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