Date: Wed, 1 Aug 2018 09:40:12 -0400 From: Greg Wooledge <wool...@eeg.ccf.org> Message-ID: <20180801134012.r6ojiewtx3npa...@eeg.ccf.org>
| https://lists.gnu.org/archive/html/bug-bash/2017-06/msg00283.html A bug in dash which as far as I can tell has since been fixed. | https://lists.gnu.org/archive/html/bug-bash/2017-09/msg00058.html A bug in bash, but I don't have a recent enough version to know if it has been fixed or not. | https://lists.gnu.org/archive/html/bug-bash/2018-01/msg00035.html This one is fixed as well (seems to have been a transitory bug as I don't see it in versions of bash I have on different systems than are newer, or older, than the one shown as affected.) | Unquoted $* or $@ is just a disaster. Don't do it. There are bugs in some shells (and just about everything else) in some edge cases (the two above related to IFS='') which it is good to be aware of. The solution is not to run away and hide, but to report the bugs and get them fixed, which is what seems to have happed with dash and the first of those three (and bash and the third) and perhaps for bash and the middle one (it certainly should get fixed if it hasn't already.) Then from the second message ... wooledg:/tmp/x$ set -- '* *' wooledg:/tmp/x$ args $* 4 args: <file2.txt> <file one.txt> <file2.txt> <file one.txt> exactly as it should be. Field splitting comes first, so the unquoted $* expands to two words, each containing a single character, '*', and then filename expansion happens. Each '*' expands to the two filenames that exist. This has nothing at all to do with $* the same happens ... (in the same environment you set up, except here I'm using the NetBSD sh rather than bash - I'm sure bash does the same) [jinx]$ v='* *' [jinx]$ args $v 4 args: <file one.txt> <file2.txt> <file one.txt> <file2.txt> There are ways to code almost everything that one wants to do, some of them hit bugs in some shells. kre