Jim Meyering <[EMAIL PROTECTED]> 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.) _______________________________________________ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
