On 09/05/2015 01:13, Guillermo wrote:
> Are we not supposed to use pipeline or forbacktickx with a closed
> stdin, or is this something that needs fixing?
Honestly... both. It's Complicated (tm).
I read your mail yesterday, shortly after you wrote it, but it
opened a rabbit hole in more than one way. And the correct answer
is: both.
I consider it a bug, because there are cases where I do need to
run programs with fds 0, 1 or 2 closed, and I generally try to
pay attention to this. So I've pushed a fix to the current execline
git, please tell me if it works for you.
However, POSIX considers that UB is acceptable when you run a
program with 0, 1 or 2 closed: look for "If file descriptor 0" in
http://pubs.opengroup.org/onlinepubs/9699919799/functions/execve.html
So, stricto sensu, it's a case of "don't do that" - it's acceptable
for pipeline, and other programs, to fly demons through your nose
when you run it with stdin closed.
And Unix primitives do not make it easy to support that case
without bugs. I have run into that problem before, and your report
is just another incarnation of the problem, and I'm sure there are
other similar ones hiding in my code.
Whenever you open a file, Unix guarantees that the descriptor you get
is the smallest unused number. So if you run a program with 0 closed,
when the program opens something, or creates a pipe, or anything that
requires a descriptor, descriptor 0 will be used. If you then need to
exec into a program with 0 redirected, you should pay attention to
not overwrite your (internal) descriptor 0 when you dup2() into it.
And dup2() when both descriptors are the same does not clear the
close-on-exec flag, which leads to the problem you observed.
I'll try to support the case as much as I can, and squash those bugs
whenever they're found, but still, don't do that - Big Bad POSIX will
bite you if you do.
--
Laurent
Received on Sat May 09 2015 - 17:06:47 UTC