Excellent analysis, but I'm not sure if I agree with all of the detail
of your interpretation (aren't we glad the docs are so clear! :-)).
I think we end up with a similar conclusion regarding the solution.
Aaron Kulkis wrote:
Linda Walsh wrote:
I would, but it doesn't help. When "boot" starts (1st script
called by init), it redirects stdout and stderr to /dev/console.
#
# Set I/O of this script and its childs to console
#
exec 0<> $CONSOLE 1>&0 2>&0
Now, according to the bash manual:
Duplicating File Descriptors
The redirection operator
[n]<&word
is used to duplicate input file descriptors.
If word expands to one or more digits, the file
descriptor denoted by n is made to be a copy of
that file descriptor.
----
So file descriptor "n" becomes a copy ("is made
to be a copy") of "word", thus 2>&1 redirects stderr (2)
to the same place as stdout (1).
#
# Set I/O of this script and its childs to console
#
exec 0<> $CONSOLE 1>&0 2>&0
So..it doesn't redirect stdout and stderr to /dev/console,
it COPIES the stdout (fd1) and stderr (fd2) to fd0 (stdin),
and uses fd0 for communication both from AND TO the console.
---
I think the wording in the manpage is less than crystal
clear! I think it means nearly the opposite. the "0<>"
says to open "0" for reading and writing to "$CONSOLE". Then
the "1>&0 2>&0" duplicates fd0 into fd1 and fd2, so everything
goes to $CONSOLE after this line.
Now, the NEW boot script needs a way to record
everything while still doing what it does, here we
can use the command "tee" command. tee takes an input
(such as stdout or stderr) and directs it to TWO output
streams (a named file, and stdout)
---
Tried "tee", FYI -- but I found I needed a place
to store the output (and when this script is run, "/" (rootfs)
is still mounted "ro" in expectation of running "fsck".
The only "problem" with "tee" is that some programslook at the
output file handle and behave differently based on whether output
is a device (like /dev/console) or a pipe (as you'd get with
using "tee").
The boot procedure could likely be cleaned up a bit
in this area if one assumes a journalling filesystem that doesn't
need (or doesn't have) an "fsck" program (or function). Since
all my disks are "xfs" (which has no fsck program), I could
probably "mount -o remount,rw /" at this point to create a
space for the log. Alternatively, I could wait a few lines until
tmpfs gets started and log to a tmp-file while booting.
However, rather than going through that extra pain now (being basically
lazy), the sed 1-liner I mentioned is sufficient, for my needs, for now,
to clean up "/var/log/boot.msg" to be a fairly reasonable approximation
of what I am looking for.
Thanks for the analysis & help...appreciated!
Linda
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
