4 ms·

He is still missing the double quotes, paths may contain spaces

by rurban 3y ago

stouset 3y ago
Yep. LIB="$(dirname "$(realpath "$0")")" It seems like overkill, but just get in the habit of quoting anything and everything.
- js2 3y ago
  You can technically omit the double-quotes during a scalar variable assignment (as long as it's not preceded by a modifier such as `export`), so the outermost quotes are not needed above. https://unix.stackexchange.com/questions/68694/when-is-double-quoting-necessary https://unix.stackexchange.com/questions/68694/when-is-doubl... The extra quotes don't hurt, but also: use shellcheck. It will tell you if you've omitted necessary quotes.
  - lloeki 3y ago
    > The extra quotes don't hurt I have the habit of quoting everything, that way I don't have to think about any corner case where I can skip quotes, and thus conversely never miss anything where I should quote. I do the same with curly braces, that way I don't have to think whether "${foo_bar}" or "${foo}_bar" was meant, and makes later adding or reading string manipulation (e.g "${haystack/needle/replacement}") or arrays (e.g "${foo[42]}" or "${foo[@]}" that much more consistent: variable references are always bounded by ${} which makes code easier to scan. I apply that to "${1}" and "${@}" too whenever possible, unfortunately bash 3.x doesn't quite like that so it's not always the case (I can't decide which one I hate more: macOS for the refusal to either update bash or outright drop it† and just have a plain posix sh + zsh, or GNU for the viral license move which is highly detrimental in practice for that case). I also often quote "semantically", e.g: # instead of: PATH="/some/path/${foo}/bar:${PATH}" /some/command "--foo=${bar}" # I'd rather do: PATH="/some/path/${foo}/bar":"${PATH}" /some/command --foo="${bar}" † I guess there's a crapton of bash scripts that have been written and possibly embedded in apps or installers, so backwards compatibility won here.
    - stouset 3y ago
      Are you me? :)
  - stouset 3y ago
    I actually personally use `declare` frequently, particularly to make variables readonly. So in my case the quotes are necessary. Of course this has its own issues, in that subprocess exit codes are hidden, so you often need to assign then declare. But I quote everything, always, because then I don’t have to rely on remembering when it’s necessary and when it isn’t. Just do the safe thing every time and you don’t have to think.
- tpoacher 3y ago
  no, you should only quote things that you want quoted. ("duh") the caveat being if you actually do want things expanded then you should not quote them. for i in $(seq ...) comes to mind...
iforgotpassword 3y ago
Yeah that made me really anxious while reading this. That's the first thing I hammer into fresh hires and interns who are "lucky" enough to end up dealing with shell scripts.
enriquto 3y ago
> paths may contain spaces what kind of savage puts spaces on their paths? Failing in such cases is a neat feature it would seem. I never understood why common filesystems allow this foolishness. There are already other semantically meaningful characters in paths that are forbidden, like '/' or '\0'. Disallowing bare spaces in filenames is such a natural feature that it makes no sense to deal with all this stupid quoting pain. Any space that is entered by a user in a filename context should be transparently translated to a unicode non-breaking space. Most users wouldn't notice, and shell scripts authors would be much happier!
- rurban 3y ago
  > what kind of savage puts spaces on their paths? Failing in such cases is a neat feature it would seem. windows noobs (as in embedded development), but more likely grabbed music.
- lifthrasiir 3y ago
  Failing in the way that it is virtually not fixable (e.g. Windows user names) or destructive (e.g. removing some unrelated directories) is not neat. It is even often said that Windows had a space in `C:\Program Files` (now `C:\ProgramData`) in order to make sure that app developers have to handle paths with spaces correctly. Don't know if it's indeed true, but at least it's believable.
- CorrectHorseBat 3y ago
  It's much worse than this. On Unix '\000' (NUL) and '\057' (/) are the _only_ things that are not allowed. Anything else, whether it's valid in any encoding or not, is allowed.
  - ykonstant 3y ago
    In order to test my shell scripts, I have a directory hierarchy of filenames generated from /dev/urandom, which contains a sub-structure with filenames in unary, using only the newline character.
- lmm 3y ago

He is still missing the double quotes, paths may contain spaces

by rurban 3y ago

He is still missing the double quotes, paths may contain spaces

Yep. LIB="$(dirname "$(realpath "$0")")" It seems like overkill, but just get in the habit of quoting anything and everything.

js2 3y ago
You can technically omit the double-quotes during a scalar variable assignment (as long as it's not preceded by a modifier such as `export`), so the outermost quotes are not needed above. https://unix.stackexchange.com/questions/68694/when-is-double-quoting-necessary https://unix.stackexchange.com/questions/68694/when-is-doubl... The extra quotes don't hurt, but also: use shellcheck. It will tell you if you've omitted necessary quotes.
- lloeki 3y ago
  > The extra quotes don't hurt I have the habit of quoting everything, that way I don't have to think about any corner case where I can skip quotes, and thus conversely never miss anything where I should quote. I do the same with curly braces, that way I don't have to think whether "${foo_bar}" or "${foo}_bar" was meant, and makes later adding or reading string manipulation (e.g "${haystack/needle/replacement}") or arrays (e.g "${foo[42]}" or "${foo[@]}" that much more consistent: variable references are always bounded by ${} which makes code easier to scan. I apply that to "${1}" and "${@}" too whenever possible, unfortunately bash 3.x doesn't quite like that so it's not always the case (I can't decide which one I hate more: macOS for the refusal to either update bash or outright drop it† and just have a plain posix sh + zsh, or GNU for the viral license move which is highly detrimental in practice for that case). I also often quote "semantically", e.g: # instead of: PATH="/some/path/${foo}/bar:${PATH}" /some/command "--foo=${bar}" # I'd rather do: PATH="/some/path/${foo}/bar":"${PATH}" /some/command --foo="${bar}" † I guess there's a crapton of bash scripts that have been written and possibly embedded in apps or installers, so backwards compatibility won here.
  - stouset 3y ago
    Are you me? :)
- stouset 3y ago
  I actually personally use `declare` frequently, particularly to make variables readonly. So in my case the quotes are necessary. Of course this has its own issues, in that subprocess exit codes are hidden, so you often need to assign then declare. But I quote everything, always, because then I don’t have to rely on remembering when it’s necessary and when it isn’t. Just do the safe thing every time and you don’t have to think.
tpoacher 3y ago
no, you should only quote things that you want quoted. ("duh") the caveat being if you actually do want things expanded then you should not quote them. for i in $(seq ...) comes to mind...

iforgotpassword 3y ago

Yeah that made me really anxious while reading this. That's the first thing I hammer into fresh hires and interns who are "lucky" enough to end up dealing with shell scripts.

enriquto 3y ago

> paths may contain spaces what kind of savage puts spaces on their paths? Failing in such cases is a neat feature it would seem. I never understood why common filesystems allow this foolishness. There are already other semantically meaningful characters in paths that are forbidden, like '/' or '\0'. Disallowing bare spaces in filenames is such a natural feature that it makes no sense to deal with all this stupid quoting pain. Any space that is entered by a user in a filename context should be transparently translated to a unicode non-breaking space. Most users wouldn't notice, and shell scripts authors would be much happier!

rurban 3y ago
> what kind of savage puts spaces on their paths? Failing in such cases is a neat feature it would seem. windows noobs (as in embedded development), but more likely grabbed music.
lifthrasiir 3y ago
Failing in the way that it is virtually not fixable (e.g. Windows user names) or destructive (e.g. removing some unrelated directories) is not neat. It is even often said that Windows had a space in `C:\Program Files` (now `C:\ProgramData`) in order to make sure that app developers have to handle paths with spaces correctly. Don't know if it's indeed true, but at least it's believable.
CorrectHorseBat 3y ago
It's much worse than this. On Unix '\000' (NUL) and '\057' (/) are the _only_ things that are not allowed. Anything else, whether it's valid in any encoding or not, is allowed.
- ykonstant 3y ago
  In order to test my shell scripts, I have a directory hierarchy of filenames generated from /dev/urandom, which contains a sub-structure with filenames in unary, using only the newline character.
lmm 3y ago