mike@apex.yorku.ca (Mike Marques) (06/22/91)
Greetings...
Where do I get information about /dev/xcons?
I tried adding the following to my rc.local:
# Direct console output to /usr/adm/messages
tail -f /dev/xcons >>/usr/adm/messages &
It worked fine and the boot process was recorded on that file.
However after the boot was completed and X windows started up output
to the console stopped showing up on that file. In fact console
output didn't go anywhere anymore. I killed the tail -f on
/dev/xcons and that didn't help.
My idea was to have console output recorded to a file and then have
processed intersted on console output read the /usr/adm/messages file.
Is there a better way of doing this? (I tried a cat of /dev/xcons but
cat just exits after the first message shows up.
Mike
p.s. Oh yeah, I'm running Ultrix 4.2 on DECstation 2100
(Hey, who protected /dev/console? ;-) )
--
Mike Marques )( Usenet: ......!utzoo!yunexus!mike
Computing & Communications Services )( mike@outland.yorku.ca
(IT division), York University. )( Bitnet: mike@yulibra
Only visiting this planet... )( Voice: (416) 736-5257grr@cbmvax.commodore.com (George Robbins) (06/22/91)
In article <MIKE.91Jun21173626@apex.yorku.ca> mike@apex.yorku.ca (Mike Marques) writes: > Greetings... > > Where do I get information about /dev/xcons? > > I tried adding the following to my rc.local: > > # Direct console output to /usr/adm/messages > tail -f /dev/xcons >>/usr/adm/messages & I think tail depends on seeing the file size change or some other clue that data has been appended to a file. I don't know that it can be expected to do anything meaningful on a character device. One way we use X here is to provide graphics support for a CAD package where the control terminal is a normal termainal (no xterm to clutter up the screen). I just have "cat -u /dev/xcons & " in the startup script which seems to work nicely in diverting "console" output to the controlling terminal. I don't see why writing to a file would be any different - perhaps the trick is to avoid having the output buffered so that "killing" the cat doesn't loose the buffer, which for low volume would be most of the output. Dunno if "cat -u" is adequate or merely cargo cult. -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing: domain: grr@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)
trost@reed.edu (06/25/91)
> # Direct console output to /usr/adm/messages > tail -f /dev/xcons >>/usr/adm/messages & I think tail depends on seeing the file size change or some other clue that data has been appended to a file. I don't know that it can be expected to do anything meaningful on a character device. (Probably) untrue -- the sources for 4.3 BSD indicate that tail just sleeps a second and then read(2)s BUFSIZ bytes from stdin. Of course, it only does that if the lseek(2) above doesn't return an EISPIPE -- which may or may not occur on the xcons pseudo-device. A more compelling argument is that we use "xterm -e tail -f /dev/xcons" to redirect our console output, and it works fine. This is Ultrix 4.1, though -- maybe somebody "fixed" something (somehow, getting, EISPIPE *does* make sense...).
grr@cbmvax.commodore.com (George Robbins) (06/26/91)
In article <TROST.91Jun24181628@brahma.reed.edu> trost@reed.edu writes: > > > # Direct console output to /usr/adm/messages > > tail -f /dev/xcons >>/usr/adm/messages & > > I think tail depends on seeing the file size change or some other clue > that data has been appended to a file. I don't know that it can be > expected to do anything meaningful on a character device. > > (Probably) untrue -- the sources for 4.3 BSD indicate that tail just > sleeps a second and then read(2)s BUFSIZ bytes from stdin. Of course, > it only does that if the lseek(2) above doesn't return an EISPIPE -- > which may or may not occur on the xcons pseudo-device. > > A more compelling argument is that we use "xterm -e tail -f > /dev/xcons" to redirect our console output, and it works fine. This > is Ultrix 4.1, though -- maybe somebody "fixed" something (somehow, > getting, EISPIPE *does* make sense...). Well, I don't have any problem with your source reading or logic, but I would claim that in this case tail isn't going to do anything for you that cat doesn't. 8-) -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing: domain: grr@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)
mellon@nigiri.pa.dec.com (Ted Lemon) (06/26/91)
>A more compelling argument is that we use "xterm -e tail -f >/dev/xcons" to redirect our console output, and it works fine. This >is Ultrix 4.1, though -- maybe somebody "fixed" something (somehow, >getting, EISPIPE *does* make sense...). It seems to me that just a ``cat /dev/xcons'' would work better. Cat does blocking reads, so if there's no data, it will block until data is available, rather than waking up once a second to check again. Actually, there's a good chance that tail -f works this way too, since it probably doesn't go into the 1-second sleep mode until it reads zero bytes at the end of the file. If there's nothing to read from /dev/xcons, the read would just block until something came out. _MelloN_
cks@hawkwind.utcs.toronto.edu (Chris Siebenmann) (06/27/91)
Ian D! Allen (idallen@watcgl.waterloo.edu) wrote a patch for the R4
xterm such that it could handle -C under Ultrix. It just opens
/dev/xcons and dumps the output into the window, without needing you to
use cat or anything; it's quite nice and handy. I imagine he'd be
happy to send people the patch; it's pretty short and simple.
--
ported program: a program which takes constant or increasing
effort to port to each new machine.
portable program: a program which takes less effort to port to
each new machine.
cks@hawkwind.utcs.toronto.edu ...!{utgpu,utzoo,watmath}!utgpu!cks