4 ms·

This article is obvious bait. It has to be. You choose to expand a variable and then complain about not wanting the expansion? Or about the behaviour of clear

This article is obvious bait. It has to be. You choose to expand a variable and then complain about not wanting the expansion? Or about the behaviour of clearly documented special variables doing exactly what they're supposed to instead of something another special variable does? What are they unhappy about exactly, they don't like the symbol that was chosen?? These are all things you find out within minutes of reading the manpage. (one of the best written manpages out there, in fact). Heck, this isn't even a "cannot whitespace" problem. It's expanded vs unexpanded tokens. Which is a feature of the language. Because it's text/stream based (not "despite"). 35 years of shell experience? I call bait.

wodenokoto 3y ago
Just because something is documented doesn't mean it is not crappy. I agree with the author, that just like how | aren't interpreted in `echo $myvar` neither should spaces. I also agree that `mv "$i" "$(suf "$i")" is unnecessarily cumbersome.
- tpoacher 3y ago
  Indeed. Which is why you should use the built-in parameter expansion provided by bash for easily removing a suffix, instead of an external program. The thing about spaces (and expansion more generally) as I understand it is this. At some point the bash designers had a choice how to represent expanded, unexpanded, and verbatim strings. One could argue that verbatim should have been the default, with expanded using single quotes, and unexpanded using double quotes, such that you would only get expansion if you really wanted it. This might have been my choice if I had designed it. I'm guessing, however, that the designers quite reasonable went for the opposite logic, which was, if you use a $ in your string, you're probably after expansion, rather than a verbatim $ symbol (and you can always escape it in the unlikely scenario that you did want a verbatim one). So presumably they chose expanded as the default because it would be the most common, leaving single quotes for verbatim instead.

wodenokoto 3y ago

Just because something is documented doesn't mean it is not crappy. I agree with the author, that just like how | aren't interpreted in `echo $myvar` neither should spaces. I also agree that `mv "$i" "$(suf "$i")" is unnecessarily cumbersome.

tpoacher 3y ago
Indeed. Which is why you should use the built-in parameter expansion provided by bash for easily removing a suffix, instead of an external program. The thing about spaces (and expansion more generally) as I understand it is this. At some point the bash designers had a choice how to represent expanded, unexpanded, and verbatim strings. One could argue that verbatim should have been the default, with expanded using single quotes, and unexpanded using double quotes, such that you would only get expansion if you really wanted it. This might have been my choice if I had designed it. I'm guessing, however, that the designers quite reasonable went for the opposite logic, which was, if you use a $ in your string, you're probably after expansion, rather than a verbatim $ symbol (and you can always escape it in the unlikely scenario that you did want a verbatim one). So presumably they chose expanded as the default because it would be the most common, leaving single quotes for verbatim instead.