This reverts commit 027a8de6f5.
I was a bit quick on this one, and only tested error cases. Turns out,
this causes foot to hang in a blocking read(3) on the event FD.
This is because while the FD has FD_CLOEXEC, that flag is per file
descriptor. I.e. the forked copy of the event fd is closed when we
exec(), but since this isn't a pipe, nothing is signaled to the parent
process, which thus remains blocking in read(3) since its copy of the
event fd hasn't been closed.
We _could_ write a dummy value on the event fd just before exec(), but
then we wouldn't be able to catch errors from exec() self - only
errors *before* exec().
Replace the pipe we used to communicate errors after fork(), but
before exec() to the parent process with an event FD.
The overhead in the kernel is much lower to setup an event fd,
compared to a pipe.
Since we need to restore the status flags anyway, there's nothing to
gain from emitting the user notifications after dup:ing the pts file
descriptor.
On the other hand, emitting user notifications *before* dup:ing means
we can still print error messages for e.g. write(3) errors.
We (need to) set O_NONBLOCK on the pts file description before
emitting the user-notifications, to ensure we don't block in write(3).
However, since file status flags are per *file*, not per
file *descriptor*, this ends up setting O_NONBLOCK on the dup:ed
stdin/stdout/stderr file descriptors too.
Not all clients want this, or can handle this.
Thus we need to restore the original flags before exec:ing the client.
This fixes "makepkg" build failures.
The main process is blocking and waiting for us to close the error
pipe (in exec(3), via O_CLOEXEC).
Thus, pts data will *not* be processed until we've exec:d the shell.
Because of this we must not write too much and block in write(3). Do
this by setting O_NONBLOCK on the pts fd (*after* dup:ing it to
stdin/stderr/sdout) and watch for EAGAIN EWOULDBLOCK.
* Rename user_warning to user_notification
* Add warning and error types (in addition to the existing deprecated)
* Simplify logic when emitting a user notification after forking; we
don't need to copy the notification data since we're in a new
process and have total control over that memory.
This is used when spawning the slave, to set its current working
directory just before we exec() the client.
In a regular foot instance, we set the cwd from getcwd().
In a foot server instance, each connecting client sends its cwd to the
server, and we use that.
