> > > log in on some virtual terminal, then run the following line
> > > in a bourne type shell, like bash :
> > >
> > > X 2>&1 | less
>
> > or by just not piping X
into less or more.
> I didn't do it on purpose to lock up my system and risk FS corruption
> durin unclean reboot. I was interested in the server output and " 2>&1 | less"
> is the logical way to do that.
>
> I could also "solve" this problem by not running linux. And I can "solve" all
> gcc bugs by not using gcc. Those are not solutions. Not to me at least.
You could also solve all your computer problems by not using a computer.
> > output into interactive programs. tail -f is a viable workaround -- and
>
> tail -f ? what is the difference between :
> $ X 2>&1 | tail -f
> and
> $ X
> ?
>
> > all this is off-topic on linux-kernel,
>
> non-root user locked up the console code. console code is part of kernel.
> it is a kernel topic.
This is not the problem. It's not the kernel's fault, it's less's fault.
When you pipe to less, it only reads enough to display on the screen. X is
sending tons more information than less is willing to read therefor X will
block (stop) until less reads more. I've done this myself. my work around
is to press END as soon as I hit enter. That way less will go to the end
and not block.
You're better off doing:
X > somefile 2>&1
then lessing "somefile". this won't block the X server.
I agree with matt that this is off-topic as it's not a kernel issue, it's
userland.
-- Lab tests show that use of micro$oft causes cancer in lab animals - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Jan 15 2002 - 21:00:31 EST