I am logging into a solaris server, switching to bash, then switching to another user "sruser" and switching to bash.

/home/batch/sruser/ is the home directory of the user "sruser".

The issue is ps is not giving any output when run in the home directory -

# pwd
# ps
# cd dir1
# ps 
 17867 pts/1789 0:00 bash
 17165 pts/1789 0:00 ksh
 20435 pts/1789 0:00 ps

Don't know what could be the issue. Don't even know where to start looking for whatever could be the issue.

  • 3
    Maybe the sruser has . (cwd) in $PATH and a ps executable in his home directory? – guido Feb 21 '11 at 12:22
  • 3
    try type ps or which ps to see what is being executed – phunehehe Feb 21 '11 at 13:05
  • 1
    Hope you didn't run that as root? But how would . end up in root's PATH? Hope you didn't add it there yourself. – alex Feb 21 '11 at 14:31
  • 1
    If type ps shows that /usr/bin/ps is being executed, run truss ps to see what's going on. (But . in $PATH is the most obvious explanation.) – Gilles 'SO- stop being evil' Feb 21 '11 at 21:11
  • @guido Thanks for the answer. @phunehehe @Gilles Thanks to you guys, TIL 3 new commands (I'm a UNIX newb) – Srikanth Feb 22 '11 at 5:20

$PATH has .(cwd) and there is a file ps with executable permissions in the home directory.

# ls -lrt *ps*
-rwxrw-r--   1 sruser  batch          0 Jun 2 2010 ps
# type ps
ps is hashed (./ps)
# which ps

Hence the command was not giving any output.

  • "ps" has no executable permission bits set in your ls output. It should then be ignored by the shell while exploring your PATH. – jlliagre Feb 23 '11 at 4:46
  • @jlliagre thanks for correcting me. i copied the wrong snippet. it does have a executable permission. – Srikanth Feb 23 '11 at 16:54
  • 3
    In any case, having . in your PATH as root is a poor practice but having it before the standard /bin, /usr/bin, sbin directories is quite suicidal. – jlliagre Feb 23 '11 at 20:26
  • 2
    Note that the more traditional way to include the current directory in $PATH is with the empty string. PATH=/bin: has the current directory last and PATH=:/bin:/usr/bin has it first. Incidentally, that latter one is the default $PATH (!) on GNU/Linux systems (for execvp, env...) when PATH is unset. – Stéphane Chazelas Jun 4 '14 at 22:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.