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.
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).
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
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.
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:
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
# Source global definitions
if [ -f /etc/bashrc ]; then
# User specific environment
if ! [[ "$PATH" =~ "$HOME/.local/bin:$HOME/bin:" ]]
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:
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.
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.
@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.
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.