Re:The roots of an obscure Bourne shell error message
by 1vuio0pswjnm7 on Monday September 11, 2023 @10:57PM
(#37476553)
Missing semicolon.
FRED=barney; set | grep FRED
Also there is no need for grep, nevermind grep -F (fgrep), if using printenv. FRED=barney printenv FRED
Without semicolon sh -c 'FRED=barney set'|grep ^FRED
Re:The roots of an obscure Bourne shell error message
by dcassett on Monday September 11, 2023 @11:15PM
(#37476632)
>Missing semicolon.
If you add a semicolon then FRED is no longer a single command variable (it persists)
> on NetBSD, one can do this
Linux also does the expected thing:
$ FRED=barney printenv FRED
barney
Re:The roots of an obscure Bourne shell error message
by _TwoFinger on Monday September 11, 2023 @11:11PM
(#37476615)
> Missing semicolon.
It's not missing. PP is making a point about "single-command variables."
Re:The roots of an obscure Bourne shell error message
by Izkata on Tuesday September 12, 2023 @06:17PM
(#37489332)
Single-command environment variables, to be precise. The same thing that gets created when you use "export", but isn't created when you use "=" on a line on its own:
$ FOO=BAR env | grep FOO # Exists as an environment variable passed to env
FOO=BAR
$ env | grep FOO # But only for that command
$ FOO=BAR # Creates a variable (not an environment variable)
$ env | grep FOO # As shown by not being passed down
$ echo $FOO # But still accessible in this context
BAR
$ export FOO=BAR # Promotes it to an environment variable (the "=BAR" is optional since it's already defined)
$ env | grep FOO # And as such is now visibly passed down
FOO=BAR
(Yes, bash does mix these together so it's easy to accidentally replace something you don't intend to)
(I am the author of the linked-to entry.)