processing passwords?

[Kenneth Brody]

On 10/15/2012 6:26 PM, Jean-Pierre A. Radley wrote:
> Jay Ashworth propounded (on Mon, Oct 15, 2012 at 05:35:02PM -0400):
> | ----- Original Message -----
> | > From: "Jean-Pierre A. Radley" <appl at jpr.com>
[...]
> | > An assignment exists in the environment of the shell in which it is
> | > made.
> | > An assignment preceding a command makes it exist in the command's
> | > environment too.
> | > Since the command in this case an "export" of that assignment, the
> | > assignment persists in the environment of the shell in which it was
> | > made as well as in all of that shell's children.
> |
> | Not quite.
> |
> | ==================8<====================
> | jra at princeton:~> unset JRA            # make sure the variable isnt set.
> | jra at princeton:~> JRA=test echo $JRA   # set it in the environment of echo
> |                                       # find out that it wasn't set by the time
> |                                       # the statement was parsed
> | jra at princeton:~> echo $JRA            # how bout now?
> |                                       # still not set
> | jra at princeton:~> JRA=test bash        # try inline with a subshell
> | jra at princeton:~> echo $JRA
> | test                                  # INSIDE THE SUBSHELL, it's set
> | jra at princeton:~> exit                 # exit the subshell
> | jra at princeton:~> echo $JRA            # set up top?
> |                                       # no, as expected.
> | jra at princeton:~>
> |
> | ==================8<====================
> |
> | So the important part of your second assertion:
> |
> | > An assignment preceding a command makes it exist in the command's
> | > environment too.
> |
> | is, as my memory led me to believe, incorrect: assignments which precede
> | a command name on the command line do *not* affect the environment of the
> | shell which processes them, only that of the command specified.  I myself
> | had not realized that the shell parsed the command line before setting
> | up the child environment and running it, which is why
> |
> | $ JRA=test echo $JRA
> |
> | does not work in the superficially obvious manner, but it makes sense
> | after I think about it -- it's like trying to use sudo with redirection.
> |
> | That behavior is documented back to the v7 shell, I'm pretty sure, though
> | my v7 UPM is at home.
> |
>
> Your shell isn't behaving like mine, in that case. I start out in tcsh
> and:
>
> 	jpradley:appl 6 sh
> 	$ unset JPR
> 	$ JPR=test echo $JPR
>
> 	$ echo $JPR
> 	test

I hate to do it, but I have to side with Jay against JP on this one.  My 
understanding has always been that "name=val command" sets the value of the 
environment variable only for "command", and not in the shell.  It's been 
this way since at least TRS-Xenix days.  In fact, "man sh" on my Linux box says:

>        The  environment for any simple command or function may be
>        augmented  temporarily  by  prefixing  it  with  parameter
>        assignments,  as  described  above  in  PARAMETERS.  These
>        assignment statements affect only the environment seen  by
>        that command.

What does "echo $JPR" say *before* the echo command?

-- 
Kenneth Brody