These should detect if the errors that caused MAKDEV to fail and
pkgsrc/pkgtools/cwrappers to fail to build (problem detected in
libnbcompat/configure) ever return.
Also fixed one of the other sub-tests so that it actually does what
it should - no idea how this one has been passing, it did not for me
when I was checking the new ones (but perhaps in the interim I have
fixed something else in sh, the problem was in the area I have been
playing, and I originally debugged the new tests using a newer version
of /bin/sh than has yet been committed.)
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.)
as to why ${011} is ${11} and not ${9} (that is, why we interpret it
that way, the "why could it not be the other way?" is just "because
that is not how it was ever implemented".
piece of mind (to verify I was not breaking anything here.)
Also added some commentary better explaining why one of the tests of splitting
quoted variable expansions is almost certainly incorrect (both the tests,
and what sh does) ... though bash does the same as us, so all is not lost!
whose meaning is defined entirely by context.
For those who read commit messages, and want a (small) challenge,
work out where (and what) to insert as punctuation/operator chars
in the following to produce 3 ines of output, and what those will be:
for in in in do in do case in in in echo do do echo in esac done
(There are no comments, quotes of any kind, or any kind of sub-shell,
including cmd substitutions) With correct non alpha-numeric chars added,
it works.
but with \ newline line continuations inserted at strange places.
For the shell as it is today, since strip passes, wrap_strip should
automaticallty pass as well (and does), as the \ newline combination
is simply removed, producing identical input to that of strip.
However, for accurate line counting ($LINENO: coming soon) newlines (no
matter the context) cannot simply "go away" - we have to know where they
occur(ed) (perhaps long after the text was read) so we know what line
number we are actually processing. This new test case is (perhaps just
part) of future-proofing that the modified code does not break anything.
Upi really (really!) don't want to know!
Also, add a comment (in another section) and avoid giving messages
to atf_fail that include newlines - AFT really doesn't like that.
Instead, convert the \n's to ;'s so at least the content is retained.
contain a # character, can get parsed (which amounts to 86 extra checks,
any Australian can tell you why I decided to stop there and not add one
more...)
Add 5 new test cases to test various ways that $* can be expanded.
Currently 3 of the 5 are marked as "expected to fail" because of the
bug in this PR.
ash based shell bug
echo ${unset_var##$(echo a)}$(echo b)
should say "b" but instead says "a" ... the first "echo a" is not
evaluated because it cannot possibly match an unset variable, but is
not removed from the list of command substitutions, when the shell
needs to execute the 2nd cmdsub, "echo b" should be at the head of
the list, but isn't, "echo a" is still there...
This test should fail (for now) - should show 4 of 40 subtests failing.
It isn't marked as atf_expect_fail as the fix for this will be coming
later today (I will just wait at least 1 b5 build cycle so the failure
can be observed).
Detecting the bug, and the fix, are from FreeBSD.
redirection works correctly (including that the bugs reported in those PRs
are fixed.) Note that the tests for 48875 are slow, so one of the new
test cases ends up running > 25 seconds (just doing sleeps) - each individual
test is just a few seconds, but there are several of them.
OK christos@
behaviour (and failed with the NetBSD shell, and was marked as expected to
fail.) Other shells do different things. The test was worthless, and is
now gone.
OK christos@
file descriptors outside the 0..9 range, and complex fd
reassignments. Also test that the shell can cope with the
value of ulimit -n changing (downwards, up is harmless)
(Freom kre@)
redirect operator inside the ``. Move the one similar test using
$( ) into its own test case (and expand that test as well.
The `` case was omitted before, as no shells (including NetBSD) were
parsing it correctly, Now the NetBSD shell does, so ... (from kre@)
producing (( (when the cmd starts with a '(' as that as a reserved
sequence (according to posix) and some shells do treat it specially.
So, force a space after the enclosing '(' to avoid the problem.
For symmetry, put a space before the concluding ')' as well, though
there is nothing special about )). (from kre@)
use printf %s instead of echo, as there are embedded \ chars in
some of the strings, and some other (nameless) shells insist on
treating \ in the args to echo as something special... (from kre@)
that could be interpreted as something different. That is, for our
shell +4++3 is just (+4)+(+3) and works fine. But others treat ++
as the increment operator. Same for --. Sprinkle spaces to taste.
(from kre@)
to wait for the same process over and over again (forever) (???)
This test now takes slightly over 20 seconds to complete (elapsed
time) caused by all the waiting on sleep commands being run in
the background. (from kre@)
work, now anyway) rather than working around a defect by using
/bin/kill (if the shell is broken, the test should fail, not succeed)
and test more aspects of the wait builtin in the kill test. (from kre)
that is not required by the standard. The test now allows either
of the two allowed responses. Also add commentary correcting
erroneous comments about what is correct, and incorrect. (from kre)
to the name of a shell, plus options that shell needs to run it
in the correct mode to be tested: eg: TEST_SH='bash -o posix'
Also finished the implementation of tests of "set -n" now that
the NetBSD shell supports that as it should. (from kre)
inside dot commands:
The test cases are named with the pattern
dotscope_cmd_cmdscope,
where dotscope is the scope in which the dot command is and cmdscope
is the scope where cmd is in the sourced file.
sh +nounset and `for X; do` iteration fails if parameter set empty
by applying and testing FreeBSD's patch of Oct 24 2009 for this; see
http://svnweb.freebsd.org/base/head/bin/sh/expand.c?r1=198453&r2=198454
Also created an ATF test in tests/bin/sh/t_expand.sh for this error and
corrected a space->tabs problem there as well.
kre