On Mon, 2008-03-24 at 16:19 -0500, Dan Bongert wrote:
> mouss wrote:
> > Dan Bongert wrote:
> >> Hello all:
> >>
> >><snip>
> Though 'ls' was just an example -- just about any program will fail. The 'w'
> command will fail too:
>
> thoth(118) /tmp> w
> 16:06:51 up 5:34, 1 user, load average: 0.94, 1.46, 2.04
> USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
> dbongert pts/0 copland.ssc.wisc 14:16 0.00s 0.22s 0.05s w
>
> thoth(119) /tmp> w
> 16:06:52 up 5:34, 1 user, load average: 0.94, 1.46, 2.04
> USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
> dbongert pts/0 copland.ssc.wisc 14:16 0.00s 0.22s 0.05s w
>
> thoth(120) /tmp> w
>
> thoth(121) /tmp> w
>
Hmmm... Sure it's failing? Maybe just the output is going somewhere
else? After the command runs, what does "echo $?" show? Does it even
work? Echo is a bash internal command, so I would expect it to never
fail.
What is your output device? A serial terminal? If so, could be simple
flow control issues. In fact, any serial connection (even a PC emulating
a terminal) could suffer from flow control problems. And they would tend
to be erratic in nature.
If you are on a normal console, try running the commands similart to
this (trying to determine if *something* else is receiving output or
not)
<your command> &> /dev/tty
if this works reliably, maybe that's a starting point.
There's a couple kernel guys who frequent this list. Maybe one of them
will have a clue as to what could go wrong. Corrupted libraries and
whatnot.
You might try that rpm -V command earlier against all packages (add a
"a" IIRC). Maybe some library accessed by the coreutils, but which is
not itself part of coreutils, is corrupt.
HTH
Highlight