6 ms·

> Use the .sh (or .bash) extension for your file. It may be fancy to not have an extension for your script, but unless your case explicitly depends on it, you’r

> Use the .sh (or .bash) extension for your file. It may be fancy to not have an extension for your script, but unless your case explicitly depends on it, you’re probably just trying to do clever stuff. Clever stuff are hard to understand. I don't agree with this one. When I name my script without extension (btw, .sh is fine, .bash is ugly) I want my script to look just like any other command: as a user I do not care what the language program is written in, I care about its output and what it does. When I develop a script, I get the correct syntax highlight becuase of the shebang so the extension doesn't matter. The rest of the post is great.

asicsp 4y ago
My thumb rule is no extension if the script goes to the local bin folder and `.sh` otherwise. Beyond syntax highlighting, the extension also helps for wildcard matching for file operations (`ls`, `cp`, `for` loop, etc).
- _wolfie_ 4y ago
  Though in any non-trash editor you get syntax highlight based on shebang line alone. One advantage of no-extension is that you can swap the implementation language later without "breaking" shell history for people in your team.
- Sponge5 4y ago
  What I do is have a scripts folder where the names have extensions and which is version controlled and symlink them from `.local/bin`
- nrvn 4y ago
  And this rule has been followed the majority(if not all) interpreted and scripting languages. The likes of Ruby, python and JS have multiple examples. Whatever executable is in your $PATH it won’t have an extension. Not sure if this convention is actually documented anywhere. Random examples: - https://github.com/PyCQA/isort/blob/main/pyproject.toml#L100 https://github.com/PyCQA/isort/blob/main/pyproject.toml#L100 - https://github.com/pypa/pip/blob/main/setup.py#L78 https://github.com/pypa/pip/blob/main/setup.py#L78 - https://github.com/11ty/eleventy/blob/master/package.json#L10 https://github.com/11ty/eleventy/blob/master/package.json#L1...
- 0xbadcafebee 4y ago
  shellcheck *.sh FTW
hdjjhhvvhga 4y ago
> .bash is ugly "Ugly" is subjective. If I encountered a file with that extension, I'd assume it uses Bash-specific features and that I shouldn't run this script with another shell.
- Octabrain 4y ago
  Subjetive, indeed. But unless I am missing something, the interpreter to be used should be determined by the shebang within the script though?
  - selectnull 4y ago
    Extension or not, .sh or .bash: definitely subjective. That was the intention of my comment. Because the rest of the post (or most of it for sure) is not subjective.
  - erlkonig 4y ago
    It's the effect of the extension on USER behavior that's the problem, the OS doesn't care.
    - Octabrain 4y ago
      Yes, I get it. But in my case I simply give u+x permissions to the script and then run "./script.sh" and then the script will be executed with the interpreter defined in the shebang.
- ndsipa_pomu 4y ago
  The hashbang already specifies the shell, so also having it in the extension seems unnecessary. I don't like using '.sh' as an extension as it differs from other OS commands and I can't think where it's actually helpful.
  - Beltalowda 4y ago
    If you download a script then running "sh script.sh" is a lot quicker and easier than a chmod followed by ./script.sh. You can of course also type "bash script.sh", but I don't always have it installed on every system, and the .bash extension just clarifies it. For things in my PATH I drop any suffixes like that.
nephrite 4y ago
In my setup, I use aliases or functions to have short/mnemonic names for commands. But the files on disk must always have proper extensions like .sh to quickly see what they are.
- erlkonig 4y ago
  The extensions are improper from the outset. Commands should not have extensions.
Octabrain 4y ago
Personally, I prefer to keep the extension and add and alias in my aliases file inside "~/.bashrc.d". Redudant, perhaps, but I like to run a ls inside "~/.local/bin" (the place where I throw user wide personal executables) and be able to see at first glance what is a binary and what is a script.
pindab0ter 4y ago
There are use cases where you don't have execute privileges. In those cases the .sh-extension makes it clear that you can do `bash script.sh`. If you don't use an extension you wouldn't easily see that that was an option.
- erlkonig 4y ago
  No, it doesn't. The extensions are usually too inaccurate to rely on. That could be either a Bourne or Bash script, meaning it could either fail at some arbitrary point during run if the wrong one is used, or just subtly, critically change some output. Much more true for Python scripts.
ilyt 4y ago
I honestly do it mostly coz IDEA is/was mighty stupid when it comes to detecting file types compared to Emacs... altho newer editions seemed to fix that problem for the most part
wazoox 4y ago
Also an extension will prevent execution from cron.d on Debian-based systems.
- ndsipa_pomu 4y ago
  Really? I've never heard of that and I mainly use Ubuntu which is Debian-based

asicsp 4y ago

My thumb rule is no extension if the script goes to the local bin folder and `.sh` otherwise. Beyond syntax highlighting, the extension also helps for wildcard matching for file operations (`ls`, `cp`, `for` loop, etc).

_wolfie_ 4y ago
Though in any non-trash editor you get syntax highlight based on shebang line alone. One advantage of no-extension is that you can swap the implementation language later without "breaking" shell history for people in your team.
Sponge5 4y ago
What I do is have a scripts folder where the names have extensions and which is version controlled and symlink them from `.local/bin`
nrvn 4y ago
And this rule has been followed the majority(if not all) interpreted and scripting languages. The likes of Ruby, python and JS have multiple examples. Whatever executable is in your $PATH it won’t have an extension. Not sure if this convention is actually documented anywhere. Random examples: - https://github.com/PyCQA/isort/blob/main/pyproject.toml#L100 https://github.com/PyCQA/isort/blob/main/pyproject.toml#L100 - https://github.com/pypa/pip/blob/main/setup.py#L78 https://github.com/pypa/pip/blob/main/setup.py#L78 - https://github.com/11ty/eleventy/blob/master/package.json#L10 https://github.com/11ty/eleventy/blob/master/package.json#L1...
0xbadcafebee 4y ago
shellcheck *.sh FTW

hdjjhhvvhga 4y ago

> .bash is ugly "Ugly" is subjective. If I encountered a file with that extension, I'd assume it uses Bash-specific features and that I shouldn't run this script with another shell.

Octabrain 4y ago
Subjetive, indeed. But unless I am missing something, the interpreter to be used should be determined by the shebang within the script though?
- selectnull 4y ago
  Extension or not, .sh or .bash: definitely subjective. That was the intention of my comment. Because the rest of the post (or most of it for sure) is not subjective.
- erlkonig 4y ago
  It's the effect of the extension on USER behavior that's the problem, the OS doesn't care.
  - Octabrain 4y ago
    Yes, I get it. But in my case I simply give u+x permissions to the script and then run "./script.sh" and then the script will be executed with the interpreter defined in the shebang.
ndsipa_pomu 4y ago
The hashbang already specifies the shell, so also having it in the extension seems unnecessary. I don't like using '.sh' as an extension as it differs from other OS commands and I can't think where it's actually helpful.
- Beltalowda 4y ago
  If you download a script then running "sh script.sh" is a lot quicker and easier than a chmod followed by ./script.sh. You can of course also type "bash script.sh", but I don't always have it installed on every system, and the .bash extension just clarifies it. For things in my PATH I drop any suffixes like that.

nephrite 4y ago

In my setup, I use aliases or functions to have short/mnemonic names for commands. But the files on disk must always have proper extensions like .sh to quickly see what they are.

erlkonig 4y ago
The extensions are improper from the outset. Commands should not have extensions.

Octabrain 4y ago

Personally, I prefer to keep the extension and add and alias in my aliases file inside "~/.bashrc.d". Redudant, perhaps, but I like to run a ls inside "~/.local/bin" (the place where I throw user wide personal executables) and be able to see at first glance what is a binary and what is a script.

pindab0ter 4y ago

There are use cases where you don't have execute privileges. In those cases the .sh-extension makes it clear that you can do `bash script.sh`. If you don't use an extension you wouldn't easily see that that was an option.

erlkonig 4y ago
No, it doesn't. The extensions are usually too inaccurate to rely on. That could be either a Bourne or Bash script, meaning it could either fail at some arbitrary point during run if the wrong one is used, or just subtly, critically change some output. Much more true for Python scripts.

ilyt 4y ago

I honestly do it mostly coz IDEA is/was mighty stupid when it comes to detecting file types compared to Emacs... altho newer editions seemed to fix that problem for the most part

wazoox 4y ago

Also an extension will prevent execution from cron.d on Debian-based systems.

ndsipa_pomu 4y ago
Really? I've never heard of that and I mainly use Ubuntu which is Debian-based