mirror of
https://github.com/koalaman/shellcheck.git
synced 2025-10-03 19:29:44 +08:00
Created SC2229 (markdown)
39
SC2229.md
Normal file
39
SC2229.md
Normal file
@@ -0,0 +1,39 @@
|
||||
## This does not read 'foo'. Remove $/${} for that, or use ${var?} to quiet.
|
||||
|
||||
### Problematic code:
|
||||
|
||||
```sh
|
||||
read $foo
|
||||
```
|
||||
|
||||
### Correct code:
|
||||
|
||||
```sh
|
||||
read foo
|
||||
```
|
||||
|
||||
### Rationale:
|
||||
|
||||
`read` takes a variable name, but shellcheck has noticed that you give it an expanded variable instead. This will populate whatever the variable expans to instead of the variable itself. For example:
|
||||
|
||||
foo=bar
|
||||
read $foo # Reads data into 'bar', not into 'foo'
|
||||
read foo # Reads data into 'foo'
|
||||
|
||||
### Exceptions:
|
||||
|
||||
If this is intentional and you do want to read a variable through an indirect reference, you can silence this warning with a directive:
|
||||
|
||||
```sh
|
||||
# shellcheck disable=SC2229
|
||||
read "$foo"
|
||||
```
|
||||
|
||||
Or take advantage of the fact that ShellCheck only warns when no parameter expansion modifiers are applied:
|
||||
|
||||
```sh
|
||||
read "${foo}" # ShellCheck warns
|
||||
read "${foo?}" # No warning
|
||||
```
|
||||
|
||||
`${foo?}` fails when `foo` is unset, which is fine since `read` would have failed too. The main side effect is an improved runtime error message in that case.
|
Reference in New Issue
Block a user