[siebenmann]

In this case, one reason to use printenv is that it is an external command, and so it is clearly and unambiguously seeing (and reporting) whatever the Bourne shell would export into the environment for a real command. In this specific case, it appears that set does not report such single-command variables (whether or not they have a value, eg 'FRED=barney set | grep FRED').

(I am the author of the linked-to entry.)

[1vuio0pswjnm7]

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'

   echo 'FRED=barney set|grep ^FRED'|sh

[_TwoFinger]

> Missing semicolon.

It's not missing. PP is making a point about "single-command variables."

[Izkata]

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)

[dcassett]

>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