-1

I have a `start.sh' program

me@host:~$ cat start.sh
nohup google-chrome &
nohup lantern &
xdg-open .
emacs &

Tried to run it

me@host:~$ ./start.sh
bash: ./start.sh: Permission denied
me@host:~$ sudo ./start.sh
[sudo] password for gaowei: 
sudo: ./start.sh: command not found

Nonetheless, this works

me@host:~$ bash start.sh
nohup: appending output to 'nohup.out'
nohup: appending output to 'nohup.out'

I cannot figure out what's the problem to employ './start.sh'

me@host:~$ ls | grep 'start.sh'
start.sh
Alice
  • 1,360
  • 2
  • 13
  • 28

1 Answers1

1

What is happening is that you do not have permission to execute your start.sh file. What you have to do is either give execution permission to file like so, if you are the owner of the file.

chmod u+x start.sh

or run it using sh or bash command

sh start.sh

or

bash start.sh

will execute it, no need for execution permission.

NOTE: Read somewhere that later is needed in Mac OS in some cases. Correct me if I am wrong.

EDIT: Per @GordonDavisson comment. In your case, with simple script, it does not matter if you use Bourne shell or BASH (sh or bash) but in many cases you will have to specify which shell to use, and the best way to do so is to put #!/bin/bash (#!/usr/bin/env bash on MacOS) of every script. #!/bin/bash will force use of bash, if file is executed by giving it execution permission and running it with ./start.sh

One fact:

  • Bourne shell is sh
  • Bourne Again shell bash

I cannot figure out what's the problem to employ './start.sh'

do this:

ls -l start.sh

you should get something like this:

-rw-r--r-- 1 <username> <group> 1 Mar 17 08:57 start.sh

there lays your problem. You do not have executive rights to it. If your username is not same as <username>, but you are member of a group <group> you could do following:

chmod g+x start.sh

You can give everybody else (not the <user> and not the member of the <group>) execution permission (REALLY BAD IDEA) by doing this:

chmod o+x start.sh

To give execution permission to all users:

chmod +x start.sh

which is also a bad idea.

  • 1
    The best way to do it is to add a shebang line (like `#!/bin/bash`) as the first line of the script, set execute permission, then run it with `./start.sh`. Running it with `sh` disables some or all `bash` features (even if the shebang specifies `bash`). This particular script doesn't depend on any bash-only features, but unless you know what falls into that category it's best to avoid the risk. – Gordon Davisson Mar 17 '19 at 05:35
  • @GordonDavisson I improved my answer. Thank you for suggestion, please fill free to give me more suggestions. –  Mar 17 '19 at 13:54
  • 1
    One more correction: running a script with `sh` or `bash` will override the shebang, not the other way around. Setting the right shebang and then just running the script directly (without specifying which shell to use) is generally best. Oh, and I wouldn't worry about user/group/other permissions; unless there's a special reason to restrict access, just use `chmod +x` to make it executable for all. (And if there is a need to restrict it, you should also remove read access for anyone who shouldn't be able to run it.) – Gordon Davisson Mar 19 '19 at 03:40
  • @GordonDavisson I value your input, i fixed override part. For somebody who is learning Linux user/group/others/all, but I learned to be caucus on SO in regards to little details like permissions. Once again thank you!!! Honestly I learned about `sh ...` is overriding `#!/bin/bash`. –  Mar 19 '19 at 22:14