9817a5b1e5
by IFS just the same as any other expansion (split when they should be,
and not when they shouldn't).
Good thing I did ... this discovered a regression in the new expand
code (from an hour or three ago) where quoted arith expansions are
being split, and shouldn't be. (on the other hand, when they should
be split, they are being split correctly, so that's good...)
No need to worry too much about this, in real life (as opposed to
torture tests) no-one ever puts digits in IFS, and a $(( )) expansion
only ever contains digits, so in practice, splitting never happens,
whether because it is quoted, or just becaue there is nothing to split.
The FreeBSD shell does it correctly (they do word splitting using a
totally different mechanism than we do) - I will find where I missed
testing for quoted expansions later tonight. Until that happens,
expect a test failure from t_fsplit:split_arith
While here add more comments in the other test casess (one had a comment
already) that our shell parses incorrectly (this is a parsing problem,
not an expansion problem, and the bug has existed forever .. and is
shared by bash).
That is, in an expression like "${var:-word}" the whole thing (including
word) is quoted by the double quotes, and in "${var:-"word"}" the
expansion is quoted, but 'word' is not, the 2nd " (the one before 'w')
ends the opening quote, and the third (before }) turns quoting on
again (it is required that there be an even number of unquoted quotes inside
a ${} expression, so things like "${var:-"word} are simply invalid.)
Another way of saying this, is that if the { is quoted (for which the
only way is using " to get to this kind of expansion at all) the }
must also be quoted (" quoted). There is no quote nesting here.
This also means that in "${var:-'word'}" the single quotes are just
characters, they are quoted by the "" that surround them, just as in
"a 'string' containing quotes", but "${var:-"'word'"}} is valid and
contains a single quoted word.
Note that this is different than the patetrn-match/trim expansions
( ${var%pattern} etc) where any surrounding quotes do not affect the
pattern, and all forms of quoting can be used in it - but it always
parses as a pattern, and is never subject to filename expansion, so
a '*' in it that is to mean "match any string" does not need special
quoting to avoid it expanding to file names, regardless of whether
the ${var%*} is quoted or not, but a * that is to be matched as a
character literally does need to be quoted.
I will probably file a PR about this bug sometime, but as it is
very old, and doesn't every seem to bother anyone (and is shared by
bash) there isn't any big hurry to open yet another verry messy can
of excrement to fix it...
This does mean that the FreeBSD shell "fails" some of our tests.
(The test is wrong, their shell is correct.)
|
||
|---|---|---|
| .. | ||
| bin | ||
| crypto | ||
| dev | ||
| fs | ||
| games | ||
| include | ||
| ipf | ||
| kernel | ||
| lib | ||
| libexec | ||
| modules | ||
| net | ||
| rump | ||
| sbin | ||
| share | ||
| sys | ||
| usr.bin | ||
| usr.sbin | ||
| Makefile | ||
| Makefile.inc | ||
| README | ||
| h_macros.h | ||
README
$NetBSD: README,v 1.4 2012/05/18 15:36:21 jruoho Exp $ When adding new tests, please try to follow the following conventions. 1. For library routines, including system calls, the directory structure of the tests should follow the directory structure of the real source tree. For instance, interfaces available via the C library should follow: src/lib/libc/gen -> src/tests/lib/libc/gen src/lib/libc/sys -> src/tests/lib/libc/sys ... 2. Equivalently, all tests for userland utilities should try to follow their location in the source tree. If this can not be satisfied, the tests for a utility should be located under the directory to which the utility is installed. Thus, a test for env(1) should go to src/tests/usr.bin/env. Likewise, a test for tcpdump(8) should be in src/tests/usr.sbin/tcpdump, even though the source code for the program is located under src/external. 3. Otherwise use your own discretion.