Bash and ls problems
 

Hmm, this is quite strange. Today, I've noticed some odd problems with bash and ls that weren't there yesterday. As a normal user, whenever I open a console (xterm or rxvt), the first thing bash says is:

bash: [: =: unary operator expected

Followed by a login prompt. The same error pops up in a lot of other cases, such as when I use 'su -' to become root. Also, oddly, after becoming root, none of root's paths and whatnot (/sbin, /usr/sbin and the like) are in $PATH. Bash apparently ignored the hyphen after 'su'.

Anyhow, as if these aren't confusing enough, I've also found that 'ls -l' does not work; in fact, it causes a segfault:

eric@malcolm $ ls -l
total 987
Segmentation fault
eric@malcolm $

Same for any other user. /var/log/messages has no clues. Presumably it's just bash that's broken. The only explanation I'd have for why it's different today than yesterday is that I have 'emerge sync' and 'emerge -u world' run on a daily cron job (this is Gentoo, btw).

Anyone else experience this before?

edit: The bash unary operator warning occurs when my ~/.bashrc sources my ~/.profile, which in turn sources the global /etc/profile. Removing the line fixes the bash warning; sourcing /etc/profile still causes the warning, so I'll have to pin down where it is. At any rate, the ls -l segfault appears to be unrelated, since it still occurs even without sourcing /etc/profile.

edit #2: The /etc/profile script gives a bash warning because it uses the output of `/usr/bin/whoami`, which, apparently as of today, is "Segmentation fault". So whatever happened affected both ls and whoami... Time for some detective work...

Okay, whoami and ls are part of the coreutils package. I'm attempting to reinstall coreutils (hopefully all the segfaults that occur as a result of its use of chmod and such will not kill it).

I'm fairly certain I know exactly what happened now: I added 'static' to my USE variables in /etc/make.conf a while back. Apparently, it's a really bad idea to use that flag with some system apps. Oh well, live and learn :)

Did you do something with your /etc/bashrc file? Since the problem occurs when you are a normal user, and when you su to root, the ~/.bashrc file is probably ok. Also check the /etc/profile script. This script runs files with the .sh extension in the directory /etc/profile.d when you login.

Also check the environment variable $BASH_ENV. If it is set it will override which script is run when you logon.