Commands typed in terminal:
chmod 777 abc.sh
sudo ./abc.sh
Every shell program is giving the same error:
.sh: command not found
Including this simple abc.sh program:
#!/bin/bash
# My first script
echo "Hello World!"
Output of sudo od -c ./abc.sh:
0000000 # ! / b i n / b a s h \n # M y
0000020 f i r s t s c r i p t \n \n e
0000040 c h o " H e l l o W o r l d
0000060 ! " \n \n
0000064
Well, from what you told us, it should be working perfectly... That is if the partition it's stored on supports unix/posix style permissions. I run into this error all the time if I try to run a script from a vfat or ntfs partition. Considering it's mounted in a location called work, is this on a USB drive with fat or ntfs formatted partition? If it is, you have to prefix the shell before the script. Check the partition, and that might be the issue. Move it to your home directory, and it might run easily, on a filesystem that supports unix/posix permissions.
Check if that's the case:
mount |grep nisheet
Does is say vfat, fuseblock or ntfs? If so...
Two options:
bash abc.sh
Ex:
mv abc.sh ~/
cd ~
chmod +x abc.sh
./abc.sh
777 by default though, so if that's the problem they should check their fstab to see how that partition is mounted.
– kos
Jan 25 '16 at 15:55
./abc.sh. It ran no difference from the it runs on the ext4 filesystems. The path of the auto mount is /media/ljames/00A4C6CAA4C6C180/WINDOWS. In other words, you can run shell scripts (and other programs) from Windows filesystems.
– L. D. James
Jan 26 '16 at 14:43
Examine the output of this (from the directory where the abc.sh resides):
$ type ./abc.sh
$ ./abc.sh
The type command will first verify that your ./abc.sh is found. If it isn't it will exit saying that it can't find the ./abc.sh file. Then we would have to find out what it is about the filename that it can't be found.
Also, what is the name of the editor you are using to create your script file. If you inadvertently used a Windows edit (through wine) this can cause problems with the line terminators in your script.
Try using and edit such as nano or gedit. You might use one of those recommended editors and create the same example file as, abc1.sh and ensure that you have the lines exactly as they are in your edited question.
By the way, the only way I can reproduce the error message that you gave in your question is by leaving out the abc part of the abc.sh file.
These commands will produce the error of your message:
$ ./.sh
$ sudo .sh
Please keep in mind that each error is unique and important in diagnosing the problem. It's important to test and exact script and give the exact error message.
For example a permission denied error could be caused by trying to execute a file that doesn't have the execution bit set. This can be set by executing the command that you reference in your question:
$ chmod 777 abc.sh
You could also get the permission denied error by trying to execute a file that that is owned by root and doesn't have the world or group bit set for reading. This can be a side effect of using sudo in your personal space when it's not necessary. The chmod 777 that you mentioned in your question would also resolve that problem by giving reading and execution permission to all users.
If you have created the file in such that it's owned by root you will have to use the elevated command to change the properties. This will give you access to execute the file:
$ sudo chmod 777 abc.sh
If you have a reason to control who can execute or access the script you might take a look at some of the other options of chmod:
$ man chmod
As suggested in the comments to your question, you shouldn't use the elevated command sudo to run scripts that you are testing. If the testing is in your personal space, you can cause areas of your personal space to have become owned by root... losing personal access to those areas. Some ill formed scripts could also cause corruption to other system files of our OS. The mistyping of your attempt to run the abc.sh script is an example that errors can happen. If you decided to remove your script or script work directory and mistakenly had a space in the wrong place it could cause serious problems where you least expect.
Not a solution to the case of the asker, but it might help others, who come to this question:
If you get a command not found after trying to run a script (e. g. sudo ./abc.sh), make sure:
You have the permission to execute the file. You can make the script executable for everyone by the following command:
chmod a+x ./abc.sh
Depending on your current access rights, you might have to prefix this command with sudo. You can check the current access rights with:
ls -la ./abc.sh
Your script has a correct Shebang, e. g.:
#!/bin/bash
Otherwise, you have to run your script by calling your desired interpreter, e. g.:
sudo bash ./abc.sh
Your script uses Unix line endings: Every line (also the last one!) has to end with a line feed (\n or 0A in hex). It will not run with Windows line endings (\r\n or 0D 0A in hex), for example. You can use the following command to investigate on your line endings:
hexdump -C ./abc.sh
If the script is in the directory you are currently in, you have to use:
. abc.sh
instead of:
./abc.sh
assuming your user has permissions.
