must be assumed to have something following, even if the loop itself doesn't,
so redirected fd's around func calls need to be saved. Should fix etcupdate
micron's "TN-FD-33: M510DC SSD SMART Implementation Introduction"
document.
these two values can be used to calculate the write amplication
factor:
WAF = ( A247 + A248 ) / A247
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@
perspective of the dawn of time, so "next" means "newer" and "previous"
means "older". Libedit, by contrast, uses reverse chronology and
regards history from the perspective of the present, such that "next"
means "longer ago" and "previous" means "not so long ago".
The following patch fixes previous_history() and next_history()
as proposed by Bastian Maerkisch.
But there is a related problem demonstrated by Bastian's regression
tests that his patch did not fix: next_history() can advance not
only to the newest entry, but beyond it, which core libedit cannot
do. So that feature must be implemented locally in readline.c.
With that, the last of Bastians tests is fixed, test_movement_direction().
This patch also improves libedit documentation to more clearly state
what "previous" and "next" mean. GNU readline documentation is
just as unclear, but we can't easily fix that since libedit doesn't
include its own readline.3 manual.
(Ingo Schwarze)
implementation: libedit goes to the entry with the given number
stored in the HistEvent structure, while GNU subtracts history_base,
then advances that many entries from the oldest one. If entries were
removed in between, GNU advances further than libedit.
The call sequence H_CURR, H_DELDATA, H_CURR, H_NEXT_EVDATA looks
weird, as if part of that must somehow be redundant. But actually,
the user interface is so counter-intuitive that every single step
is really required.
- The first H_CURR is needed to be able to go back after an error.
- The H_DELDATA is needed to move the cursor. Even though it takes
a pointer to ev, that structure is not filled in when the call
succeeds. H_DELDATA only moves the cursor, it doesn't tell us
the new event number.
- Consequently, the second H_CURR is required to get ev.num filled
in. But it doesn't return the data because ev has no field for
that.
- So even though the cursor is already positioned correctly,
H_NEXT_EVDATA is needed as the final step merely to get the data.
(Ingo Schwarze)
command in the current shell (so they can be restored for the next command)
in cases where it is obvious that there is not going to be a following
command to use them. This fixes the problem reported in the PR (though
there are still plenty of situations where a FD could be closed but isn't,
we do not do full fd flow eveluation to determine whether a fd will be
used or not).
This is the change that was just committed and then backed out again...
OK christos@
a fd to an unspecified high fd number, we certainly do not want to hand
that high fd off to other processes after an exec, so always set close-on-exec
on the result (even if lack of fd's means no fd alteration happens.)
This will (eventually) allow some other code that sets close-on-exec to
be removed, but for now, doing it twice won't hurt. Also, in a N>&M
type redirection, do not set close-on-exec if we don't want it.
OK christos@
completely empty, they must have something (var assignment, redirect,
or command, or multiple of those) to avoid a syntax error. This
matches the requirements of the grammar in the standard. Correct the
parser (using FreeBSD's sh as a guide) and update the man page to
remove text that noted a couple of places this was previously OK.
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@
