processing passwords?

[Jean-Pierre A. Radley]

Kenneth Brody propounded (on Tue, Oct 16, 2012 at 10:49:46AM -0400):
| 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?

Don't follow you, Ken.

The comand "JPR=test echo $JPR" produces just a newline.

The next command shows that the assignment (JPR=test) before the command
(echo $JPR) persists in the invoking shell, because the next command
(echo $JPR) prints "test".

-- 
JP