Krdytkyu

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

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.

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

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

Ex:

mv abc.sh ~/

cd ~

chmod +x abc.sh

./abc.sh