Bash script returns "command not found" when outside the source folder

Question

under my directory, /home/lucas/bin I have the following script term_multiscreen:

[lucas@lucas-ThinkPad-W520]~$ sudo cat bin/term_multiscreen                              
#!/bin/bash
# Initializes Nvidia Optimus for multi-screen functionality.

xorg_process=$(ps aux | grep 'Xorg' | grep -v grep | awk '{print $2}')
sudo kill -15 $xorg_process
sudo rmmod nvidia
sudo tee /proc/acpi/bbswitch <<<OFF
# xrandr --output VIRTUAL1 --off
[lucas@lucas-ThinkPad-W520]~$ 

When I cd ~/bin, it runs fine with sudo term_multiscreen. When I am outside that directory, it returns command not found. I also have /home/lucas/bin in my $PATH. What am I doing wrong?

BTW here are my permissions:

[lucas@lucas-ThinkPad-W520]~$ ls -la bin/
total 44
drwxr-xr-x  2 lucas lucas 4096 May  6 15:43 .
drwxr-xr-x 71 lucas lucas 4096 May  6 15:43 ..
-rwx--x--x  1 root  root   137 Mar  2 03:26 init_multiscreen
-rw-r--r--  1 lucas lucas    0 Mar  2 03:24 init_optimus~
-rwx--x--x  1 root  root   260 Mar  2 05:54 term_multiscreen
[lucas@lucas-ThinkPad-W520]~$ 

BTW I am on Ubuntu 13.10

Solution 1

I would suggest calling your script with its full path: sudo /home/lucas/bin/term_multiscreen or sudo ~/bin/term_multiscreen. This won't create any security risks connected to sudo's secure_path.

Of course that's too long to type (admins are lazy), so put it into an alias in your ~/.bashrc:

alias tmulti="sudo $HOME/bin/term_multiscreen"

Then reload your ~.bashrc to test:

. ~/.bashrc
tmulti

If you always call your script with sudo, you could also remove the sudo calls within the script.

Solution 2

Ubuntu?

Define an alias as your regular user: alias sudo='sudo env PATH=$PATH'.

Or, run sudo visudo and change Defaults secure_path to Defaults !secure_path. Then, sudo will not use the compiled option, --with-secure-path.

Comments

[mikeserv]

kill -15 $(ps -o pid= -C $prog_name) - or, if you've got pgrep - kill -15 $(pgrep $prog_name). Also, you should probably look at this: github.com/Bumblebee-Project/bbswitch

[mleonard]

@mikeserv Or use killall -15 $prog_name. (killall comes with the psmisc package.)

[mleonard]

@Lucas Why do you want to call a script via sudo that uses sudo itself, where necessary?

[mleonard]

@Lucas No, this doesn't answer my question. If you call this script from the shell, the first sudo in the script will automatically ask you for your password (or not even that, if you used sudo shortly before). If you always use sudo <scriptname>, then the whole script is called in the superuser context and the sudo calls within the script are not necessary anymore.

[modulitos]

@Dubu Ah, yes. Good point, calling with sudo is unnecessary. Thanks for pointing it out! (I caught this just before you posted, so my other comment was deleted...)

[modulitos]

It works! So, it looks like sudo does not use my $PATH by default. Would you suggest adding alias sudo='sudo env PATH=$PATH' to my .bashrc?

[mleonard]

@Lucas Be aware that disabling secure_path poses a security risk. If there are or will be any scripts executed via sudo (probably without a password), an attacker might be able to execute arbitrary binaries as root.

[modulitos]

@Dubu I did not change the default secure_path setting, I only added the alias: alias sudo='sudo env PATH=$PATH. Does this alias addition pose a security risk, or were you referring to the Defaults !secure_path change?

[modulitos]

I think this solution is the cleanest and simplest - and it works!

[mleonard]

@Lucas I was only referring to the secure_path setting. The alias is only slightly dangerous as you might inadvertently execute something with an unexpected $PATH when using sudo under your account. So, someone would have to take over your account to manipulate your $PATH to wreak havoc, but if they managed this, they could do more harm in other ways. OTOH, the secure_path setting is valid for all accounts, so if someone takes over an account with few privileges which is allowed to start a sudo script without password (e.g. a backup account), they could get root access with that.