If the path to the dir is longer than $HOME, say, $HOME/Tools/modding/hd2-audio-modder/wwise/v123456789_idr_but_its_a_long_one/random file name with spaces, it makes more sense.
I’ll try using the braces syntax, if it does prevent word splitting I wasn’t aware of it, though it’s still slightly inconvenient (3 key inputs for each brace on my kb) and I’d probably still use quotes instead if I had to use Bash and had the file path in a variable for some reason.
… though at this point I’m probably overthinking it, atm I don’t recall better examples of my distaste for Bash expansion shenanigans.
Did some testing, here’s what I found.
Beware, it devolves into a rant against Bash and has little to do with the original topic - I just needed to scream into the void a little.
# Zsh
function argn { echo $#; }
var='spaced string'
argn $var
# Prints 1: makes sense, no word splitting here
var=(array 'of strings')
argn $var
# Prints 2: makes sense, I'm using a 2-wide array where I would
# want 2 arguments (the second one happens to have
# a whitespace in it)
# Bashfunctionargn{ echo $#; }var='spaced string'
argn $var# Prints 2: non-array variable gets split in 2 with this simple reference;# I hate it, but hey, it is what it is
argn ${var}
# Prints 2: no, braces do not prevent word splitting as I think you suggestedvar=(array'of strings')
argn $var# Prints 1: ... what?echo$var# Prints array: ... what?!?# It implicitly takes the first element?# At least it doesn't word-split said first element, right?var=('array of' strings)
argn $var# Prints 2:
Upon further investigation:
# Bashmkdir /tmp/bashtest ; cd /tmp/bashtest
touch'file 1'touch'file 2'stat file*
# Prints the expected output of 'stat' called on both files;# no quotes or anything, globbing just expands into# 2 arguments without *word* splitting
files=('file 1''file 2')
stat$files# stat: cannot statx 'file'# stat: cannot statx '1'# WHY? WHY DOES GLOBBING ACT SENSIBLY WHEN ARRAYS DO NOT?
I get that the Bash equivalent to Zsh’s $array is ${array[@]}, but making $array behave like it does in Bash has no advantage whatsoever.
… IS WHAT I WOULD SAY IF THAT WERE TRUE! YOU ALSO HAVE TO QUOTE "${array[@]}" BECAUSE WE LOVE QUOTES HERE AT BASH HQ!
# ... continued from beforestat"prefix ${files[@]}"# stat: cannot statx 'prefix file 1'# (regular 'stat' output for 'file 2')
While this behavior doesn’t make much sense to me, it also doesn’t make sense for me to write that “prefix” within the quotes in the first place, right?
YES. BECAUSE SPLITTING IS NOT WHAT YOU EXPECT WHEN YOU PUT STUFF IN QUOTES.
My bad, I was thinking of zsh. And I think it’s configurable there too so may not behave that way according to your settings. But it is at least the default on Mac.
I use Zsh too, though at this point is becoming detrimental to my (already limited) Bash skills because of features like the ${^array}{1,2,3} syntax which I use in some scripts of mine, which in turn I wouldn’t dare try to translate to Bash.
If the path to the dir is longer than
$HOME
, say,$HOME/Tools/modding/hd2-audio-modder/wwise/v123456789_idr_but_its_a_long_one/random file name with spaces
, it makes more sense.I’ll try using the braces syntax, if it does prevent word splitting I wasn’t aware of it, though it’s still slightly inconvenient (3 key inputs for each brace on my kb) and I’d probably still use quotes instead if I had to use Bash and had the file path in a variable for some reason.
… though at this point I’m probably overthinking it, atm I don’t recall better examples of my distaste for Bash expansion shenanigans.
Did some testing, here’s what I found.
Beware, it devolves into a rant against Bash and has little to do with the original topic - I just needed to scream into the void a little.
# Bash function argn { echo $#; } var='spaced string' argn $var # Prints 2: non-array variable gets split in 2 with this simple reference; # I hate it, but hey, it is what it is argn ${var} # Prints 2: no, braces do not prevent word splitting as I think you suggested var=(array 'of strings') argn $var # Prints 1: ... what? echo $var # Prints array: ... what?!? # It implicitly takes the first element? # At least it doesn't word-split said first element, right? var=('array of' strings) argn $var # Prints 2:
Upon further investigation:
# Bash mkdir /tmp/bashtest ; cd /tmp/bashtest touch 'file 1' touch 'file 2' stat file* # Prints the expected output of 'stat' called on both files; # no quotes or anything, globbing just expands into # 2 arguments without *word* splitting files=('file 1' 'file 2') stat $files # stat: cannot statx 'file' # stat: cannot statx '1' # WHY? WHY DOES GLOBBING ACT SENSIBLY WHEN ARRAYS DO NOT?
I get that the Bash equivalent to Zsh’s
$array
is${array[@]}
, but making$array
behave like it does in Bash has no advantage whatsoever.… IS WHAT I WOULD SAY IF THAT WERE TRUE! YOU ALSO HAVE TO QUOTE
"${array[@]}"
BECAUSE WE LOVE QUOTES HERE AT BASH HQ!# ... continued from before stat "prefix ${files[@]}" # stat: cannot statx 'prefix file 1' # (regular 'stat' output for 'file 2')
While this behavior doesn’t make much sense to me, it also doesn’t make sense for me to write that “prefix” within the quotes in the first place, right?
YES. BECAUSE SPLITTING IS NOT WHAT YOU EXPECT WHEN YOU PUT STUFF IN QUOTES.
Sorry, I’ll stop.
My bad, I was thinking of zsh. And I think it’s configurable there too so may not behave that way according to your settings. But it is at least the default on Mac.
I use Zsh too, though at this point is becoming detrimental to my (already limited) Bash skills because of features like the
${^array}{1,2,3}
syntax which I use in some scripts of mine, which in turn I wouldn’t dare try to translate to Bash.