signal-handling problems for "dd": some thoughts

[Paul Eggert]

I looked into GNU dd's signal handling and found some problems.

The biggest is that GNU "dd" appropriates SIGUSR1 to mean "please
issue a progress report on stderr".  POSIX doesn't allow this
behavior: it requires "dd" to immediately exit when it gets SIGUSR1.
Also, it's very difficult to implement SIGUSR1 support correctly: for
example, the SIGUSR1 might interrupt a read or write to a slow device,
causing "dd" to get a short block.

The simplest fix is to remove SIGUSR1 support from GNU "dd".  But this
raises the issue: how many people use this "progress report" function?
If there's a real need for it, we should provide it, but perhaps in a
different way -- perhaps, for example, the user could specify a file
descriptor that could be used to interrogate dd's status.

If we do want to retain support for status reports triggered by
SIGUSR1, I propose that this behavior be enabled only upon explicit
user request, e.g., "dd stats=1".  This would conform to POSIX.
However, I don't see any way of implementing it reliably for slow
devices (short of having "dd" become multiprocess or multithreaded,
which sounds pretty extreme), so in this case "dd stats=1" should be
documented be buggy with slow devices.

I can send you more details if you like, including a (undoubtedly
buggy) draft of support for SIGUSR1 with an explicit stats=1 option.