views:

11

answers:

1

I wish to source a script, print the value of a variable this script defines, and then have this value be assigned to a variable on the command line with command substitution wrapping the source/print commands. This works on ksh88 but not on ksh93 and I am wondering why.

$ cat typeset_err.ksh
#!/bin/ksh
unset _typeset_var
typeset -i -r _typeset_var=1
DIR=init # this is the variable I want to print

When run on ksh88 (in this case, an AIX 6.1 box), the output is as follows:

$ A=$(. ./typeset_err.ksh; print $DIR)
$ echo $A
init

When run on ksh93 (in this case, a Linux machine), the output is as follows:

$ A=$(. ./typeset_err.ksh; print $DIR)
-ksh: _typeset_var: is read only
$ print $A

($A is undefined)

The above is just an example script. The actual thing I wish to accomplish is to source a script that sets values to many variables, so that I can print just one of its values, e.g. $DIR, and have $A equal that value. I do not know in advance the value of $DIR, but I need to copy files to $DIR during execution of a different batch script. Therefore the idea I had was to source the script in order to define its variables, print the one I wanted, then have that print's output be assigned to another variable via $(...) syntax. Admittedly a bit of a hack, but I don't want to source the entire sub-script in the batch script's environment because I only need one of its variables.

The typeset -r code in the beginning is the error. The script I'm sourcing contains this in order to provide a semaphore of sorts--to prevent the script from being sourced more than once in the environment. (There is an if statement in the real script that checks for _typeset_var = 1, and exits if it is already set.) So I know I can take this out and get $DIR to print fine, but the constraints of the problem include keeping the typeset -i -r.

In the example script I put an unset in first, to ensure _typeset_var isn't already defined. By the way I do know that it is not possible to unset a typeset -r variable, according to ksh93's man page for ksh.

There are ways to code around this error. The favorite now is to not use typeset, but just set the semaphore without typeset (e.g. _typeset_var=1), but the error with the code as-is remains as a curiosity to me, and I want to see if anyone can explain why this is happening.

By the way, another idea I abandoned was to grep the variable I need out of its containing script, then print that one variable for $A to be set to; however, the variable ($DIR in the example above) might be set to another variable's value (e.g. DIR=$dom/init), and that other variable might be defined earlier in the script; therefore, I need to source the entire script to make sure I all variables are defined so that $DIR is correctly defined when sourcing.

A: 

It works fine for me in ksh93 (Version JM 93t+ 2009-05-01). If I do this, though:

$ . ./typeset_err.ksh
$ A=$(. ./typeset_err.ksh; print $DIR)
-ksh: _typeset_var: is read only

So it may be that you're getting that variable typeset -r in the current environment somehow.

Dennis Williamson
Our env is untouched prior to call of the first `A=$(...)`. To ensure `_typeset_var` wasn't in the environment, we put an unset in the script typeset_err.ksh -- although since unset cannot remove readonly variables this wouldn't help if the variable were already there, readonly. So I'm not sure why you are getting success where we are not.I should also add that repeated calls look like this:`$ A=$(. ./typeset_err.ksh; print $DIR)``-ksh: _typeset_var: is read only``$ A=$(. ./typeset_err.ksh; print $DIR)``-ksh: .[2]: unset: _typeset_var: is read only``-ksh: _typeset_var: is read only`
Bernard Assaf
@Bernard: Repeated calls for me print "init" each time.
Dennis Williamson

related questions