He is still missing the double quotes, paths may contain spaces
LIB="$(dirname "$(realpath "$0")")"
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.
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}"
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.
the caveat being if you actually do want things expanded then you should not quote them.
for i in $(seq ...)
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!
> Most users wouldn't notice, and shell scripts authors would be much happier!
They would, because people want to use spaces, and they wouldn't, because there's a bunch of characters you need to quote for (in POSIX sh/bash).
The solution is to realize it's not 1986 and evolve shell scripting beyond that. Fish and zsh have done that. Probably others as well. It's not even that hard and doesn't even need to woefully break compatibility.
Oh, and even if you did somehow convince the Unix world to outlaw spaces and other special shell characters by some super-human feat of charisma, you still haven't really solved anything because there's no way in hell you're going to convince the Windows or macOS people to do that, so you're still going to end up in trouble when your spouse or grandma or boss gives you their USB drive, or sends you files (which you can conveniently no longer store), or whatnot.
Might as well argue for the moon to be painted green. It's just not going to happen.
windows noobs (as in embedded development), but more likely grabbed music.
Because back in the days of K&R the kernel just blatted out whatever bytes it was given, and the C/Unix folks refuse to even consider that old APIs might have problems and need changing.