[Linux-Anyway] Re: Update: Searched & searched for locale....
- From: Horror Vacui <horrorvacui@xxxxxxx>
- To: Linux-Anyway@xxxxxxxxxxxxx
- Date: Mon, 8 Dec 2003 18:24:23 +0100
On Mon, 8 Dec 2003 15:12:16 +0100
Godwin wrote:
> Mon, 8 Dec 2003 14:38:07 +0100 scripsit Horror Vacui:
>
> > which is quite a sound assumption, seeing that I'm incapable of
> > using a bash script to set variables permanently.
>
> That's what "export" is for.
>
> Saying something like:
>
> MYVARIABLE="something"
>
> ...in a script will make the environment variable available to that
> script but once it's finished executing it gets dropped along with all
> the other environment variables belonging to the process.
>
> If, OTOH, your script says:
>
> export MYVARIABLE="something"
>
> -- or --
>
> MYVARIABLE="something"
> export MYVARIABLE
>
> ...then the environment variable "MYVARIABLE" gets added both to the
> environment block of the current process (i.e. the instance of bash
> running your script) *AND* that of the parent process (i.e. the
> instance of bash from which you invoked your script).
The funny thing is, I *did* use export in both versions, the one-liner
and define-then-export alike. Wouldn't work. I just went and tried it
again, with the script "testscript":
#!/bin/bash
MYVAR="blah"
export MYVAR
echo $MYVAR
Invoking it gives the expected results, but see what happens when I try
the same after the script has exited; also, export -p doesn't list it.
bash-2.05b$ ./testscript
blah
bash-2.05b$ echo $MYVAR
bash-2.05b$ export -p | grep MYVAR
bash-2.05b$
When I do the same entirely on the command-line, it works:
bash-2.05b$ export MYVAR="blah"
bash-2.05b$ echo $MYVAR
blah
bash-2.05b$
I'm confused. I first thought that I might have made a stupid error in
the (rather complicated) script in which I tried to do this originally -
like inadvertently invoking yet another instance of bash before
exporting the variable - but it doesn't seem the case.
Even more confusingly, I've put a similar construct in the /etc/profile
to set the TZ (timezone) variable on this system, and it works.
>
> All this, of course, is based on the understanding that when you
> invoke a script on the command line, you do in fact fire up a new
> instance of bash which accepts your script as input (instead of
> accepting input from the keyboard).
>
> IOW, if you type:
>
> $ /path/to/your/script
>
> ...the instance of bash currently running will "see" that your script
> is a script rather than a binary, analyse the first line, called the
> "shebang" line which is of the form "#!/path/to/interpreter", and fire
> up the stated interpreter telling it to read the file as a set of
> commands. The exception is if you type something like:
>
> $ . /path/to/script
>
> (Note the period and the space)
>
> This gets the current instance of bash to interpret the given script
> as bash commands within the same process, without firing up a child
> bash process.
Ah, thanks! This helps my understanding of it no end. I'm familiar with
the . /script notation, but I didn't know what it does exactly. I saw it
used to source other files from configfiles, and I vaguely imagined it
enables the script to read the values from the other (which in fact it
does), but I wasn't aware that it works like that (the best likeness of
an #include for bash, I'd say).
Cheers
--
Horror Vacui
Registered Linux user #257714
Go get yourself... counted: http://counter.li.org/
- and keep following the GNU.
To unsubcribe send e-mail with the word unsubscribe in the body to:
Linux-Anyway-Request@xxxxxxxxxxxxx?body=unsubscribe
Other related posts:
