Last Updated:

What is the Bash File Extension?

I wrote the bash script in a text editor. Which extension should I save the script so that it can work as a bash script? I created a script that should theoretically run an ssh server. I'm wondering how to get a script to run when I click on it. I'm using OS X 10.9.5.


Disagreeing with other answers, there is a general agreement to use the extension for shell scripts, but this is not a useful convention. It is better not to use the extension at all. The advantage of being able to determine what is a shell script is because its name is minimal and you pay for it with a loss of flexibility. .sh foo.sh

To make a bash script executable, it must have the line shebang at the top:

 #!/Bin/bash 

and use the command to make the system recognize it as an executable file. It must then be installed in one of the directories listed in your . If the script is named , you can execute it from the shell prompt by typing . Or, if it's in the current directory (usually for temporary scenarios), you can type . chmod + x $ PATH foo foo ./foo

Neither the shell nor the operating system pays attention to this part of the file name extension. It's just part of the name. And by not giving it a special extension, you guarantee that any (whether user or other script) that uses it shouldn't care how it was implemented, whether it's a shell script (sh, bash, csh, or anything else), a Perl, Python, or Awk script, or an executable binary. The system is specifically designed in such a way that an interpreted script or binary executable can be invoked without knowing or caring how it is implemented.

UNIX-like systems began with a purely text-based command-line interface. Later, graphical interfaces such as KDE and Gnome were added. In a desktop system with a graphical user interface, you can usually launch a program (again, whether it's a script or an executable file), for example, by double-clicking the icon that references it. This usually discards any output that the program might print and does not allow command-line arguments to be passed; it is much less flexible than running from the command line. But for some programs (mostly GUI clients), this may be more convenient.

Shell scripts are best learned from the command line rather than from a graphical interface.

(Some tools do pay attention to file extensions; for example, compilers typically use the extension to determine the language in which the code is written: for C, for c++, etc. This convention does not apply to executable files.) .c .cpp

Keep in mind that UNIX (and UNIX-like systems) are not Windows. MS Windows usually uses the file extension to determine how to open/run it. Binary executable files must have a .. If Windows has a UNIX-like shell installed, you can configure Windows to recognize the extension as a shell script and use the shell to open it; There is no agreement in Windows. .exe .sh #!


You don't need any extension (or you can choose an arbitrary but useful convention). .sh

You should start your script with (this first line is understood by the execve system call (2)), and you should make your file executable using . therefore, if your script is in some file, you need to enter once #!/bin/bash chmod u + x $ HOME/somedir/somescriptname.sh

 chmod u + x $ HOME /somedir/somescriptname.sh

in the terminal. Cm. Chmod (1) for the command and chmod (2) for the system call.

If you do not enter the full path to the file, you should place this file in some directory specified in yours (see Environment (7) and execvp (3)), which you can install permanently in your own if your login shell is PATH ~/.bashrc bash )

By the way, you can write your script in another language, for example in Python, by running it with , or in Ocaml, running it with .. . #!/usr/bin/python #!/usr/bin/ocaml

Double-clicking your script (what? you didn't say it!) is a desktop environment issue and can be desktop-specific (may differ in Kde, Mate, Gnome, .... or IceWM or RatPoison). Perhaps reading the EWMH specification will help you understand better.

Perhaps creating a script executable file with a help can make it clickable on the desktop (apparently Quartz on macOSX). But then you should probably make it give visual feedback. chmod

And some computers don't have a desktop, including your own, when you access it remotely via ssh.

I don't think to run a shell script by clicking. You'll probably want to provide arguments to your shell script (and how would you do that by clicking?), and you should take care of its output. If you can write a shell script, you can use an interactive shell in the terminal. This is the best and most natural way to use a script. Good interactive shells (like zsh or fish or maybe recent) have delightful and customizable autocomplete tools, and you won't have to type much (learn how to use a tab on your keyboard). In addition, scripts and programs are often parts of composite commands (pipelines, etc.). bash

PS. I've been using Unix since 1986 and Linux since 1993. I've never run my own programs or scripts by clicking. Why should I?

 
 

You don't need any extension (or you can choose any, but .sh is a useful convention).

You have to start your script with (this first line is understood execve (2) syscall), and you have to make your file executable using . therefore, if your script is in some file, you need to enter once #!/bin/bash chmod u + x $ HOME/somedir/somescriptname.sh

 chmod u + x $ HOME /somedir/somescriptname.sh

in the terminal. Cm. Chmod (1) for the command and chmod (2) for the system call.

If you do not enter the full path to the file, you should place this file in some directory specified in yours (see Environment (7) and execvp (3)), which you can install permanently in your own if your login shell is PATH ~/.bashrc bash )

By the way, you can write your script in another language, for example in Python, by running it with , or in Ocaml, running it with .. . #!/usr/bin/python #!/usr/bin/ocaml

Double-clicking your script (what? you didn't say it!) is a desktop environment issue and can be desktop-specific (may differ in Kde, Mate, Gnome, .... or IceWM or RatPoison). Perhaps reading the EWMH specification will help you understand better.

Perhaps creating a script executable file with a help can make it clickable on the desktop (apparently Quartz on macOSX). But then you should probably make it give visual feedback. chmod

And some computers don't have a desktop, including your own, when you access it remotely via ssh.

I don't think to run a shell script by clicking. You'll probably want to provide arguments to your shell script (and how would you do that by clicking?), and you should take care of its output. If you can write a shell script, you can use an interactive shell in the terminal. This is the best and most natural way to use a script. Good interactive shells (like zsh or fish or maybe recent) have delightful and customizable autocomplete tools, and you won't have to type much (learn how to use a tab on your keyboard). In addition, scripts and programs are often parts of composite commands (pipelines, etc.). bash

PS. I've been using Unix since 1986 and Linux since 1993. I've never run my own programs or scripts by clicking. Why should I?


simply. .sh

Run the script as follows:

 ./script.sh 

EDIT: As Anubhava said, expansion is not really important. But for organizational reasons, it is still recommended to use extensions.

 
 
 

simply. .sh

Run the script as follows:

 ./script.sh 

EDIT: As Anubhava said, the extension doesn't matter. But for organizational reasons, it is still recommended to use extensions.


I know it's been around for quite some time now, but I feel like it adds to what the question was asking.

If you're using a Mac and want to be able to run a script by double-clicking on it, you'll need to use the . Just as before, make the file executable using . .command chmod -x

As noted earlier, it's actually not that useful, tbh.

 
 

I know it's been around for quite some time now, but I feel like it adds to what the question was asking about.

If you have a Mac and want to be able to run a script by double-clicking it, you'll need to use the . Just as before, make the file executable using . .command chmod -x

As noted earlier, it's actually not that useful, tbh.


TL; DR — If the user (not necessarily the developer) of the script uses a graphical interface, it depends on which file browser he is using. The macOS Finder requires an extension to run the script. Gnome Nautilus, however, recognizes properly formatted scripts with or without an extension. .sh .sh

I know I've already talked several times about the reasons and against using extension in bash scripts, but not so much why or why not to use extensions, but I have what I think is a good rule of thumb.

If you're one of those who jumps both outside of bash and using the terminal as a whole, or are developing a tool for someone else who isn't using the terminal, add an extension to your bash scripts. Therefore, users of this script have the option to double-click this file in the GUI file browser to run the script. .sh

If you're the type of person who primarily does all or most of your work in terminal, don't worry about adding any extensions to your bash scripts. In the terminal, they are useless if you have already configured the file to visually distinguish scripts from directories. ~/.bashrc

Change:

In the Gnome Nautilus file browser with 4 test files (each with permissions granted for the file to be run) with a silly simple bash command to open a terminal window (): gnome-terminal

  1. file without the extension with in the first line . #!/bin/bash

    It worked by double-clicking on the file.

  2. The file with the extension in the first line. .sh #!/bin/bash

    It worked by double-clicking a file.

  3. File without extension with NO in the first line. #!/bin/bash

    It worked by double-clicking on the file... technically, but the GUI didn't indicate that it was a shell script. He said it was just a text file.

  4. A file with an extension without in the first line. .sh #!/bin/bash

    It worked by double-clicking on the file.

However, as Keith Thompson wisely noted in the comments to this answer, relying on using the extension instead of bash shebang in the first line of the file (), this could cause problems. .sh #!/bin/bash

However, I remember when I previously used macOS, it even moved correctly (that's the word ?) bash scripts without the extension could not be run from the GUI in macOS. I'd like someone to correct me about this in the comments. If this is the case, then this proves that there is at least one file browser for which the . .sh .sh

 
 
 

TL; DR — If the user (not necessarily the developer) of the script uses a graphical interface, it depends on which file browser he is using. The macOS Finder requires an extension to run the script. Gnome Nautilus, however, recognizes properly formatted scripts with or without an extension. .sh .sh

I know I've already talked several times about the reasons and against using extension in bash scripts, but not so much why or why not to use extensions, but I have what I think is a good rule of thumb.

If you're one of those who jumps both outside of bash and using the terminal as a whole, or are developing a tool for someone else who isn't using the terminal, add an extension to your bash scripts. Therefore, users of this script have the option to double-click this file in the GUI file browser to run the script. .sh

If you're the type of person who primarily does all or most of your work in terminal, don't worry about adding any extensions to your bash scripts. In the terminal, they are useless if you have already configured the file to visually distinguish scripts from directories. ~/.bashrc

Change:

In the Gnome Nautilus file browser with 4 test files (each with permissions granted for the file to be run) with a silly simple bash command to open a terminal window (): gnome-terminal

  1. file without the extension with in the first line . #!/bin/bash

    It worked by double-clicking on the file.

  2. The file with the extension in the first line. .sh #!/bin/bash

    It worked by double-clicking a file.

  3. File without extension and NO in the first line. #!/bin/bash

    It worked by double-clicking on the file... technically, but the GUI didn't indicate that it was a shell script. He said it was just a text file.

  4. A file with an extension without in the first line. .sh #!/bin/bash

    It worked by double-clicking on the file.

However, as Keith Thompson wisely noted in the comments to this answer, relying on using the extension instead of bash shebang in the first line of the file (), this could cause problems. .sh #!/bin/bash

However, I remember when I previously used macOS, it even moved correctly (that's the word ?) bash scripts without the extension could not be run from the GUI in macOS. I'd like someone to correct me about this in the comments. If this is the case, then this proves that there is at least one file browser for which the . .sh .sh