18

I was wondering what's the need to put executable commands inside a .sh file to make a single script, since I can do the same by putting the commands inside a .txt file and making it executable using chmod.

I'm assuming this can be done with any of the file extensions. So, I am quite confused about the need for .sh extension. Any help would be much appreciated.

  • 19
    Unix does traditionally not care about file extensions. So you're correct - it does not matter. It purely to make it obvious to the reader that it's a shell script – vidarlo May 1 '18 at 16:41
  • 8
    files extensions in Linux are not used by the OS in any real fashion. Putting a .sh extension merely tells the user that it is a shell script, as opposed to some other type of file, like a python or perl script. Personally, I don't put extensions on my scripts. – doneal24 May 1 '18 at 16:42
  • 2
    It's needed only to tell you or anyone else looking at it that it's a shell script. If you don't care about telling which .txt files are scripts to run and which are text to be opened in an editor, feel free to name everything .txt! – daboross May 1 '18 at 18:44
  • 2
    Right.txt, but.txt if.txt everything.txt ends.txt with.txt the.txt .txt.txt suffix.txt, you're.txt not.txt helping.txt yourself.txt (or.txt anybody.txt else.txt) understanding.txt what.txt each.txt file.txt is.txt there.txt for.txt. – leftaroundabout May 2 '18 at 12:32
  • 1
    This is similar to the question of which this is a supposed duplicate, but that question doesn't actually answer this one. – Kenny Evitt May 2 '18 at 20:20
47

There is no need for the file extension to match anything specific, as you correctly found out.

On Unix-like systems, file types are usually derived from the content of the file (i.e. the "magic number" or other characteristic structures in the first few bytes) and not from their name. You could also completely omit the extension, which is often done for executables.

Check the file command, it shows you the information it can find out about a file type from its content.

For an executable script, the system expects a so-called "shebang" in the first line, which looks e.g. like

#!/usr/bin/env python3

and indicates which program to run as interpreter with the script file as argument. If you execute a text file without such a shebang, it will use your default shell, i.e. Bash to try and interpret it.

So on Unix/Linux systems, file name extensions are mostly a hint (but no guarantee) for the human user to quickly recognize what to expect a specific file to contain. It's also a convention that can help e.g. finding files faster.

Note that there are some exceptions though, where the name and extension matters (e.g. some system config files which must follow a naming convention, or many image viewers and editors also require the extension to indicate the file type).

You can also have a look at Do file-extensions have any purpose (for the operating system)?

  • 3
    File extensions don't matter in a shell, but in a world of GUI OSes, you pretty much need them to make double clicking work correctly. – BallpointBen May 2 '18 at 0:06
  • @BallpointBen the two points are unrelated. Even under a GUI the "type" of a file can be stored alongside, as a metadata, and could trigger a specific execution, irrespective to have the extension is. MacOS does not have file names extensions and is a GUI and survives it very well... – Patrick Mevzek May 2 '18 at 0:54
  • 1
    @PatrickMevzek how dows MacOS not have extensions ? I enabled showing them and all files have them. Am I missing something ? I am new to the MacOS platform – Ciprian Tomoiagă May 2 '18 at 8:30
  • 1
    @CiprianTomoiagă you can name your files anyway you like, the OS does not need the extension to work correctly on them. See for example: howtogeek.com/192628/… – Patrick Mevzek May 2 '18 at 13:33
  • 1
    @barbecue targeting the lowest common denominator... what can go wrong with that :-) (like attacks through email attached files called something.com.txt and doing tricks to skip the .txt as .com as specific meaning in Windows-land). Indeed, for interoperability file extensions may be a good practice. One has to learn though that this is clearly a defect introduced by DOS basically and that various OS live perfectly happy with files without extensions. – Patrick Mevzek May 2 '18 at 17:26
3

There is no such thing as a file "extension" or "type" in a UNIX/Linux file name.

As others have pointed out, the "type" may be found using the file command assuming that the relevant magic is available on your system. UNIX/Linux file names can normally contain any character available but it often helpful to use some form of convention for the name so that both humans and machines can make judgements as to content (and hence usage of the content).

As an example, I often use a comma as first character of the file name to indicate a temporary file rather than using something like the string ".tmp" at the end of the filename. The result is the same, a file containing data that is only required for a short time perhaps but the name does not require to have a "." within it nor the string "tmp". This can sometimes have advantages e.g. when parsing a list of file names. But it is MY convention and someone else may decide on another even using ".tmp" as their convention of a name for a temporary file.

So my answer to you is that there is no such thing as a UNIX/Linux file extension merely a set of conventions that typically look like the file extensions used in other operating systems and their file systems.

  • FWIW, I also use a non-standard convention for myself. My scripts whose names start with "." are meant to be dotted by the shell (they cannot run meaningfully in a subshell). Correspondingly, I disable the default "initial dot = hidden file" convention in my aliases/scripts which use ls so that I can see all the files, including the "hidden" ones. Similarly on Windows, I disable the "hide file extensions" setting. – jrw32982 supports Monica May 3 '18 at 20:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.