Set an environment variable

[Mike Meyer]

My point: the OP wanted to know how to export an environment
variable to a child process. Either of the lines of code above
will do that, so what's with all the shellular shenanigans?

Actually, the OP didn't say he wanted to export a variable to a child
process. He said he wanted to know how to do the equivalent of "export
SYMBOL=value", which got intreprted as "setting a variable in the
parent shell."

<mike

 

[Grant Edwards]

Actually, the OP didn't say he wanted to export a variable to a child
process. He said he wanted to know how to do the equivalent of "export
SYMBOL=value", which got intreprted as "setting a variable in the
parent shell."

The only think you can export an environment variable to is a
child process, so I thought it obvious that was what he was
doing with the "export" command example.

 

[Eric Brunel]

The only think you can export an environment variable to is a
child process

Well, you know that, and I know that too. From my experience, many people don't...

so I thought it obvious that was what he was
doing with the "export" command example.

Well, when I first read the OP's message, I thought it was obvious he wanted to export the variable to the parent shell. Re-reading it, it was actually not so obvious, so my apologies for not having included an example using os.environment...

 

[Grant Edwards]

Well, you know that, and I know that too. From my experience,
many people don't...

True. Using Unix for 20+ years probably warps one's perception
of what's obvious and what isn't.

 

[Alex Martelli]

True. Using Unix for 20+ years probably warps one's perception
of what's obvious and what isn't.

This specific issue is identical in Windows, isn't it? I do not know
any OS which does have the concept of "environment variable" yet lets
such variables be ``exported'' to anything but a child process.


Alex

 

[Jorgen Grahn]

This specific issue is identical in Windows, isn't it? I do not know
any OS which does have the concept of "environment variable" yet lets
such variables be ``exported'' to anything but a child process.

AmigaDOS, if I recall correctly. Its "ENV:" drive/namespace is global, and
that's its closest thing to Unix environment variables.

/Jorgen

 

[Mike Meyer]

AmigaDOS, if I recall correctly. Its "ENV:" drive/namespace is global, and
that's its closest thing to Unix environment variables.

AmigaDOS had both global environment variables (using the ENV: device)
and local environment variables, that worked like the Unix
version. You manipulated them in a similar way in the shell, and they
had a similar API for programmers: one call with a flag to indicate
which you wanted. The ENV: device was an implementation detail that
let you save/restore the state of the global environment with file
commands. The posix calls checked the local then global variables.

Of course, this is now 10+ year old memory, and I may not RC.

<mike

 

[Dennis Lee Bieber]

AmigaDOS had both global environment variables (using the ENV: device)
and local environment variables, that worked like the Unix
version. You manipulated them in a similar way in the shell, and they
had a similar API for programmers: one call with a flag to indicate
which you wanted. The ENV: device was an implementation detail that
let you save/restore the state of the global environment with file
commands. The posix calls checked the local then global variables.

Of course, this is now 10+ year old memory, and I may not RC.

Close enough. ENV: was a system defined logical name for a standard
system directory. The contents of that directory contained short files
(one line). The environment variable name was the file name, the
variable value, then, was the content of the file.

CLI commands for manipulating them tended to be of the order of

setenv name value
vs
set name value
for a shell local environment variable.

But AmigaOS also had those logical names mentioned, and those were
used in some places UNIX uses environment variables.

How would you like to refer to a directory?

HD0:myDirectory
SYS:myDirectory
myDir:

The first references via the hardware partition name; the second by
a volume label, and the third by a logical name (assign myDir:
SYS:myDirectory)

Windows lets one assign a volume label to a partition, but it is not
used for anything except display. Amiga volume labels were useful: one
could refer to two separate floppy disks by two different volume labels,
and the OS would prompt the user to insert the disk by name as needed.
Even more, if the need was fresh, rather than to perform I/O on an
already opened file, once could satisfy the prompt by putting the floppy
in ANY available floppy drive

 

[Jorgen Grahn]

AmigaDOS had both global environment variables (using the ENV: device)
and local environment variables, that worked like the Unix
version.

As I recalled it, the latter type was shell-local and not accessible to
normal processes ...

You manipulated them in a similar way in the shell, and they
had a similar API for programmers: one call with a flag to indicate
which you wanted.

.... but if there were system calls to access them, I must have remembered
incorrecly. Possibly I was too stupid back then to find enviroment variables
very useful ;-)

Of course, this is now 10+ year old memory, and I may not RC.

I think I remember /you/ though, from the Amiga newsgroups in the early
nineties. And now I feel old -- and offtopic.

/Jorgen