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