This is more consistent, and probably more useful (while read loops tend not to treat EOF and read errors differently).

OK, but perhaps this fix should be in libedit instead. The same issue can be seen in other libedit clients such as ftp(1).

This functionality clearly fills a gap, but the provided interface is too low level for applications to call. The code in lib/libc/gen/posix_spawn.c uses various non-standard facilities to handle things like signals correctly. Depending on how this is planned to be used, additional libc code may be useful, but it need not be part of this review.

In D30464#689064, @stephane.rochoy_stormshield.eu wrote:

In D30464#685956, @jilles wrote:

Looks reasonable, assuming veriexec itself is reasonable (in many cases, it seems to me that verifying the root filesystem would be a simpler and more reliable approach).

The -- was added so that source pathnames starting with - would not break. I guess destination pathnames starting with - already did not work before D25551, so that was not a regression. This could be fixed differently by prepending ./ if the name starts with -.

In D30498#686136, @fernape wrote:

As this is a small fix to the EXAMPLE, is it necessary to bump .Dd at commit time?

Looks reasonable, assuming veriexec itself is reasonable (in many cases, it seems to me that verifying the root filesystem would be a simpler and more reliable approach).

In D30330#681137, @a.wolk_fudosecurity.com wrote:

Unfortunately, some ports like PostgreSQL redefine start_cmd which would make _oomprotect="ALL" silently not work for the database. I am not sure where it would be a good place, but I think it would be worthwhile to document that redefining ${name}_cmd has such a pitfall.

The comment is correct. LOG_PID has no effect and the process ID is always included. This change was made along with the move from RFC 3164 to RFC 5424 log messages.

Some people may get negatively surprised if they first encounter this change in a git update. A post to -current@ and Relnotes: yes are probably a good idea.

I like it better if EFAULT is reserved as much as possible to the case where a syscall argument points to an invalid memory location for the calling process, which is undefined behaviour according to POSIX and other standards and often behaves poorly (for example, completing an operation but discarding the result). If the address in the target process passed to PT_READ_I is invalid, this is fully defined and may not be fully avoidable (for example if the traced process is running concurrently).

There should be documentation about this in the man page.

In D29493#661261, @bapt wrote:

@jilles do you think we should add an option to disable the load and save so people willing to have a giant history while not suffering from the load/save can do it? if yes do you have any options to suggest?

Note that this can still be overridden via $EDITRC, ~/.editrc or a bind command after set -o emacs.

Another nice feature, but I expect that making it good enough to replace bigger shells will take more work. For example, the save-all/load-all approach may be rather slow with the number of history entries I personally like to keep.

Nice feature.

Perhaps it makes more sense to implement this as a separate program that performs setsid() and then execvp(). This is a bit like daemon, but not quite, since daemon also forks and makes it hard to track the child process. As noted in the man page, sh tends not to implement many extensions. Extensions like set -o trapsasync and set -o pipefail are different from this one because they are hard to implement outside the shell or in a shell script. Of these, set -o pipefail is particularly simple to implement in the shell.

This was reported before as https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218598 but I did not know for sure what to do so I left it alone. Since the patch is essentially the same, perhaps we should make this change. The wording of the error message in the patch in the PR seems a bit more formal, so better.

In D27310#610450, @kib wrote:

I do not see this EINTR and EINPROGRESS change in the most recent version of POSIX I have, IEEE Std 1003.1™-2017.

The referenced austin group ticket even went as far as propose posix_close() with some retry flag, which again was not added. More, there were strong objections from Linux side arguing that EINTR behavior should be as it is de-facto implemented by Linux and FreeBSD: file is always closed.

Restarting a close() would indeed be very bad, but returning [EINTR] might cause userland to do the same.

Having this kind of possibly mysterious errors documented is very useful.

My suggestion is to change all the exit statuses that were changed to sysexits codes here to 2 instead.

In D27216#607710, @gbe wrote:

In D27216#607705, @jilles wrote:

A pthread implementation "libc_r" was already added in 2.2-release, which contained most of these functions.

A pthread implementation "libc_r" was already added in 2.2-release, which contained most of these functions.

Exit statuses should implement a protocol between the calling and called process. Since only 8 bits (or 32 if the calling process uses waitid()) are available, there is not much flexibility. I think distinctions between different exit statuses should have a purpose, while most of the sysexits codes categorize errors without a clear purpose. If more flexibility is needed, a channel with more capacity should be used.

This complies to https://www.austingroupbugs.net/bug_view_page.php?bug_id=508 which is planned for POSIX issue8 (in a few years).

Perhaps it is better to match sockstat (D26413) and make the option -C instead of -c.

I found a reason to touch this code, but otherwise I'm a bit surprised about a change here.

This change may cause breakage in setups where the chroot does not have /etc/pwd.db and related files. Given that chroot(8) has worked like this since 2003, why change it now?

I think the best way forward is to start with -@ first and leave -l output as it is, at first.

Since struct timeval is mostly obsoleted by struct timespec, I suggest adding this only when there is existing code using it.

In D25033#551601, @kevans wrote:

In D25033#551509, @jilles wrote:

The dup2 part looks good.

The dup2 part looks good.

Although there is nothing wrong with this per se, applications can deal with this problem more easily using getline(3) (which is also standard).

read(2) on a directory seems only useful for educational or debugging purposes. These purposes are better served by a different API.