Re: signal-handling problems for "dd": some thoughts

[Paul Eggert]

Jim Meyering <address@hidden> writes:

> for progress reporting, don't we need to block only
> one signal (SIGUSR1) while e.g., reading?  Of course, that'd mean no
> progress reporting during a read, but that doesn't seem too restrictive.

If dd is reading from a fast device it's no problem, but if dd is
reading from a slow one (e.g., a pipe from who knows where) it could
be pretty annoying.

> I liked the idea of being able to decide, after starting a transfer,
> to enable some sort of progress-reporting mode.  Sometimes, it seems
> like it's taking too long and/or one can't easily tell that it's
> making progress.

That's what BSD's SIGINFO is for.  Unfortunately "dd" can't use
SIGUSR1 for this and still conform to POSIX.  Also, I think the
utility of appropriating SIGUSR1 for this is fairly limited: how many
users know how to put "dd" into the background, find its process-ID,
send a SIGUSR1 to it, put it back into the foreground again so that
you can see the output, etc.?  Or to start up another window, find out
the dd process ID, and send a SIGUSR1?  It's much more convenient in
BSD where you just type control-T.

The simplest fix to the POSIX-conformance problem is to change "dd" so
that it doesn't enable the feature unless SIGINFO is defined.  This
conforms, since POSIX doesn't specify SIGINFO.  And it enables the
feature on BSD hosts, which have control-T.

I suppose we could fall back to some other non-POSIX signal if SIGINFO
isn't defined.  In practice, SIGPWR seems to be the most popular
"replacement" for SIGINFO; e.g., on some Alpha Linux kernels they're
the same signal.  However, I suspect such a fallback won't be any more
useful than SIGUSR1 is.

After hacking in this area I'd rather not use a
signal-handling-oriented interface for progress-bar reporting:
signal-handling is too flaky internally.  For "dd", for example, I'd
rather have it output a "wget"-style progress report (or perhaps
something more machine-readable) to stderr periodically.  This
wouldn't require any signals internally.  POSIX allows this behavior
even without an option to enable it, since POSIX allows "dd" to output
whatever it likes to stderr.  And that way, users wouldn't have to
know about SIGUSR1, SIGPWR, SIGINFO, or control-T: they'd just see a
progress report, which is what they often want.

(POSIX also allows "cp" etc. to output a progress report to stderr
periodically.  This might be a bit much.  But perhaps we should just
experiment with "dd" first, since it already has a problem, before
worrying about "cp" etc.)