Date: Tue, 29 Oct 1996 18:23:01 PST From: Bill Fenner <fenner@parc.xerox.com> To: hackers@freebsd.org Subject: Input on changing "dump" output? Message-ID: <96Oct29.182310pst.177480@crevenia.parc.xerox.com>
next in thread | raw e-mail | index | archive | help
The output of the rdump command can obviously (based upon a recent PR and followups in -questions) be confusing. I'm playing around with it, and I think I've gotten it to a point where first-time users will be significantly less confused. However, it deviates from the "traditional" output somewhat. Here's the "traditional" output: DUMP: Date of this level 0 dump: Tue Oct 29 17:47:45 1996 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/rsd1a (/) to /dev/null on host root@nectar DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 16657 tape blocks on 0.43 tape(s). DUMP: Protocol to remote tape server botched (code "rmt: not found"). rdump: Lost connection to remote host. DUMP: Bad return code from dump: 1 Here's my "new" output: DUMP: Connection to nectar.parc.xerox.com established. DUMP: Date of this level 0 dump: Tue Oct 29 18:00:29 1996 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/rsd1a (/) to /dev/null on host root@nectar DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 16657 tape blocks on 0.43 tape(s). DUMP: Lost connection to remote host. DUMP: on nectar.parc.xerox.com: rmt: not found The changes are: - The addition of a "connection established" line at the top. The real reason for this is that rcmd() prints its own error message, but I didn't like seeing just "Permission denied." So I had to print " DUMP: " before calling rmt, in case it failed. But if it didn't fail, I needed something to put after the word "DUMP". If it does fail, it looks like: DUMP: Login incorrect. DUMP: login to nectar.parc.xerox.com as nosuch failed. or DUMP: nosuchost: Unknown host DUMP: login to nosuchost as root failed. - The seperation of stdout and stderr. Presumably this takes another TCP connection to the remote host, which may be a worry, but it allows the local dump to explicitly identify errors as such. - The consistent use of msg() instead of fprintf(stderr,) and the consistent use of exit codes causing rdump messages to look like dump messages and fixing the "bad return code". My questions are: Does anyone think that the addition of the first line, DUMP: Connection to nectar.parc.xerox.com established. is going to cause anyone (automated backup scripts, etc.) any trouble? Does anyone think that the extra TCP connection (useless after the error-discovery phase) will cause any trouble? Thanks, Bill
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?96Oct29.182310pst.177480>