4

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

screenshot of terminal and abc.sh path(1)

screenshot of terminal and abc.sh path(2)

  • Comments are not for extended discussion; this conversation has been moved to chat. – Mitch Jan 25 '16 at 17:40
2

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.

  • 3
    ummm......what? – heemayl Jan 24 '16 at 11:30
  • bro chmod 777 is not the best solution. Giving all rights is not suitable. 'chmod +x' is the best solution – DINA TAKLIT Jan 31 '19 at 13:42
3

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:

  1. Prefix the shell in front of the script to run:

bash abc.sh

  1. Move it to a filesystem that supports Unix/Posix permissions:

Ex:

mv abc.sh ~/
cd ~
chmod +x abc.sh
./abc.sh
  • vFAT and NTFS partitions are mounted with permissions 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
  • @kos If it is just a USB drive from work, it probably isn't in his fstab. Judging by the naming convention, it was a userspace utility that mounted it, with some basic permissions. The following link can help with manual mounting, to get the right mask in the filesystem. Look at the second answer: askubuntu.com/questions/23108/… – darkdragn Jan 25 '16 at 16:11
  • You can run a script file from a Windows mounted drive. To make sure before posting this reference I took a drive out of an old Windows XP laptop. I mounted it with a USB/Hardrive adapter. I plugged it in. It automatically opened up the folder. I create the abc.sh file, then ran it using ./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

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.