6 ms·
Agreed, but that's not something you can automatically enforce.
by setpatchaddress 11y ago
Agreed, but that's not something you can automatically enforce.
- dllthomas 11y agoI guess you could require a comment on any line with an unquoted variable expansion...
- kazinator 11y agoHow about some naming convention? If a variable contains a word with no spaces, call it $foo_w or something. Shell linting programs can be patched to recognize that and suppress their warnings. Heck the shell language itself should have a declaration for this! IMAGINARY FEATURE: typeset -w foo # foo is not expected to contain spaces (Or more generally, expansions of foo are not expected to undergo field splitting by IFS regardless of content.) Now if you have an unquoted $foo that undergoes field-splitting, bash produces an error if that splitting actually breaks the contents of foo into two or more pieces.) Furthermore, a way could be provided to declare that a variable requires splitting. Maybe "typeset -W". This could even assert into how many pieces "typeset -W3 foo" means that expansions of foo are expected to undergo splitting, and it must be into three fields. Then there could be a global diagnostic option (similar to set -u and set -e) which diagnoses all unquoted expansions of variables, except for the -W and -w ones. The -w ones are diagnosed if they are subject to splitting, and splitting actually occurs. The -W ones are diagnosed if they quoted, or if they are unquoted and splitting doesn't produce the required number of pieces, if specified.