Date: Fri, 23 Jun 2017 11:39:45 -0400 From: Greg Wooledge <wool...@eeg.ccf.org> Message-ID: <20170623153945.ga4...@eeg.ccf.org>
| That's what I always thought too, but if commonly used shells like | dash can't even agree on this, then I simply upgrade my response level | from "bad practice" to "completely wrong, don't ever do this" when | someone uses unquoted $* or $@. As Chet said in an earlier response, unquoted expansions are more often bugs than not - but not always. Anything that you attempt to apply as a "one rule to govern them all" is going to be inappropriate sometimes. Most of these issues only arise when IFS='' and while that's a perfectly valid thing to do, and useful when appropriate, it is not particularly common. In cases where IFS is not a null string, the broken implementations mostly tend to work OK (sometimes perhaps only by a fluke), and even more work properly if IFS has its default value or something similar, that is where IFS[0] == ' ' to borrow an inappropriate way of writing it. | It's not like it's ever *OK* to use them, really. Now I just consider | it totally unacceptable instead of something that needs a stern warning. No, it is, and is required, if you have what is essentially a command in the args, but which is yet to be pathname expanded, you cannot use quotes or the pathname expansion doesn't happen, you can't do eval "$*" as that will re-tokenise the input, and perhaps not split at the correct places, there are times where only a bare $* (or $@ which is the same thing, when unquoted, of course) will do. These may be rare, but just saying "never do it" is too much. kre ps: I am not saying that there is not some bash private way of accomplishing the same thing, I have no idea, but if there is, and it was used, that would then make the script non-portable.