This tested #1728, where redirecting a directory (`begin; something;
end < .`) would cause `status` to misbehave.
Unfortunately, on Illumos/OpenIndiana/SunOS, this returns a different
error (EINVAL instead of EISDIR), so we can't check that with our test harness, because
we can't redirect it.
Since it's not important that this gives the same error across
systems (and indeed we provide no way of intercepting the error!),
use an invocation test instead, because that allows different output per-uname.
See #5472.
This teaches the status command to work with features.
'status features' will show a table listing all known features and whether
they are currently on or off.
`status test-feature` will test an individual feature, setting the exit status to
0 if the feature is on, 1 if off, 2 if unknown.
The `status` command currently silently allows incompatible flags (i.e.,
subcommands). Too, using flags to specify subcommands misleads the user
into thinking they can specify multiple subcommands.
We recently modified the `history` command to deprecate using flags for
subcommands. This change does the same for the `status` command.
Fixes#3509
Instead of globally marking the state as "in block" when evaluating
blocks/functions, update the "in block" status when pushing/popping
blocks on the parser stack.
Fixes#1729.
On a side note, `status -b` is actually pretty useless, because it
always returns 0 inside of a function (even without this patch).