${gapver:=$SAGE_ROOT/spkg/standard/newest_version gap}
GAP0=`$gapver`
SAGE_ROOT will be an absolute path, so $SAGE_ROOT/spkg/standard/
newest_version is a program which takes an argument which in this case
is "gap".
Someone has said:
"The meaning of ':=' there is to only set $gapver to $SAGE_ROOT/
spkg/.... if
$gapver was unset or null previously.
"
Is that POSIX compliant? Can anyone tell me who this can be written
more portably so it runs with the default shell on Solaris, whilst not
breaking elsewhere?
Dave
> I work on a project which has this bit of code:
>
> ${gapver:=$SAGE_ROOT/spkg/standard/newest_version gap}
> GAP0=`$gapver`
>
> SAGE_ROOT will be an absolute path, so $SAGE_ROOT/spkg/standard/
> newest_version is a program which takes an argument which in this case
> is "gap".
>
> Someone has said:
>
> "The meaning of ':=' there is to only set $gapver to $SAGE_ROOT/
> spkg/.... if
> $gapver was unset or null previously.
> "
${var:=val} sets var to val if $var is empty or unset
${var=val} sets var to val if $var is unset (but not if it's empty)
> Is that POSIX compliant?
Yes.
> Can anyone tell me who this can be written more portably so it runs with
> the default shell on Solaris, whilst not breaking elsewhere?
I think some old bourne shells support only = but not :=, I don't know what
the one you're using in Solaris does, but if you provide more details about
its version there are readers here that surely can help you.
>Someone has said:
Yes and it works for the default shell in Solaris; you should note
that
${gapver:=$SAGE_ROOT/spkg/standard/newest_version gap}
will value to that expression and the shell will execute $gapver:
$ ${gapver:=echo gapver was null or not set}
gapver was null or not set
I.e., gapver is set and then it is evaluated.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
> I think some old bourne shells support only = but not :=, [...]
Yes, the colon form of parameter expansion was introduced with System III ('81).
The predecessors (mainly 7th edition, traditional BSDs, Ultrix /bin/sh but not sh5)
are of historical interest (let alone that functions were not implemented, yet).
> ${gapver:=$SAGE_ROOT/spkg/standard/newest_version gap}
> GAP0=`$gapver`
>
> SAGE_ROOT will be an absolute path, so $SAGE_ROOT/spkg/standard/
> newest_version is a program which takes an argument which in this case
> is "gap".
>
> Someone has said:
>
> "The meaning of ':=' there is to only set $gapver to $SAGE_ROOT/
> spkg/.... if
> $gapver was unset or null previously.
> "
>
> Is that POSIX compliant?
The syntax: yes. The statement above: no, and that is not what happens.
$gapver will be set in any case. See SUSv3, 2.6.2 Parameter Expansion:
| parameter parameter parameter
| Set and Not Null Set But Null Unset
| [...]
| ${parameter:=word} Substitute parameter assign word assign word
PointedEars
Please, what is SUSv3?
Thanks,
David
No, it will only be set (to $SAGE_ROOT/...) if it was unset or
null, as described by:
> See SUSv3, 2.6.2 Parameter Expansion:
>
>| parameter parameter parameter
>| Set and Not Null Set But Null Unset
>| [...]
>| ${parameter:=word} Substitute parameter assign word assign word
Which is exactly what Dr. Kirby stated.
--
Chris F.A. Johnson, author <http://shell.cfajohnson.com/>
===================================================================
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress)
===== My code in this post, if any, assumes the POSIX locale =====
===== and is released under the GNU General Public Licence =====
--
Newton's Law of Gravitation:
What goes up must come down. But don't expect it to come down where
you can find it. Murphy's Law applies to Newton's.
> Thomas 'PointedEars' Lahn wrote:
>> Dr. David Kirkby wrote:
>>> ${gapver:=$SAGE_ROOT/spkg/standard/newest_version gap}
>>> GAP0=`$gapver`
>>>
>>> SAGE_ROOT will be an absolute path, so $SAGE_ROOT/spkg/standard/
>>> newest_version is a program which takes an argument which in this case
>>> is "gap".
>>>
>>> Someone has said:
>>>
>>> "The meaning of ':=' there is to only set $gapver to $SAGE_ROOT/
>>> spkg/.... if
>>> $gapver was unset or null previously.
>>> "
>>>
>>> Is that POSIX compliant?
>>
>> The syntax: yes. The statement above: no, and that is not what happens.
>> $gapver will be set in any case.
>
> No, it will only be set (to $SAGE_ROOT/...) if it was unset or
> null,
At least that is what happens in bash 4.1.2(1). Thanks.
> as described by:
>
>> See SUSv3, 2.6.2 Parameter Expansion:
>>
>>| parameter parameter parameter
>>| Set and Not Null Set But Null Unset
>>| [...]
>>| ${parameter:=word} Substitute parameter assign word assign word
>>|
>
> Which is exactly what Dr. Kirby stated.
Yes, apparently I misunderstood "substitute parameter" as "substitute the
value of parameter (with word)".
PointedEars
That's what happens with *any* Bourne-type shell.
>> as described by:
>>
>>> See SUSv3, 2.6.2 Parameter Expansion:
>>>
>>>| parameter parameter parameter
>>>| Set and Not Null Set But Null Unset
>>>| [...]
>>>| ${parameter:=word} Substitute parameter assign word assign word
>>>|
>>
>> Which is exactly what Dr. Kirby stated.
>
> Yes, apparently I misunderstood "substitute parameter" as "substitute the
> value of parameter (with word)".
>
>
> PointedEars
> Thomas 'PointedEars' Lahn wrote:
>> Chris F.A. Johnson wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> Dr. David Kirkby wrote:
>>>>> ${gapver:=$SAGE_ROOT/spkg/standard/newest_version gap}
>>>>> [...]
>>>>> Someone has said:
>>>>>
>>>>> "The meaning of ':=' there is to only set $gapver to $SAGE_ROOT/
>>>>> spkg/.... if
>>>>> $gapver was unset or null previously.
>>>>> "
>>>>>
>>>>> Is that POSIX compliant?
>>>> The syntax: yes. The statement above: no, and that is not what
>>>> happens. $gapver will be set in any case.
>>> No, it will only be set (to $SAGE_ROOT/...) if it was unset or
>>> null,
>>
>> At least that is what happens in bash 4.1.2(1). Thanks.
>
> That's what happens with *any* Bourne-type shell.
So you have tested them *all*? For a line in SUSv2+ does not need to mean
that all "Bourne-type" shells support it. (For me, it suffices to know
that the current bash and POSIX-compliant shells support it like that.)
Please trim your quotes to the relevant minimum.
PointedEars
> Chris F.A. Johnson wrote:
>
> > Thomas 'PointedEars' Lahn wrote:
> >> Chris F.A. Johnson wrote:
> >>> Thomas 'PointedEars' Lahn wrote:
> >>>> Dr. David Kirkby wrote:
> >>>>> ${gapver:=$SAGE_ROOT/spkg/standard/newest_version gap}
> >>>>> [...]
> >>>>> Someone has said:
> >>>>>
> >>>>> "The meaning of ':=' there is to only set $gapver to $SAGE_ROOT/
> >>>>> spkg/.... if
> >>>>> $gapver was unset or null previously.
> >>>>> "
> >>>>>
> >>>>> Is that POSIX compliant?
> >>>> The syntax: yes. The statement above: no, and that is not what
> >>>> happens. $gapver will be set in any case.
> >>> No, it will only be set (to $SAGE_ROOT/...) if it was unset or
> >>> null,
> >>
> >> At least that is what happens in bash 4.1.2(1). Thanks.
> >
> > That's what happens with *any* Bourne-type shell.
>
> So you have tested them *all*? For a line in SUSv2+ does not need to mean
> that all "Bourne-type" shells support it. (For me, it suffices to know
> that the current bash and POSIX-compliant shells support it like that.)
I think this has been part of Bourne-style shells for decades, since
before POSIX and SUS existed. They simply wrote down what was already a
de facto standard.
If it doesn't work in any particular shell, I'd claim that it's either
not Bourne-style or it has a bug.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
>> Please, what is SUSv3?
>>
> Single Unix Specification, version 3.
> The SUSv3 standard is practically the same as POSIX, [...]
The only difference between SUSv3 and POSIX.1-2001 is that
SUSv3 includes an XCurses volume that is not in POSIX.1-2001.
Likewise for SUSv4 and POSIX.1-2008.
--
Geoff Clare <net...@gclare.org.uk>