processing passwords?

[Richard D. Williams]

There is a "prompt"  for a password while in *cabe.
I have stumbled across it while wildly typing and I still do not known 
what I hit to make it popup .

In the FP Linux version I do not see anything from the F8 key that would 
be a password.


Richard

On 10/15/2012 4:35 PM, Jay Ashworth wrote:
> ----- Original Message -----
>> From: "Jean-Pierre A. Radley" <appl at jpr.com>
>> To: "FilePro Mailing List" <filepro-list at lists.celestial.com>
>> Sent: Monday, October 15, 2012 5:19:58 PM
>> Subject: Re: processing passwords?
>> Jay Ashworth propounded (on Mon, Oct 15, 2012 at 05:09:59PM -0400):
>> | ----- Original Message -----
>> | > From: "Jean-Pierre A. Radley" <appl at jpr.com>
>> |
>> | > | KENMAGIC=1; export KENMAGIC
>> | >
>> | > Why the superflous, unnecessary semi-colon?
>> |
>> | export means "make the named variable visible to child processes;
>> | doing an assignment in front of a command makes it visible to *that*
>> | processes, but *not* in the environment of the shell running that
>> | process; I've never been clear on the semantics of the first. So
>> | since
>> | I *always* want it set in the current process as well as its
>> | children,
>> | I do the assignment and the export as separate commands.
>>
>> 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.
>
> Cheers,
> -- jra