CVS log for src/tests/bin/sh/t_fsplit.sh

Up to [cvs.NetBSD.org] / src / tests / bin / sh

Request diff between arbitrary revisions

Keyword substitution: kv
Default branch: MAIN

Delete the dummy "always fail" test.

It has demonstrated that the code elsewhere will successfully
handle sub-test errors, should any occur, so has served its purpose.

Always run all sub-tests in a test case.

Previously, as soon as a sub-test in a test case failed,
the sub-test failed along with it, and no further sub-tests
were run, which would mean "fix one, run it again, fix
another, run it again, ...".   Now all the sub-tests that
fail are reported in each run.   Many of the other sh
ATF tests work the same way (approximately anyway).

This does mean that it is no longer possible to do (as was
once done here)

	atf_expect_fail "whatever reason"
	run_the_sub_test
	atf_expect pass

to allow for just one known sub-test to fail, and expect all
the others to work, as the individual sub-tests no longer atf_fail.

This change would have made no observable difference, as all
the sub-tests in all the test cases currently pass.

That's no fun!   So I added a new test case which contains a
bunch of sub-tests, some of which fail.   Don't bother attempting
to work out why, they fail because they were deliberately broken,
that is, broken in the test, not in sh.

Once this update has settled for a day or so, I'll remove that
new test case again (its sub-tests were simply stolen from other
test-cases, there's nothing new, and then some mangled, so they
fail).

While here, since there were (more or less rote) changes throughout,
some sh formatting style changes, 80-col, ..., slipped in as well.

Test field splitting as used by the read built-in.

This includes a couple of sub-tests which test for the bug from
PR bin/58749

Other aspects of read should be tested elsewhere (someday).

NFC:   Added some comments (about other comments)

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....

Paranoia:   add a new test case testing that $(( )) results get split
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.)

Add some extra sub-tests checking splitting of ${#var} - just for my
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!

Finish TEST_SH - all tests should support it now.
Misc other KNF changes, minor bug fixes, and a few minor
extra tests added. (from kre@)

Set TEST_SH

Added more test cases, more exhaustive testing. (from kre)

sync with head

file t_fsplit.sh was added on branch yamt-pagecache on 2012-04-17 00:09:02 +0000

Deprecate tests/util.