/usr/bin/which returns cryptic error "which: no ls in ((null))"

Question

I am writing a simple shell program. When I use /usr/bin/which with my shell in mac osx and ubuntu, it acts normally. When I use the exact same command on Red Hat Enterprise Linux Client release 6.3 (Santiago), I get this error: "which: no ANYCOMMANDHERE in ((null))".

Is there any intuition for this? I can't even find what the error means (Let me know if showing my source will help).

EDIT: My path is (from inside the shell):

$ echo $PATH
/usr/lib64/qt-3.3/bin:/usr/local/bin:/bin:/usr/bin

Thanks, Jon

Answer 1

The string (null) is substituted by some C libraries for arguments to printf's %s (string) conversion specifier, when the corresponding argument is a NULL pointer, e.g. for

 char *path = 0; /* This would normally be = getenv("PATH"). */
 printf ("which: no foobar in (%s)\n", path);

It appears that either your PATH environment variable is unset, or not exported. In these cases getenv("PATH") returns 0. As a last possibility, your which utility might have a mighty bug).

Does it work properly if you say export PATH?

Answer 2

Actually, what all other people here already answered - PATH not being set, is true in one way, but false in another way.

I had the same problem (using bash). It seems, a bash "feature" turns into a miss-feature: Bash creates a shell variable (not environment variable!) PATH which it then uses for lookups.

So, the situation is: There exists a shell variable called PATH. But it's not an environment variable. This means, it's not exported to newly created child processes. One thing, we should learn from this, is that using echo $PATH is no way to figure out whether the environment variable PATH is set. Same prolem with set | grep "^PATH=" However, one way to do so is by using the external command env: env | grep "^PATH="

Example shell session:

$ env -i bash
# A new shell is started with empty environment.
# What follows happens in this new shell:
$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
$ set | grep "^PATH="
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
$ env | grep "^PATH="
$ which ls
which: no ls in ((null))
$ export PATH
$ env | grep "^PATH="
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
$ which ls
/bin/ls

Depending on what you're trying to achieve, you can ask the shell to act like a login shell, for bash it's -l. With that, /etc/profile and other files are sources which set up PATH properly by default:

$ env -i bash -l
$ which ls
/bin/ls

The alternative, is to export PATH, see above.

Answer 3

I can reproduce the same output from tcsh:

env -u PATH which ls
which: no ls in ((null))

In csh and tcsh, there's a distinction between environment variables (which are common to all processes) and shell variables (which are local to the current invocation of the shell). It uses the same syntax to refer to both, e.g., $PATH. If you have a shell variable and an environment variable of the same name, then $PATH refers to the shell variable.

[t]csh uses different syntax to set shell vs. environment variables:

set shell_var = foo
setenv env_var bar

(Bourne-based shells such as bash have a different syntax and a different terminology; an environment variable is a shell variable that's been "exported", or that's inherited from the calling process.)

Based on the symptoms you describe, you have a shell variable $PATH (which is useless), but no environment variable of the same name. That shouldn't normally happen. Check your .cshrc, .tcshrc, and/or .login files for statements that set $PATH.

You should be able to work around the immediate problem like this:

setenv PATH "$PATH"   # set the environment variable
unset PATH            # unset the shell variable, just to avoid confusion

(Don't do the unset PATH until you've confirmed that things are working correctly.)

Just to add to the frivolity, [t]csh has a special shell variable $path (note lowercase); its value is an array consisting of the :-separated components of the $PATH environment variable. Setting either will automatically update the other:

 setenv PATH /usr/bin:/bin # sets $path to ( /usr/bin /bin )
 set path = ( /usr/local/bin $path ) # sets $PATH to '/usr/local/bin:/usr/bin:/bin'

This can be convenient, but if you prefer you can just ignore $path and deal with $PATH. Just make sure that you're setting the environment variable $PATH (using setenv), not the useless shell variable of the same name.

Answer 4

It sounds like your PATH environment variable is the problem. For instance, if you run which asdf normally you will get something like:

which: no asdf in (/usr/local/bin:/usr/bin:...)

So it appears your PATH environment variable is something like (NULL). The other possibility is that there's something wrong with the which binary on your RHEL box.

Answer 5

So it turns out the issue is specific to redhat and the forking mechanism. Child processes are not given the default env vars while in ubuntu and mac osx they are. This means that I had to explicitly set the envp to the parent's (in a call to execve).

Apologies for the misleading phrasing in my question (although it is hard to pinpoint these type of things).

Thanks for all the help! Jon