[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Doesn't MY_ENV=abc printf "${MY_ENV}\n" suppose to print abc?



On Sun, Aug 03, 2003 at 06:57:44AM -0400, Shawn Lamson wrote:
> On Sat, August 02 at 12:08 PM EDT
> Dave Carrigan <dave@rudedog.org> wrote:
> >The "MY_ENV=abc printf" syntax sets the environment variable for the
> >printf subprocess. And, in fact, when printf runs, MY_ENV is truly set
> >to abc. However, the "${MY_ENV}\n" is expanded *before* printf is
> >executed, and since MY_ENV is not set in the existing shell, the
> >expansion results in an empty string. The printf command doesn't even
> >see MY_ENV in its arguments, all it sees is a single argument that
> >looks like ``\n''.
> 
> Can you elaborate a little more on this?  I am curious, too.  After
> reading your email I tried this:
> slamson@callerio:~$ unset COMMAND
> slamson@callerio:~$ COMMAND="printf" $COMMAND "x${COMMAND}\n"
> bash: x\n: command not found
> slamson@callerio:~$ COMMAND="printf" && $COMMAND "x${COMMAND}\n"
> xprintf
> slamson@callerio:~$

Your second command is not a good example because it is actually a
complex command consisting of two simple commands and a conjunctive. An
equivalent syntax would be

  COMMAND="printf"
  if [ $? = 0 ]; then
    $COMMAND "x${COMMAND}\n"
  fi

It should be clear that the above is very different than

  COMMAND="printf" $COMMAND "x${COMMAND}\n"

It will also set COMMAND in the current shell, which the original poster
seems not to want.

> So it seems that the variable is not assigned even for the subprocess. 

See my other message that goes into this in more detail.

> Does the shell see programs to execute before it looks to do variable
> substitution?  I know the first things it sees are pipes and redirects
> but I don't know more.

Actually, the first thing it does is variable expansion, before it sets
up the redirects.

> I must admit I had never thought of just running a command after an
> assignment so it has never come up. "Bug hunting" is great, but if the
> OP needs a solution for something, what about this:
> slamson@callerio:~$ unset MY_ENV 
> slamson@callerio:~$ (MY_ENV=abc &&  printf "x${MY_ENV}\n") xabc
> slamson@callerio:~$ echo x$MY_ENV
> x
> slamson@callerio:~$ 

This is pretty close, but is not actually exporting MY_ENV to the
subshell. The reason it looks like it worked is because MY_ENV was
expanded before printf even saw it.

This would export a variable to the subshell but still let it be
expanded on the current command without setting it in the current shell:

  $ (export MY_ENV=abc && printf "${MY_ENV}\n")

However, I have no idea why this should be considered useful.

-- 
Dave Carrigan
Seattle, WA, USA
dave@rudedog.org | http://www.rudedog.org/ | ICQ:161669680
UNIX-Apache-Perl-Linux-Firewalls-LDAP-C-C++-DNS-PalmOS-PostgreSQL-MySQL



Reply to: