It is indeed important to ensure that this is the complete kernel assist for posix_spawn, so we do not leave multiple versions of this around, each with their own flag.

The general approach seems good.

This seems a good approach to make things work. Malloc typically uses mutexes, so it makes things much easier if mutexes do not use malloc.

In D18926#406366, @se wrote:

I'd do not like the conversion to floating point for numbers outside the range of 64 bit integers. They violate assumptions I'd like to be able to make (e.g. that adding and then subtracting the same number leads back to the initial value in all cases).

Add test for [ERANGE] special case.

In D18926#405742, @se wrote:

The behavior is not consistent for shell arithmetic operating on parameters with or without "$" (e.g. "$((X))" vs. "$(($X))") for variables not in the range of valid integers.
This may be allowed by the standard, but is still somewhat surprising:

My original objection to \u is no longer valid since we have accepted that the ugly \ bash prompt sequences are staying.

The BLOCKSIZE assignments in share/skel are not "wrong" as such, but BLOCKSIZE seems a configuration option of little use in general. Most of the time, the -h option is more useful.

I wonder when it is appropriate to run pwd_mkdb without -p. Only when etc/passwd is considered legacy and needs to be omitted from the system?

If this is only for mounting filesystems, starting mirror/raid and the like, then the new error makes sense to me, including mapping it to EINVAL in the Linux compatibility layer.

A case could be made that it is really login(1) and sshd(8)'s job to set PWD along with chdir(2), but this will do.

In D18765#400410, @mckusick wrote:

Mirror might be able to read both sides but find that they have different values. So it would not know which one to return. Here EIO is not really the right answer as the media is fine, it is just the data that is inconsistent. So saying EINTEGRITY gives a hint that a higher level tool might be able to figure out which one was right and correct the wrong one. None of that is done today, but it is conceivable that it could be done. That said, my main intent is to return this error from UFS when it detects inconsistencies or when a check-hash fails.

A new test in bin/dd/tests that does dd if=/dev/null of=/dev/null status=none conv=trim would be nice (by not writing/trimming any bytes, it does not need a fake disk setup, but it does verify that the option is recognized). Even better would be something using md but that would need more ATF/Kyua magic.

It seems like the idea is that we're stuck with that ugly \h/\$ bashism anyway so we might as well use it.

A world-readable pidfile can be locked in shared mode by any user, which may cause the real daemon to act as if it is already running when it is not (e.g. after it crashed).

"Cookie" or "handle" are definitely good words here. The part "to position the directory descriptor to the start of the entry next to the current" could be simplified a bit to "to position the directory descriptor to the next entry" since the position cannot be in the middle of an entry.

The man page seems to contain the right content now. I just have some English language comments.

In D17547#375528, @kib wrote:

In D17547#375474, @jilles wrote:

Unconditionally allowing absolute paths with O_BENEATH seems a bit strange, as I expect this to be used for partially untrusted paths. An application can easily check for absolute paths and cause either behaviour (allowing or disallowing).

This was one of my questions. But, it is not clear to me what change, if any, you are proposing.

OUTBUFSIZ is somewhat of a strange name given that these buffers contain shell input.

I think it would make more sense to define a new buffer size constant than modifying BUFSIZ.

Unconditionally allowing absolute paths with O_BENEATH seems a bit strange, as I expect this to be used for partially untrusted paths. An application can easily check for absolute paths and cause either behaviour (allowing or disallowing).

I don't think "Show time for sorting" is better than "Use time for sorting". If you want to avoid the weak "use", something like "Sort by (with .Fl t) or write (with .Fl l) time when file ..." may be better.

This is not wrong, but perhaps some details about different types of errors may be helpful, such as that nonexistent usernames in -U are immediately fatal while an empty result (such as from only nonexistent process IDs in -p or only existing users that do not currently run any process in -U) still writes the header line (if not disabled) and also returns a non-zero exit status.

I would like to see a consistent behaviour in handling chown/chmod failures between creating directories and installing files. A -e flag looks ugly and should only be added if both behaviours are necessary in different situations.

There is actually another important difference between reboot and shutdown -r now: reboot does not run /etc/rc.shutdown. This is because reboot has its own shutdown procedure and does not signal init like init 6 and shutdown -r now do (except in the case of rerooting via reboot -r).

This is useful, but some parts seem too specific to usage in appliances.

I think this looks good except that I would like to consider a new errno again.

iflag= and oflag= would be better than inventing something new.

NetBSD and GNU instead have iflag= and oflag= operands that accept various open flags such as direct. I think that makes more sense, even though conv=notrunc could be considered to belong with oflag instead (but does not for historical reasons).

In D16075#340644, @eadler wrote:

For my edification: the two possible solutions to cast alignment are (a) memcpy and (b) aligned_alloc. The issue with the latter is that the compiler likely won't understand it, and thus still warn.

Perhaps the alternative of listing and extracting iso images using tar(1) can be mentioned as well.

Looks good to me apart from the comment. Sorry for the delay.

Thanks for working on this, but I think pedantic compilation modes should be kept working.

I agree that the man page should be changed, but I think it can be done better.