[Bug 3547] shell read is maybe too safe

[Laurent Bercot]

> There is no reason for a correct program to ever check for EINTR
> unless it specifically installs signal handlers and fails to specify
> SA_RESTART for them. Checking for ret==-1&&errno==EINTR in your read
> loop is purely bloat that does not belong in most programs.

 Well, I disagree, and I'll keep disagreeing until there's a release of
the Single Unix specification that says explicitly that the default
behaviour for every signal that does not terminate the process MUST be
SA_RESTART.

 I agree with Denys that it would probably be the best fix. But until
that day, color me paranoid, I'm keeping my safe wrappers.


>>  Does that mean that when you write a shell, you completely forbid
>> yourself to use internal file descriptors ? You are not allowed to use
> Yes it means that.

 Then the shell specification is even more demented than I first thought.
Great: one more paragraph to add to my anti-shell rant at
 http://www.skarnet.org/software/execline/dieshdiedie.html

 Seriously, Unix system programming without opening files. Awesome.

 And how do you manage the fd that has to be kept open to read the
script, when the script is in a file ? Do you read all the script into
memory then parse it from there ? Or do you somehow make an exception ?
If you're making an exception for one fd, you might as well allow
yourself more leverage and reserve a range of private descriptors.


> Are you thinking of that epoll nonsense? poll does not need a
> dedicated file descriptor.

 No. I'm thinking of poll() and asynchronous handling of stdin,
signals (via a selfpipe or signalfd) and other events I'm not thinking of
right off the bat. If you're only allowed to listen to stdin and no other
single fd, there's not much you can do asynchronously - not with the poll()
model anyway.


> Hideous hack.

 YMMV. It's either that or jumping through hoops to make things work
without opening a single descriptor, and some of these hoops look more
hideous to me than reserving a few descriptors for private use. We're
talking about busybox where things should be kept as simple as possible;
writing a shell is difficult enough as is, giving yourself even more
constraints doesn't sound like a good idea, unless you're going for the
hacking value instead of the maintenability.


> This is what pselect() is for.

 pselect() is a horrible API, but I agree that in this case it could be
useful. You really have to hate open descriptors to use it instead of a
selfpipe, though.


> Or you could use threads. :-)

 Yes, you could. And triple the complexity of your shell. This is busybox
we're talking about, again, not GNU bash ;)

-- 
 Laurent