2

I have this weird problem. The php command is not found in one specific sitiation.
I try to call the command in three different ways. Only one of them fails:

  1. Being user john I create a simple script which calls php --version. Then as user root I call that script like this: sudo -u john ./script.sh
    This way the php command is not found.

  2. Being root I invoke the command directly like this: sudo -u john php --version
    No problem here, the command does exist.

  3. I call the script directly as user 'john': ./script.sh
    It works fine too.

What is causing this?

The problem happens with other users too, not just john, and it happens on this particular machine only.
The OS is CentOS 5.9.

EDIT: Also, other commands like gcc, perl or python don't present this problem. The php command is the only one I found so far with the problem.

GetFree
  • 1,500
  • 7
  • 23
  • 37
  • 1
    May I suggest comparing path variables on the accounts? /home/"username"/.bash_profile Simply add php executable location to the path. – Vick Vega Apr 07 '13 at 03:31

1 Answers1

4
  1. Your test script lacks a shebang line. No soup for you.
  2. The subshell being invoked by your script is not using the same PATH variable as your interactive shell. Type echo $PATH to see your current path variable, and set this PATH variable within the script.

As for why the PATH variable isn't consistent between the two:

  • Because you aren't specifying the shebang line, you have no insurance that the shell being invoked is the same as your interactive shell. It could be sourcing different configuration files entirely.
  • Different configuration files get sourced depending on how a shell is executed. You are inside of an interactive shell, and your script is a non-interactive shell. Assuming you're trying to use bash, consult man bash and begin reading at the INVOCATION section near the top of the file.
Andrew B
  • 32,588
  • 12
  • 93
  • 131
  • Thanks. The difference in the $PATH variable was the problem. The `php` command wasn't in `/usr/bin` as it normaly is, so I just added a symlink to it and problem solved. – GetFree Apr 07 '13 at 04:02
  • @GetFree I really don't recommend that symlink, it will just make things confusing. The proper solution to the problem is to understand why the `PATH` variable was different, and correct it in the proper configuration file. – Andrew B Apr 07 '13 at 04:05
  • I think the difference in PATH is due to .bash_profile as @Vick said. The PATH inside the script was just `/usr/bin:/bin` while in the interactive shell it was a much longer list of paths. – GetFree Apr 07 '13 at 04:20
  • 1
    @GetFree I know about `.bash_profile`, I was directing you to the invocation docs earlier. Symlinks aren't the right way to solve this problem in a professional IT environment, I'll leave it at that. – Andrew B Apr 07 '13 at 04:24
  • @AndrewB Nice answer as usual – David Houde Apr 07 '13 at 04:25
  • I understand, it's not an elegant solution. But in my particular situation it's faster because the script is present in several user accounts. I'll keep in mind your advice, thanks. – GetFree Apr 07 '13 at 04:34
  • 2
    Specifying the **absolute path** to the `php` binary in the script would be my preferred solution. This makes your script independent of any `$PATH` variable (although this _could_ also be a problem when different users are intended to run different PHP binaries). – Lukas Apr 07 '13 at 05:28
  • @Lukas, another problem is that the absolute path to the php binary is not the same across different OSs – GetFree Apr 09 '13 at 00:43
  • @GetFree And neither is the value of `PATH` for a bash script. I guess you will have to do _some_ work when porting a script to another OS or distribution. – Lukas Apr 09 '13 at 01:04
  • Check for **secure_path** on sudoers `sudo -V | grep 'Value to override'` – codemonkee Sep 01 '13 at 17:00