Bash script turmoil
 

A small script which sets an environment variable will not work.

#!/bin/sh
NPX_PLUGIN_PATH=/usr/local/Acrobat5/Browsers/intellinux
export NPX_PLUGIN_PATH

I can surround the [/usr/local/Acrobat5/Browsers/intellinux] with
single quotes or double quotes and still nothing.

I can enter the commands individually from the command line
and the variable appears in the environment but, despite what
I do, the script will not work.

I'm rather new to bash scripting but the above seems simple
enough and should work. Before you ask, there is a symlink
to bash in /bin (i.e. sh -> bash). Running as root.

Is there something different in Slackware that could be causing
the problem or is it something very simple that I am missing or
just unaware of?

I would think the script is executing and performing as desired. However, after the script terminates the setting will be lost because the script terminated. The value will be stored in the environment for the script file and all child processes, but not the environment for the parent process I think as you desire.

Consider adding your setting in the /etc/profile script or create a .bashrc script in the users home directory. If the setting is for a particular program, edit or create a shell wrapper script to execute the setting and then call the program from within the script.

Hope it helps.

Try source(ing) the script to cause it to exeute in the current shell.
You must have a . [space] then command. The env variable will then show up in the current shell.

I suspected that running the script might cause the variable to go 'out of scope'
after the script finished, but that's what the 'export' function is for isn't it? To set
the environment variable permanently (at least for the current session).

Using . ./script.sh results in an 'env' printout in which the exported variable appears
but upon entering 'env' again, the variable is missing.

Some of the startup script files like profile and the various rc.x's contain execution
instructions that use the space convention like:

. /somedirectory/somefile

but using something like this while you are in the current shell gives the result
described above, i.e. the env variable is not really set.

Where do you want to go from here?

I'm not sure what your problem is. You may have to post an example. These are the results I see:

dude.sh
bash shell
Works as I would expect. Now if you exited out of this shell, you would loose the variable.

I suppose the upshot of all this is why can't I create
a script which will export an environmental in the
same fashion as if I had typed the instructions at
the terminal.

For instance, if I type at the terminal:

$ NPX_PLUGIN_PATH=/usr/local/Acrobat5/Browsers/intellinux[enter]

$ export NPX_PLUGIN_PATH[enter]

and then enter 'env' [enter]

I see the variable in the 'env' printout, but if I use the script

#!/bin/sh
NPX_PLUGIN_PATH=/usr/local/Acrobat5/Browsers/intellinux
export NPX_PLUGIN_PATH

call it DUDE.sh and enter on the command line . ./DUDE.sh

the variable is not set.

That's as clear as I can describe it!

post the output of:

The output of set | grep SHELL is:

SHELL=/bin/bash
SHELLOPTS=braceexpand:hashall:histexpand:monitor:ignoreeof:interactive-comments:emacs

The reason is because when you place the "#!/bin/sh" at the top
of your script, you are explicitly saying you would like to start up
a NEW shell, one that will run until the end of this file. It's just
as if you had started a new xterm (or whatever you are using).
The variables you've defined in your old xterm will not be carried
over to the new one. They know nothing about each other. If
you want something to be kept across different shells, you need
to set it up in your shell startup (.cshrc, .bashrc, etc.).
To get what you want, you need to "source" the file. That is,
you need to tell your current shell that you want to run the
commands in the file as if you had just typed them all in at the
prompt.
example (in a file):
The "./foobar" notation means to run this as a shell executable,
and the first line indicates that it is, in fact a shell executable, so
it starts up a new shell (/bin/bash), and then runs the rest of the
file.
The ". foobar" and "source foobar" notation tell the current shell
to just run the commands as if you had typed them in. The
reason the #!/bin/bash doesn't start up a new shell is because it
is recognized as a comment by the shell. In the "./foobar"
notation, it's not a comment, it's a special sequence of
characters that indicate that this file can be treated as a shell
executable, IF it's called accordingly.

Thank you! I knew there must be some way to accomplish this
with a script. As it turns out the notation

. ./Script.sh does not work as advertised but using either

. Script.sh or source Script.sh work as you describe. I had actually
tried the . Script.sh before but I guess I did something wrong because
it did not work correctly.

I have been through several bash scripting tutorials and have
never seen these methods described. Maybe this is not all
that obscure but I was certainly unaware of the distinction.