varname=(assign_list) with . filename

[phidebian]

Hi All,
I read in the man this

   Variable Assignments.
       One  or  more variable assignments can start a simple command 
       ... [deleted]
       The syntax for an assignment is of the form:

       varname=word
       ... [deleted]
       varname=(assign_list)
              No  space  is permitted between varname and the =.  The variable
              varname is unset before the assignment.  An assign_list  can  be
              one of the following:
                      word ...
                      [word]=word ...
                      assignment ...
                      typeset [options] assignment ...
 
                      . filename
                             Include  the  assignment  commands  contained  in
                             filename.

I am interested with the last form . filename yet can't find any example of a use of it, i.e I looked all the test/*.sh but was not able to find anything, though my grep'ing may have overlooked complex syntax.

So a basic test like this

v=(. /tmp/doesnotexist)

Seem to be successfull while I guess it should fail, but I fear I misunderstand something because inspecting v[@] shows

$ echo ${#v[@]}
2
$ echo ${!v[@]}
0 1
$ echo ${v[@]}
. /tmp/doesnotexist

So looks like (. filename) are just 2 values entered into the indexed array v[]

I tried many combo pre typeseting V with -C -a -A but nothing works, and indeed used an existing file with no more results.

So how do we source values into a variable ? or a compound variable?

Thanx in advance for nay helps.

[McDutchie]

I had not noticed that before!

This feature was supposedly introduced in ksh 93t 2008-06-24 (ksh93/ksh93-history@ce81643). This is also the commit that added typeset -C and read -C.

Relevant src/cmd/ksh93/RELEASE entry:

08-06-11  The . command is now permitted inside a compound command definition.
         The dot script can contain declaration commands and dot commands.

Of course, the . command was always permitted inside a compound command ever since there have been compound commands, e.g. if foo; then . bar; fi has always been fine. So what I suspect they meant is: “The . command is now permitted inside a compound assignment definition.”.

However, I can find no trace in that commit's code changes of any special handling of . within compound assignments.

And when we do specify the -C attribute, the . is now a syntax error:

$ typeset -C z=(. /tmp/foo)
-ksh: syntax error: `.' unexpected

It wasn't a syntax error between 2008-06-24; it became a syntax error on 2012-04-03. However, the . doesn't work as a command in a compound assignment even in those historic versions (I've tested). Instead, typeset -C simply lacked proper syntax validation so it accepted (and mishandled) all sorts of nonsense.

Given how sloppy AT&T generally were with things, I wouldn't put it past them to have decided that this . thing was a failed experiment, remove the code before committing it, and then forget to remove the documentation.

[McDutchie]

Looks like I missed something.

$ typeset -C v
$ echo c=3 d=4 >/tmp/foo
$ v=(a=1; b=2; . /tmp/foo; e=5; f=6)
$ typeset -p v
typeset -C v=(a=1;b=2;c=3;d=4;e=5;f=6)

But:

$ typeset -C v=(a=1; b=2; . /tmp/foo; e=5; f=6)
-ksh: syntax error: `.' unexpected

That is certainly inconsistent.

[phidebian]

Jeez, I was on the path of fiddling around the -C, but didn't got that far.

Yet leveraging on your work, during my initial test I was doing only <SPC> separator construct of the assign-list i.e I was doing

typeset -C v 
$ v=(a=1 b=2 e=5 f=6)  # Instead of     v=(a=1;b=2;e=5;f=6)         
$ typeset -p v       
typeset -C v=(a=1;b=2;e=5;f=6)

I was omitting the typeset -p thanx for reminding me this one, and to my grand surprise, the <SPC> are replaced with ; let me thinking that the semicolon version must the more common way to do this.

I reviewed the docco to discover I was confused with 2 terms, simple command and assign-list.
The simple command is a list of variable assignments of the form

varname=word
varname[word]=word
varname=(assign_list)

And assign-list is described as one of the following.

word ...
[word]=word ...
assignment ...
typeset [options] assignment ...
. filename

None of them specify that assignment got to be separated with ; except the typeset case that kind of make sense, so I wondered how you came to a syntax like v=(a=1;b=2;e=5;f=6) with no typeset, I was stuck with the <SPC> separator.

Now I learned this kind of undocumented ; separator I went ahead and discover this

For Assoc Array

TC$ typeset -A a                                                                                     
TC$ a=(["b"]=bb ["c"]=cc ; ["d"]=dd ; ["e"]=ee) # Mix'n'Match here
TC$ typeset -p a
typeset -A a=([b]=bb [c]=cc [d]=dd [e]=ee)

The assigned to Assoc Arr a mix the <SPC> and ; and the typeset -p display something with ; replaced with <SPC>

And for compound var

TC$ typeset -C c
TC$ c=(b=bb c=cc ; d=dd ; e=ee)         # Mix'n'Match here       
TC$ typeset -p c
typeset -C c=(b=bb;c=cc;d=dd;e=ee)

That's the reverse the typeset -p favour the ; vs <SPC>

I noticed you did the Mix'n'Match via the foo file i.e the foo file is <SPC> separated while the v= assignment is ; separated, so looks like Mix'n'Match is expected to coexist.

I guess this is normal then that typeset make a syntax error on inline dot so we can forget about this. The docco never specify that typeset will accept a dot in its argv[], and then that's why the dot construct is mentionned after the typeset in assign-list i.e

typeset [options] assignment ...
. filename

So to me it is ledgit this way, may be a simple docco fix, mentioning the ; and reset the expectation that typeset could do a dot would suffice. I like the way it works as it is as soon as you know you can stick ; everywhere.

May be one concern though, I took your example but ommitted the foo creation, i.e doesn't exist on /tmp, if you created it before remove it.

TC$ typeset -C v                                                                                     
TC$ v=(a=1; b=2; . /tmp/foo; e=5; f=6)
/d1/ksh-latest/arch/linux.i386-64/bin/ksh: .: /tmp/foo: cannot open [No such file or directory]
TC$ v=(a=1; b=2; e=5; f=6)            
TC$ typeset -p v
Segmentation fault

I was please to see the no such file expected error, but a little surprised with the segfault so looks the compound things looks fragile. Coming from dtksh back from the 90's I was kind of novice regarding -T -C I played a bit them, and concluded it was kind of tricky, but may be interesting in the long run.

If you think we should track the segfault lemme know and I would open an issue...

Thanx for your archeological investigations :-) I am always impress :-)