processing passwords?
Nancy Palmquist
nlp at vss3.com
Thu Oct 18 11:41:12 PDT 2012
Richard,
Try F8 - O-Options (It is not a listed on the scree but it works.) I
have accidentally hit it and it took me some time before I pinned down
the right keys.
Works in all versions of filepro I use.
Nancy
On 10/15/2012 6:00 PM, Richard D. Williams wrote:
> 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
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list
>
--
Nancy Palmquist MOS & filePro Training Available
Virtual Software Systems Web Based Training and Consulting
PHONE: (412) 835-9417 Web site: http://www.vss3.com
More information about the Filepro-list
mailing list