Have an issue and looking for help so hope someone is able to give me some clues.
I prepared some shell scripts with coloured output to help other guys to have more automated task. Not sure if I did this but now whenever I use 'ls' command for root user every output in terminal stays green. I can of course give 'tput sgr0' and make it black again but it will come back once 'ls' command is used. This happens only for root user. I checked env variables (TERM=vt100) to see if there is something in there - nothing. I compared them with users vars - nothing. I checked .profile and .bashrc of root user - nothing. There is nothing in aliases as well. Only 'ls -F' and looks like ls does not support --color option.
I will check and post output on Tuesday cos do not have remote access. Thanks for feedback. I just installed solaris 10 on my virtual machine at home so will have comparison. If i am not mistaken I tested that with: 'which ls' and output was: '/usr/bin/ls'.
Is that "always green" background or foreground? Does it depend on the last file listed? Or on your application's exit? Please post the output of ls -la | od .
The "which" command is useless. It only looks to the PATH so doesn't take into account aliases, builtins or functions. It won't help figuring out what is actually executed when you type a command.
The portable way is "type command".
Ok then. Like I said, on Tue I will answer all question.
Only fg (text) is green, even along with the shell prompt after 'ls' is used. It does not depend on last files listed. It happens right after the first use of 'ls'.
If not mistaken only 2 aliases are there:
ll='ls -la'
ls='ls -F'
I checked that while searching to solve this issue.
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.
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:
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.
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
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
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.
It has to be something related to home folder of root. I just found out that it happens only within root folder (/root). If I escape it and send 'ls' command text stays black as it should.
I had one script with some color strings in /root. I removed all scripts from this folder and it still shows green text.