Currently (or when testing any shell that does not support -X) the
test will be skipped (also for [m]ksh (but not ksh93 etc) where there
is an absurdly badly named -X option, skip the new test for them as well.)
When -X appears in /bin/sh, this will verify that it is probably working
(the test is MUCH more gruelling than any rational use of -X would be.)
Currently testing ~user is too much effort to contemplate (other than
assuming that it works in order to verify that it works...) so only bare ~
is being tested for now. Maybe someday...
Right now (@ time of commit), this new test is expected to fail, as ~
expansions are horribly badly broken (have been for months, some forms
for much longer) in all but the simplest of uses. Fix for that coming
very soon.
This test will be skipped on shells (such as /bin/sh in -current as of
the date of this commit) which do not support $'...'
While here fix a typo in a comment (there are probably more...)
Add two new sh syntax test cases to check for bug fixes for the parser
problems (syntax errors unidentified) reported in the two PRs.
In the latter case, also include some tests that test similar
looking, valid, syntax - to make sure the fix for the PR does not
break code that should not fail. This is not needed for the earlier
PR as other tests, and just normal parsing, is sufficient.
These tests have been verified to fail with a current /bin/sh and to
pass with the sh updates that are to be committed soon -- and because that
fix is expected within hours, the tests are not marked as expected to
fail, just let them actually fail for now.
after than in ksh and bash, and the similar thing in zsh) for which a
request has been made for support in the NetBSD sh.
Until the support is committed, the test will be skipped.
STACKSTRNUL() bug to eventually be found. Not any of the test cases
directly - the shell running the tests (the same /bin/sh) managed to
build one of the f_variable_syntax sub-tests incorrectly, and that was
enough to eventually allow the bug to be located and squashed.
Like all good promotions, this one comes with increased work, and no extra pay.
We currently parse var expansions like "${x-"a b c"}" incorrectly
according to POSIX (and ancient tradition) though in a way that is
generally unexpcted (there are 2 quoted strings there, according
to the standard, "${x-" and "}" and 'a b c' is unquoted.) This has
never been fixed in our sh, as like in many other shells, it is just
a little unbelievable, most people expect that inside the {} is a
whole new ballpark, and everything starts again, and it does in cases
like "${x%"a b c"}" (the newer matching operators.) There have been
comments in this test explaining how the test is actually testing for
incorrect behaviour for a while now.
But I have since learned of POSIX bug #221 (2010), the resolution of which is
to make the problem case unspecified. This will not actually become part
of posix until the next major version (POSIX 8) whenever that appears (still
years away I expect) - but at least we now can feel happier about the
way our code works and not worry quite so much about testing that incorrect
code keeps working incorrectly....
produces output with a very large number of consecutive embegged \n
characters.
This test is currently expected to fail (as of commit date) but is not
marked as atf_expect_fail as the shell should be fixed to avoid the
problem quite soon. Until then almost anything might happen to the
sh that runs this test (from just plain wrong results, to core dumps,
even possibly the right results, though that's unlikely).
Whie doing this, get rid of the duplicate implementation of the
nested_cmdsubs_in_heredoc test (which was achieving nothing). I know
how I managed to do that, but on advice of counsel, I ... (it was
just a harmless waste of a tiny amount of CPU time "compiling" the test,
just like writing "x=0;" on consecutive lines....)
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@)
kre