News for hackers. Stuff that matters.
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)