Discard global variables defined in script best practice?

Question

Is it good practice to write sh scripts to undo all previously defined global variables at the end of the script?

If, for example, I execute my myscript script with. (source) like this

 . myscript 

after the script is executed, the shell is interpreted with the variables defined in the script. It seems very bad (especially if other people use it).

If I could, I would get rid of globals in sh (or bash) in general, but more often than not this is not the worst solution :-).

Answer 1

Actually this is not executed script. He picks it up, which causes the shell to execute each command inside the script. If you want to execute a script, you must do the following:

 ./myscript 

And in this case, none of the environment variables that are set inside the script will affect your shell.

If you really need to specify a script so that it can do things like given environment variables or change the current directory, you can highlight the variables inside the sub-shell using parentheses:

 ( a=7 echo $a ) # The change in a doesn't get to here 

If you were to disable the variables that you are using, you will have the opposite problem. If a variable with the same name was set by the user, you end up destroying it.

Answer 2

Is it good practice to write sh scripts to undo all previously defined global variables at the end of the script?

If the script runs fine (in a sub-shell using myscript ), then there is no reason to worry about the variables (or functions) defined in the script; they disappear when the script terminates without affecting the calling shell.

If, for example, I execute my myscript script using the built-in . ( source ) like this

 . myscript 

after the script is executed, the shell is polluted by the variables defined in the script. It seems very bad (especially if other people use it).

Any script that has source code must have a very good reason for it to be available at all (setting specific environment variables or changing a directory are common reasons). Any such script that will be used by other people should be fanatical in canceling any variables that it sets by accident, trying to use distinctive named variables in the first place and disabling them all as they are completed.

Or at least I will not refer to someone else's script if it places my shell with variables. I often am not a source file outside of "profile" operations, but when I do this, the script is designed to set certain variables. He can install them (it would be useless if this were not so); but it’s better not to add a random assortment of other variables. If necessary, I make a copy of another person’s script and sanitize it for my own use, or complete it with a sanitizing script.

I have a script that I use to set the PATH (so it should more or less be useful to use). It begins:

 ps_machine=$(uname -n) ps_pathset=no ps_pathoptsfile= for ps_file in \ ${HOME}/.pathopts.$ps_machine \ ${REAL_HOME:-$HOME}/.pathopts.$ps_machine \ ${HOME}/.pathopts \ ${REAL_HOME:-$HOME}/.pathopts do ...40 lines of esoteric code... ...some set ps_perl; some set ps_pathopts... done ...5 lines of active code that set PATH... unset ps_pathset ps_pathoptsfile ps_pathopts ps_file ps_perl ps_machine 

I call it like:

 . mcpathset 

An alternative for this command would be:

 export PATH=$(mcpathset) 

Here, the output of the command is used as the new value for PATH. When you only need to set one variable, this is a viable project. If you need to set a set of environment variables (for example, configure the environment to use a specific DBMS), this is less possible.

I do not clean up variables with regular scripts - those that are not intended to be searched. But for the source scenarios, I think this is important. I doubt everyone agrees with me; many people probably didn't care. But I agree with you - it is important that the source scripts are clean.

Answer 3

Not necessary.

When executing a script, it executed a new shell, and any variable determined that the script would not affect the parent shell.

If you do . myscript . myscript in the shell itself (as opposed to inside the script), then only the set variables will be alive and can pollute the shell, as you said.