Referrer key missing form os.environ dictionary?

Grant Edwards invalid at invalid.invalid
Thu Sep 26 19:27:10 EDT 2013


On 2013-09-26, Chris Angelico <rosuav at gmail.com> wrote:
> On Fri, Sep 27, 2013 at 12:11 AM, Grant Edwards <invalid at invalid.invalid> wrote:
>> On a Unix system when you invoke a program, you "pass" it four things:
>>
>>  1) A dictionary where keys/values are both strings [enviornment variables]
>>  2) A list of strings [command line args]
>>  3) A set of open file descriptors.
>>  4) The current working directory.
>>
>> You can provide input values to the program through any of these.
>>
>> For interactive programs, 2 and 3 are the most convenient.
>
> Hrm, not sure about #3 for interactive programs, unless you
> specifically mean the three standard streams.

Yes, that's what I mean: shell redirection/pipelines.  Hooking stuff
to stdin is pretty much the only example of this you'll ever see in
the wild for input data:

 foo < inputdata
 
 bar | foo
 
 foo <<EOF
 this is input 
 data that is passed
 to program foo using
 file descriptor 0
 EOF 

> With most Unix shells, you should be able to set environment
> variables:
>
> PGUSER=fred PGPASSWORD=secret psql

Yep, that's rather rarely used.  The syntax/sematics for values passed
that way is very limited compared to the syntax/semantics that can be
used for command line arguments, so the latter is much more versatile.

> Not as convenient as #2, but far easier than passing an open file
> descriptor. Of course, passing file descriptors around is pretty easy
> programmatically, but when you say "interactive" I assume you're
> talking also about an interactive shell.

I probably should have said "stdin", but in theory you can pass data
in via multiple file descriptors.  Nobody does that except people
cooking up obscure examples for advanced shell scripting guides...
 
> GUI interactions of course follow their own rules completely. In most
> systems, it's really easy to invoke an application with one argument,
> a file name; it's generally much harder to customize the arguments at
> the keyboard. OS/2 had a facility for doing that. You just put square
> brackets into the configured args and it'd turn it into a prompt:
>
> --foo=bar --mode=[Choose mode, 1-3:] %*
>
> You'd get a nice little popup with the prompt you specified, and
> whatever you type gets put into the args. Haven't seen that in any
> other system - at least, not as conveniently.

-- 
Grant Edwards               grant.b.edwards        Yow! I request a weekend in
                                  at               Havana with Phil Silvers!
                              gmail.com            



More information about the Python-list mailing list