Solaris

Since you already said that /usr/bin/ls on Solaris systems doesn't not support the --color option, there has to be an alias (or another ls in PATH before /usr/bin) that is setting the text color to green (and leaving it that way). /usr/bin/ls isn't doing this.

What shell scripts did you prepare with colored output? I would suspect that one of them is your culprit.

Some simple script, nothing special. One of them was ping test with colored output depends on the answer. I tested some color commands in terminal and could be that one of them is messing this up now. Ping script we run without root privileges so cannot be script itself, cos 'ls' for simple users and admin is fine. Only root affected.
I will double check type command and make sure if this is really /usr/bin/ls.
Is 'echo $PATH' ok for checking this?

You don't need to run with root privileges to change the text color of your output. Once you set the text color, it will remain in effect until something else changes the text color (or resets the terminal to "default" settings).

You said in your first post in this thread that 'tput sgr0 fixes the problem. Some script is effectively performing a tput that is setting text color to green and not using 'tput sgr0 to turn it off before it exits.

That could be the point but I am not convinced due to tput sgr0 does not fix it permanently. If I turn it off using above command and use 'ls' after that, then all is green again.
I will check all scripts once again.

If:

Code:

tput sgr0;echo black text;ls

gives you "black text" in black and ls output in green; you have to have an ls function, an ls alias, or a directory containing an ls in PATH before /usr/bin unless you have a corrupted version of ls installed in /usr/bin.

When you get back to the office, type ls should tell you what is going on. If it doesn't; show us the output from:

Code:

ls -l /usr/bin/l*;sum /usr/bin/ls;uname -a

so someone with the same Solaris release can verify that the timestamp and sum match the "normal" values.

This will give you the size of the "ls" binary that was installed on your server via Sun package:

Code:

grep usr/bin/ls /var/sadm/pkg/SUNWcsu/save/pspool/SUNWcsu/pkgmap | awk '{ print $8 }'

Note that the string you are grepping for does NOT start with a forward slash. This also won't work if your system has a patched "ls" binary.

FWIW, field 9 is the file checksum, obtained with "sum". Field 10 is the original modification time in seconds. You can get the current mod time of the binary in that format with

Code:

stat -c %Y /usr/bin/ls

if your system has the "stat" utility.

If you don't have the "stat" utility, you can get the mod time in seconds with

Code:

truss -t\!all -tstat -vstat ls /usr/bin/stat

You'll see the mod time in the data emitted for the "stat()" call on "/usr/bin/ls".

"echo $PATH" won't help that much identifying what command is run especially as you previously stated you believe "which ls" reported "/usr/bin/ls".
I more than strongly doubt your /usr/bin/ls binary is corrupted in a way that it still works as usual but set the color to green. That would be an extraordinary dubious event.

As already written, "type ls" is the only reliable and portable way to know what is "ls" under the cover.

If it shows "ls" is an alias or a function, check where it is defined in the shell initialization files like /etc/profile, .profile, .bash_profile, .kshrc, .bashrc, .bash_login, $ENV, $FPATH, ... depending on the actual shell used.