Re: too much for an NMU?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Thread: STDERR for "Press Hotsync" Message
Dearest Pilot-List:
Short Form:
STDERR is for things dealing with how the program does what it's doing
(diagnostics). STDOUT is for things dealing with what the program is
actually doing in the abstract (conventional output). Press Hotsync
clearly has much more to do with how the program is doing what it's doing
than with what the program is trying to do--so it should be on stderr
(just like "Insert Next Tape").
Long Form:
> It seems to definately be part of the "normal process" to me - it
> comes up every single time you start the program, so that's pretty
> normal!
Not generally. There is no guarantee whatsoever that the Palm will
continue to behave that way. Also, that prompt is often superfluous if
the button has already been pressed. While the program does not expect
that at this time, it is not necessary or desirable that it ought to be
that way--especially if the PalmX decides that synchronization be
negotiated between the pilot and computer. The Palm could change, the
backend could change, anything can happen. While the message currently
comes up every time, that is not in the nature of what it is asking. That
is an artifact of the implementation. ~60% of the time I use the program,
it is not necessary. The program has not failed to communicate with my
Palm and only reports the message out of habit. This is NOT necessary and
it ought not be done at all. An extra timeout would make the message
occur much more appropriately.
> STDERR, as the name suggests, is for -errors-. It ain't an error, >
therefore it doesn't belong there. IMHO, YMMV, etc etc. Really?
Historically STDERR developed because there was a need to give status info
out-of-the-band of the program's normal communication (most commonly for
pipes and such). As such, I have seen it (well) used to report not solely
errors but any transient, exceptional, and abnormal events with regard to
the program at hand. Tar reports garbage at the end of an archive an
STDERR but that is not an error (it's normal operation on a block tape
device). Stderr is a mainstay for many people's debugging. Almost any
pipe that has something to say to the user uses STDERR for simply
communicating status. The GNU stdio info page says that STDERR is for
"diagnostic output" and STDOUT is for "conventional output". A Press
Hotsync message is diagnostic of the program's functioning. It is not and
ought not be part of the conventional output of the program. Indeed it
could be considered a bug that the program asks for the button to be
pressed when it is not necessary. I would consider it so, but I'm really
too picky anyways (see this thread).
The point is that since pilot-xfer is not an interactive program, it's
conventional output should be nothing more than the story of the xfer.
The "Press HotSync" message should be communicated out-of-band to the user
as a diagnostic of the program's function. That is a more useful way to do
it and it does not violate the traditional use of stderr.
Should I want to record a session with pilot-xfer, it is
advantageous to be able to do this:
$ pilot-xfer -s pilot/ >> pilot/hotsync.log
Press the HotSync button now . . .
Abnormal Packet . . .
Abnormal Packet . . .
$
: leaving a log file with the meat of the operation and messages on the
screen reporting the appropriate diagnostic data.
The extra messages are unneeded in my log (I keep a log like that
actually, replete with serial errors at this point, I have it clocked a
bit high for my com port) and should be reported on STDERR. If I wanted
the complete log--with transient, exceptional, and abnormal events--I
would use >&.
That functionality (a DESIRABLE functionality) is completely lost with the
current approach. Without the above bugfix a user is robbed of the chance
to use this functionality and must do so by hand--spending hours hand
editting the log with vi, emacs, or, even (for the really unlucky)
PICO!!!. *nix tools should get tha most bang for the buck.
Jayson Vantuyl
Obsessive Lunatic
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v0.9.8 (GNU/Linux)
Comment: Made with PGP4Pine
iD8DBQE3mzVdlBv9MedxyboRAgnMAJ9tB1d+fbWJOY7MRkg/6B0TMBjnGACgu40l
imltVZI7D3AuGwgql7laSXw=
=oG8z
-----END PGP SIGNATURE-----
Reply to: