mirror of
https://github.com/koalaman/shellcheck.git
synced 2025-10-03 19:29:44 +08:00
Created SC2097 (markdown)
29
SC2097.md
Normal file
29
SC2097.md
Normal file
@@ -0,0 +1,29 @@
|
||||
## This assignment is only seen by the forked process.
|
||||
|
||||
### Problematic code:
|
||||
|
||||
name=World cmd -m "Hello $name"
|
||||
|
||||
### Correct code:
|
||||
|
||||
export name=World
|
||||
cmd -m "Hello $name"
|
||||
|
||||
To prevent setting the variable, this can also be done in a subshell:
|
||||
|
||||
(
|
||||
export name=World
|
||||
cmd -m "Hello $name"
|
||||
) # 'name' does not leave this subshell
|
||||
|
||||
### Rationale:
|
||||
|
||||
In `name=World cmd "$name"`, `name=World` is passed in as part of the environment to `cmd` (i.e., in the `envp` parameter to [man 2 execve](http://linux.die.net/man/2/execve)). This means that `cmd` and its children will see the parameter, but no other processes will.
|
||||
|
||||
However, `"$name"` is not expanded by `cmd`. `"$name"` is expanded by the shell before `cmd` is ever executed, and thus it will not use the new value.
|
||||
|
||||
The solution is to set the variable and export the variable first. If limited scope is desired, a `( subshell )` can be used.
|
||||
|
||||
### Contraindications
|
||||
|
||||
In the strange and fabricated scenarios where the script and a program uses a variable name for two different purposes, you can ignore this message. This is hard to conceive, since scripts should use lowercase variable names specifically to avoid collisions with the environment.
|
Reference in New Issue
Block a user