Committed as r277610.

The compatibility code is to stop breaking things too badly for people running an old kernel and a new world. It is not useful for running tests since it naturally pretends to support more than the kernel can deliver. It is probably best to remove it in 12-current or so.

Rebase to recent head, fix symlink.7 per pluknet@.

I have not tested this, but it looks very good.

Closed by commit rS276590 (authored by @jilles).

Apply changes requested by ngie. 'kyua test' in c063/ is happy now.

Hmm, USEM_HAS_WAITERS | USEM_MAX_COUNT compares equal to -1 and will be interpreted as a fuword32/casuword32 failure. However, this combination is extremely unlikely to happen.

Although this change makes sense, it is not required for POSIX compliance. Note that the [EINVAL] error for an invalid amode is in the "may fail" section. One reason for this is that implementation extensions or new versions of POSIX may add new amode values.

Looks good to me.

LOG_ODELAY indeed does nothing and can be removed. However, please apply this change to all non-contrib code to reduce noise: libexec/getty, libexec/rshd, usr.bin/lock, usr.bin/login, usr.sbin/timed/timedc. (It looks safest to treat release/picobsd/tinyware as contrib code given that it has not been touched/tested (?) for a long time.)

The code looks good but a bit strange in a few places. Things like \$([ -f \$se ] && echo \"-e file:\$se\") (in eval "...") cause unnecessary forks and look strange to me (as if you're writing Python in shell); instead, you could set se to the empty string if the file does not exist and expand ${se:+-e file:$se}. I think the eval will look less confusing if most of the code is escaped using single-quotes instead of double-quotes.

Excellent.

Looks good to me, although I do wonder how many incorrect applications are broken and to what degree applications benefit of the smaller list (memory and CPU time).

In D431#8, @dumbbell wrote:

In D431#4, @jilles wrote:

Although there is a change to tests/, I see new breakage in tests/regress.multitest.out/7.8. This test prints the last line of a non-empty file followed by /dev/null; this used to output an empty line but now outputs nothing. Perhaps this is correct, but if so the expected result should be changed.

This test is already broken without my change. I studied this a bit, but I'm not sure what to think:

• The sed documentation from the Opengroup website speaks about "the last line of input", without talking about file boundaries.
• Our 7.8 testcase expects this behavior.
• In GNU sed, its documentation tells that the '$' address "matches the last line of the last file of input, or the last line of each file when the -i or -s options are specified". However the real behavior (in GNU sed 4.4.2 from ports) seems to match the Opengroup description.
• Our sed(1) implements what's said in GNU sed's documentation.

Some parts are good, some parts need changes, some parts may be wrong. See per-file comments.

Another thing, it may be useful to document this extension to POSIX (processing binary data) in the man page. Per POSIX, sed input files must be text files (zero or more lines ending in '\n' of at most {LINE_MAX} and not containing '\0').

Although there is a change to tests/, I see new breakage in tests/regress.multitest.out/7.8. This test prints the last line of a non-empty file followed by /dev/null; this used to output an empty line but now outputs nothing. Perhaps this is correct, but if so the expected result should be changed.

The new version appears to work properly.

During testing, I noticed several problems with the new fdopendir():

Why is this needed? What applications does it help and what systems is it compatible with? (For example, Ubuntu 12.04's look does not support long options either.)