On 02/18/15 13:27, Laurent Bercot wrote: > On 18/02/2015 11:58, Peter Pentchev wrote: >> OK, so the "not using the whole range of valid exit codes" point rules >> out my obvious reply - "do what the shell does - exit 128 + signum". > > Well the shell is happily ignoring the problem, but it doesn't mean > it has solved it. The shell reserves a few exit codes, then does some > best effort, hoping its invoked commands do not step on its feet. > It works because most commands will avoid exiting something > 125, > but it's still a convention, and most importantly, the shell itself > does not follow that convention (it obviously cannot!) > So, something like sh -c "sh -c foobar" does not report errors > properly: for 126 and 127, there's no way to know if the code belongs > to the inner shell or the outer shell, and for 128+, there's no way > to know if the inner shell or the foobar process got killed. > > Shells get away with it because when they're nested, it's usually > auto-subshell magic and users don't want to know about the inner > shell; but here, I'm trying to solve the problem for execline commands, > and those tend to be nested a lot - so I definitely cannot reserve codes > for the outer command, because the inner command may very well use the > same ones too. > > >> Now the question is, do you want to solve this problem in general, or do >> you want to solve it for a particular combination of programs, even if >> new programs may be added to that combination in the future, but only >> under certain rules? If it's the former (in general), then, sorry, I >> don't have a satisfactory answer for you, and the fact that the POSIX >> shell still keeps the "exit 128 + signum" behavior mostly means that >> nobody else has come up with a better one, either (or it might be >> available at least as some kind of an option). > > It just means that nobody cares about shell exit codes. Error handling, > if any, is done inside of shell scripts anyway; and in most scripts, a > random signal killing a running command isn't even something people think > about, and I'm sure there are hilarious behaviours hiding in dark corners > of very popular shell scripts, that fortunately remain asleep to this day. > > For execline, however, I cannot use the same casual approach. Execline > scripts live and die by proper exit code reporting, and carelessness may > lead to very obvious breakage. > > >> Personally, I quite like the idea of some kind of a pipe (be it a >> pipe(2) pair of file descriptors or an AF_UNIX/PF_UNSPEC socketpair or >> some other kind of communication channel based on file descriptors), >> even if it is only unidirectional: > > Oh, don't get me wrong, I'm a fan of child-to-parent communication via > pipes, and I use it wherever applicable. Unfortunately, the child may > be anything here, so I need something generic.
I don't follow, what's wrong with using a fd? Cause that was my idea as well: return the exit code or 255. If there's a need to differentiate between exiting 255 or a signal, an option taking a fd shall be used, and the process P will then also write to said fd the exit code, or 255 + signal number (as a string). Note the the child C has nothing to do with this here, it is P that waits for it and gets the wstat, possibly writing to the fd given as option, and it is grandparent G that needs to specify an fd to P and then read it to get the full status info. Though if you want "shell compatibility" you could also have an option to return exit code, or 128+signum when signaled, and similarly one would either be fine with that, or have to use the fd for full/complete info. > Thanks for your input ! >
