[filename].sh not executable

Fedora 34; KDE (Breeze Dark); but this concerns Gnome Terminal, not Konsole (bc Konsole’s characters are invisible…?)

I have a shell script, saved as [filename].sh . Regardless of whether I ‘chmod +x’ the file or use Dolphin to make it executable, the file does not execute. However, when I drag it into a Terminal after entering ‘sudo bash’ then it executes.

Why might the .sh file itself not execute?

1 Like

Can we see the full permissions on the file?

Where in the file system is it located?

1 Like


If you’re trying to run the shell script from your file manager (Dolphin or whatever) make sure you check the file manager’s preferences.

In Nautilus (Gnome) and Nemo (Cinnamon), there’s a behaviour tab in the preferences that determines whether an executable text file is displayed or run when clicked. The default is ‘displayed’, so that’s probably the problem if you’re running it from the file manager.

From a command line, you’ll need to preface the file with ./ (like ./test.sh) unless the directory containing the script is in your path ($PATH).


The file is in my user/documents directory.

Permissions are rwxr-xr-x (755).

Dolphin’s ‘behavior’ tab is different, but (a) there’s an executable checkbox (which is checked), and (b) when the file is clicked in the GUI a confirmation dialog pops up to offer open or execution.

Idk if this means definitively that it is a KDE bug, but when I try to click the file in the GUI, or when I try to execute the file in Terminal preceded by “,/”, there’s an error message:
Unknown error code 100
execvp: Exec format error
Please send a full bug report […]

It works this way, but only this way (thank you, @Jonathan S):

  • cd into the directory containing the file
  • terminal: ./[filename]

I guess that’s good enough, since it works, but it would be nice to understand why it doesn’t work through the GUI or by pasting the file path and name into a terminal in a different directory. Much appreciate anyone’s taking the time to answer, but the urgency is now gone.

What are you trying to run? Is it something that requires running in a terminal? Is it a script?

If it is a script, can we see the contents?

1 Like


Re Dolphin, the preference you want is under General/Confirmation - at the bottom you have ‘When opening an executable file:’.

It only makes sense to open a file from Dolphin (or any file manager) if the script doesn’t run and terminate - if it does run and terminate, you won’t see any output and won’t know whether it’s run correctly (or at all!). When you can sensibly run it Dolphin is when it does something like opening a program for displaying a file.

To make sense of why you need to cd to the directory before you can run your script, you need to read up a bit about absolute and relative paths, such as:


You can google for more details.

So you can run /home/joe/Documents/test.sh or ~/Documents/test.sh, or go to the directory and use ./test.sh
Notice that this last (./test.sh) is using the dot (not a comma) to mean the current directory.

If you’re in /home/joe/Documents can also do things like listing /home/joe by using:

 ls -l ..

(where the two dots mean the parent directory)

You should be aware that (unlike Windows), the path ($PATH) does not (by default) include the current directory, hence the need for the ./

There’s an awful lot you can do with bash (which is the name of the shell your script is written in). The documentation is here:


Don’t worry if most of it doesn’t make sense, but bits might be helpful if you write a script that doesn’t work.


It is not running without the path because where you have your scripts, this part of directory is not in the $PATH variable so bash doesn’t know where to find it.
So, if you create a sub-folder bin in your home directory, you can put everything there (your own scripts). This folder is in the $PATH variable. This is made by every login, have a look in:

$ cat .bashrc
# .bashrc

# Source global definitions
if [ -f /etc/bashrc ]; then
	. /etc/bashrc

# User specific environment
if ! [[ "$PATH" =~ "$HOME/.local/bin:$HOME/bin:" ]]
export PATH

now you just have to set up in the terminal under “Title & Comand” the option “Run command as a login shell”

Now you are ready to create your own Scripts and use them as custom-commands like I made for Updating the System with dnf:

create a file named up in ~/bin

# example@example.com
sudo dnf up

voila, happy “BASHing” :wink:

1 Like

Thank you @jonathans . I’m hungrily digesting as much Linux as possible, so that’s helpful. As for the script’s terminating or not, it opens a secure tunnel and stays open while another app connects to remote machines. Then I close the tunnel and exit the shell.

This is great, @ilikelinux . I’ll create the subdirectory for various scripts. Not sure what it means, or why I would want, to run the command as a login shell, but I’ll research that. Thank you.

1 Like

Wrong! Having the script in a directory that isn’t in your PATH doesn’t prevent it from being executable, it just means that you have to specify the directory the script is in when executing it. Please learn how these things work (It isn’t rocket surgery, you know.) before you give any more wrong information to people.


Can we please remember to stay excellent to each other even when pointing out that some information is wrong?


1 Like

@sideburns I hope you red the rest of the request and also the Title of it? Before you come and offend you better make a statement who is correct and also has something to do about the topic.

The question was, why he needs to put a path or at least ./filname.sh to execute a script, even if the script has the correct rights. I just hope @sideburns you will take also time to find links or at least make an example/statement that helps to solve the problem for the next one who reads this.

1 Like

@sideburns better this way?

As I understood you like to double click on a launcher or file to execute a script and see the terminal poping up and closing when done ?!

I had a similar situation and solved it with a launcher alias i started the script with the auto-start function.
In the execution field of the launcher or the auto-start you have to put :

Exec=gnome-terminal --geometry=112x24+600 --window -e /path/to/your/file.sh

A good practice when you run a script from auto-start/launcher is to mention that you can interrupt it. This i solved this way:

# Banner
echo -e ""
echo -e "***************************************************************"
echo -e "******       Press any key to load  'your script'        ******"
echo -e "******                                                   ******"
echo -e "******      or interrupt the script with 'Ctrl & C'      ******"

# Pause the program.
read -n1 -r -p "***************************************************************" key

It will run the .bashrc always you start your script. So you have the path variable and other things you configured available … like aliases etc.

I use this with the Mate desktop, but it should work also with Gnome. Test it with the KDE Desktop to see if it works there too (it should, as you use gnome-terminal).

A good Idea would be to change the Title and also mark a solution. As you can read from all the answers the term “executable” is not very correct.

“Running a Bash script from a file-manager or launcher/auto-start” would be more adequate.

That would have been completely right if you’d added, “…so bash doesn’t know where to find it.” That would have told the OP why he had to specify the path which would have helped him avoid this issue in the future.

Having the file run in a different directory is dependent upon 2 things (but it boils down to the same thing)
The linux file system has to allow the file to be executable (which you show with the 755 permissions) and you have to have execute permissions in the directory where you are trying to run it. You also may need write permissions wherever it attempts to write any output.

The second factor is selinux, which fedora has in enforcing mode by default. SELinux may give you execute permissions where the file is located and successfully runs but not in the other directory where you are trying to run it.

Both factors boil down to the need for execute permissions at the location where you are executing the file.

@ilikelinux I think your scripts would be helpful, but I don’t know enough Linux yet…

Your suggestion to change the title is good, but I can no longer edit it.

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.