I have problem with sudo command when i changed $PATH
Problem:
-bash: id: command not found
-bash: tty: command not found
-bash: uname: command not found
[root#ol6 ~]# sudo
-bash: sudo: command not found
And echo $PATH
[root#ol6 ~]# echo $PATH
/usr/lib64/qt-3.3/bin:/usr/local/sbin:/usr/sbin:/sbin:$PATH:/opt/jdk1.8.0_66/bin:/opt/jdk1.8.0_66/jre/bin
Could you tell me solve this problem.
thanks sm.
sudo is located in /usr/bin on RedHat, but I think your real problem is that you single-quoted $PATH when you altered your PATH and got a literal $PATH in it instead of what you intended!
You somehow got the literal string $PATH in your PATH variable, when you probably meant to add some stuff before and after it. I imagine you did this by using single quotes when assigning:
PATH='/usr/lib64/qt-3.3/bin:/usr/local/sbin:/usr/sbin:/sbin:$PATH:/opt/jdk1.8.0_66/bin:/opt/jdk1.8.0_66/jre/bin'
when you should have used double quotes
PATH="/usr/lib64/qt-3.3/bin:/usr/local/sbin:/usr/sbin:/sbin:$PATH:/opt/jdk1.8.0_66/bin:/opt/jdk1.8.0_66/jre/bin"
so the $PATH would expand to its current value (though it's too late for that in your current shell).
Anyway, for me, sudo is in /usr/bin so if you don't have that in your path you won't be able to run it without specifying the full path.
Related
Consider the following Makefile.
install:
sudo rpi-install.py /dev/ttyUSB0 foo.bin
Note that I have deliberately not hardcoded a path to rpi-install.py because it is not in the same location on other people's machines, but I expect it to be in the PATH of everyone who uses my code.
Unfortunately, when I type make install, I get the following output.
sudo rpi-install.py /dev/ttyUSB0 larson.bin
sudo: rpi-install.py: command not found
make: *** [install] Error 1
When I type the exact same command on my shell, it works exactly as expected.
Additionally, when I remove the sudo from the Makefile, it successfully finds the binary and gets a permission denied error due to lack of root privileges.
How can I allow make to discover the programs that are in my PATH when they must be run with sudo?
For the sake of reproducibility, assume that the following contents are in rpi-install.py, and that it lives in the directory $HOME/bin. Additionally assume that PATH includes $HOME/bin.
#!/usr/bin/env python
print "Hello World!"
There was a combination of two fixes that resolved this problem.
I needed to set PATH in .profile instead of .bashrc because the default shell /bin/sh used by make did not pick up the correct path from .bashrc.
I needed to set the environment for the sudo command inside the makefile explicitly to be the external PATH, based on this answer to this question.
sudo env "PATH=$(PATH)" rpi-install.py /dev/ttyUSB0 larson.bin
I've messed up my PATH variable by editing /etc/environment, I don't have rm, sudo or many commands. Can someone tell me the path to the vim and sudo executables so I can fix this
The path to vim can possibly vary, for vi it's /usr/bin/vi.
You can still fix your PATH by exporting it manually in shell as below:
Ubuntu default:
export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
CentOS default (tested on VM):
export PATH=/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:$HOME/.local/bin:$HOME/bin
You can also look for the binaries by the following commands (if you run sudo updatedb before):
locate vim | grep -w "vim$"
or:
type -a vim
The best would be to fix your PATH by adding the right values into the right rc file. Normally you set that in ~/.profile for the current user, or adding new as part of /etc/init.d scripts:
$ grep -R PATH /etc/init.d
/etc/init.d/functions:PATH="/sbin:/usr/sbin:/bin:/usr/bin"
/etc/init.d/functions:export PATH
/etc/init.d/netconsole:PATH=/sbin:/usr/sbin:$PATH
/etc/init.d/vboxadd:PATH=$PATH:/bin:/sbin:/usr/sbin
/etc/init.d/vboxadd-service:PATH=$PATH:/bin:/sbin:/usr/sbin
/etc/init.d/vboxadd-x11:PATH=$PATH:/bin:/sbin:/usr/sbin
Vim:
$ which vim
/usr/bin/vim
sudo:
$ which sudo
/usr/bin/sudo
None of the commands are working in ec2 machine.
-bash: id: command not found
-bash: id: command not found
-bash: id: command not found
-bash: tty: command not found
-bash: mktemp: command not found
-bash: $TMP: ambiguous redirect
-bash: rm: command not found
-bash: vim: command not found
I guess I did some changes in /etc/environment for setting PATH of java and after some time I am not able to run any of the commands in the next login.
Anyone please help, what should I do in order to run these commands perfectly again?
I screwed up by appending the PATH by using export PATH=$PATH:
in /etc/environment file, as was not aware that $PATH does not work there in /etc/environment.
How i found my problem ?
A- I used command "which ls" then it showed me ls command location and which is /usr/bin and it also shows that PATH does not contain this.
How I solved my problem ?
A- As none of the command is working not even vi command so there was only option left was to do this :
PATH=$PATH:/usr/bin
export PATH
And after doing this , now i am able to sudo on my machine.
I hope ,it can be helpful for any other person who mistakenly screwed his/her environment.
I have shell command ./cherrypicker.sh input.txt which works fine in terminal.
But I want to execute few more command before and after this command like
echo "some text" > input.txt
./cherrypicker.sh input.txt
result < input.txt.response
rm input.*
So I put all this in another shell file, alls.sh and tried to execute it like this
./alls.sh
which says
bash: ./test.sh: Permission denied
then
sudo ./alls.sh
which gives
sudo: ./test.sh: command not found
what is the correct way?
Add execution rights to the script:
chmod +x test.sh
The second problem is related to the path. cd to the directory or use the full path (use whichever is more appropriate for the task).
You might want to make sure that test.sh is actually executable by doing
chmod 0700 /path/to/test.sh
And then run it without sudo.
A note on sudo: it is not muckrake to get all your problems out of your way. ;) Think of it is rather a foil to punctually and elegantly make your point clear. ;)
Question: I get this error message:
export: bad interpreter: No such file or directory
when I execute this bash script:
#!/bin/bash
MONO_PREFIX=/opt/mono-2.6
GNOME_PREFIX=/opt/gnome-2.6
export DYLD_LIBRARY_PATH=$MONO_PREFIX/lib:$DYLD_LIBRARY_PATH
export LD_LIBRARY_PATH=$MONO_PREFIX/lib:$LD_LIBRARY_PATH
export C_INCLUDE_PATH=$MONO_PREFIX/include:$GNOME_PREFIX/include
export ACLOCAL_PATH=$MONO_PREFIX/share/aclocal
export PKG_CONFIG_PATH=$MONO_PREFIX/lib/pkgconfig:$GNOME_PREFIX/lib/pkgconfig
PATH=$MONO_PREFIX/bin:$PATH
PS1="[mono-2.6] \w # "
But the bash path seems to be correct:
asshat#IS1300:~/sources/mono-2.6# which bash
/bin/bash
asshat#IS1300:~# cd sources/
asshat#IS1300:~/sources# cd mono-2.6/
asshat#IS1300:~/sources/mono-2.6# ./mono-2.6-environment
export: bad interpreter: No such file or directory
asshat#IS1300:~/sources/mono-2.6# ls
download mono-2.4 mono-2.4-environment mono-2.6 mono-2.6-environment
asshat#IS1300:~/sources/mono-2.6# cp mono-2.6-environment mono-2.6-environment.sh
asshat#IS1300:~/sources/mono-2.6# ./mono-2.6-environment.sh
export: bad interpreter: No such file or directory
asshat#IS1300:~/sources/mono-2.6# ls
download mono-2.4-environment mono-2.6-environment
mono-2.4 mono-2.6 mono-2.6-environment.sh
asshat#IS1300:~/sources/mono-2.6# bash mono-2.6-environment
asshat#IS1300:~/sources/mono-2.6#
What am I doing wrong? Or is this a Lucid Lynx bug?
I did chmod + x
The first line, #!/bin/bash, tells Linux where to find the interpreter. The script should also be executable with chmod +x script.sh, which it appears you did.
It is highly likely that you created this file with a windows editor, which will place a <cr><lf> at the end of each line. This is the standard under dos / windows. OS X will place a <cr> at the end of each line. However, under Unix / Linux, the standard is to just put a <lf> at the end of the line.
Linux is now looking for a file called /bin/bash<cr> to interpret the file,
where <cr> is a carriage return character, which is a valid file character under Linux. Such a file doesn't exist. Hence the error.
Solution: Edit the file with an editor on Linux and get rid of the extra <cr>. One tool that usually works when the file is edited on Windows is dos2unix.
Could the script be using Dos newlines?
Try running dos2unix on it.
It looks like things have been configured to override the export builtin somehow. This can be done via an exported function or the enable builtin, for example. Try putting type export in the script to check. If you are setting BASH_ENV, you probably shouldn't.
If bash is called as sh, it enables POSIX mode and does not allow export to be overridden with a function, as required by POSIX. Likewise, most other shells installed as /bin/sh follow POSIX in this and/or do not allow the execution environment of a script to be messed up so strongly as through importing functions from the environment.
By the way, the script seems designed to be sourced, i.e. . ./mono-2.6-environment instead of ./mono-2.6-environment.
Had the same problem. Used brute force:
/bin/sh /full/path/to/configure --options
& this did the trick
(Of course I'd like to know why)
I encountered a similar error but in my case I forgot to add / before bin and I was encountering the bad interpreter error. Also tried to do
sudo apt-get install dos2unix -y package.
I was using this originally :
#! bin/bash ( i was missing / before bin )
Double check the path as well.
This could be a case of a shebang with homoglyphic unicode characters. In other words, you may have invisible or look-alike characters in the shebang which don't actually represent the string #!/bin/bash. Try looking at the characters in a hex editor.
what worked for me was when dos2Unix wasn't on the system I was working with:
sed -i s/{ctrl+v}{ctrl+m}// filename
This happens sometimes when file system goes funny.
Try to move or rename the file.
If you see "Stale file handle" error this is your problem.
e.g. happened us with CentOS docker
$ ./test.sh
-bash: ./test.sh: /bin/bash: bad interpreter: Invalid argument
$ ls -alstr test.sh
20 -r-xr-xr-x 0 omen omen 17874 Jun 20 01:36 test.sh
$ cp test.sh testcopy.sh
$ ./testcopy.sh
Happy Days
$ mv test.sh footest.sh
mv: cannot move ‘test.sh’ to ‘footest.sh’: Stale file handle
$ rm test.sh
rm: cannot remove ‘test.sh’: Stale file handle
You can copy the file and read it.
But not move it!
Nor remove it.
Some weird docker file-system thing maybe.
Solution: re-create the docker container OR maybe file system repair disk would help
OR of course format c: :-D :-o