7 ms·

http://google-styleguide.googlecode.com/svn/trunk/shell.xml?showone=File_Extensions#File_Extensions http://google-styleguide.googlecode.com/svn/trunk/shell.xml?

http://google-styleguide.googlecode.com/svn/trunk/shell.xml?showone=File_Extensions#File_Extensions http://google-styleguide.googlecode.com/svn/trunk/shell.xml?... > It is not necessary to know what language a program is written in when executing it and shell doesn't require an extension so we prefer not to use one for executables. I disagree with their recommendation against using file extensions for executables, and I'd love to have my mind changed about this. Using an extension gives you automatic syntax highlighting. It also lets you quickly glean the type of a file when exploring a directory for the first time, which is more helpful than simply knowing whether the file can be executed. Why does a lack of necessity override those two benefits?

flebron 13y ago
Your benefits are so to people who are going to be editing these files. They are not benefits to people who are going to be using these files (i.e. running the script). Most people are not going to be editing the script, they are going to be using it. Thus, it makes sense to cater to them, and to not have them have to know things they don't care about, like what language the tool they are using was programmed in.
jfb 13y ago
Any serious editor will read the #! line for syntax highlighting, which has the benefit of being much more likely to be correct than the user visible and modifiable file name.
- raverbashing 13y ago
  Except when it doesn't have that line because it's a C/C+header file. And then the editor doesn't know what to do with that header file without extension. Yes, if you see some Google C++ code they do that Really, horrible practice.
  - kondro 13y ago
    What are you doing making C header files executable?
    - raverbashing 13y ago
      Where did I say I was making it executable?
      - kondro 13y ago
        They were only advocating no extension for executable shell files, not all files.
        raverbashing 13y ago
        Yes, I remembered seeing a C++ google product without the .h extension in header files (or other similar extensions) But apparently they stopped this nonsense
        ithkuil 13y ago
        It's not google, it's C++ convention. http://stackoverflow.com/questions/301586/what-is-the-difference-between-using-includefilename-and-includefilename-h http://stackoverflow.com/questions/301586/what-is-the-differ... Btw, many editors understand // -- C++ -- Nevertheless Google's c++ style guide (https://code.google.com/p/google-styleguide/source/browse/trunk/cppguide.xml https://code.google.com/p/google-styleguide/source/browse/tr...) in fact says that headers should have the .h suffix.
        raverbashing 13y ago
        Ah thanks for pointing that out > Btw, many editors understand // -- C++ -- Maybe, but if I vim /usr/include/c++/4.2.1/iostream doesn't work (only if I set it manually)
nsmartt 13y ago
The extension is unnecessary for syntax highlighting. Shebang lines are supposed to be used for detecting the file type. As for knowing the file type at a glance, I'm not sure how often I need this. I'm normally looking for the file by name anyway. If I needed to determine the file-type, I'd write a script to parse the shebang lines of executable files in the current directory and generate a list of the files with their hypothetical extensions (based on a hash/dictionary/whatever). I don't need that very often, so, for me, the trade is worth it.
xwowsersx 13y ago
I'm new to shell scripting and I'm clearly missing something basic. Why can't you use file extensions? This is saying not to use .sh for bash scripts and .rb for ruby scripts, etc?
- packetslave 13y ago
  One reason: let's say you write tool 'foo.sh' in Bash. It does what you want and you move on to other things. It's suddenly a year from now, and your foo.sh tool needs some new features, or is too slow to do the job any more because your requirements have changed. You decide it's grown too much for Bash and want to move to Python for maintainability, or Go for performance, or C++ to link with some library you need to use. Now you have to tell your team (and any other teams that have found your tool useful): "We only want to maintain one version, so don't use 'foo.sh' any more. You have to use 'foo.py' (or 'foo.exe' or whatever). Oh, and have fun changing all YOUR scripts and tools that reference 'foo.sh'!" That's one reason.
  - MBlume 13y ago
    Now I'm wondering how many shops have some legacy script with a 'foo.sh' filename and a #!/usr/bin/python shebang
  - tlarkworthy 13y ago
    yeah, that's a good reason. I am convinced.
    - oblio 13y ago
      Not really, I'd rather do: https://news.ycombinator.com/item?id=6688782 https://news.ycombinator.com/item?id=6688782
  - oblio 13y ago
    Well, you do have some sort of deployment process, right? (as in, you're not attaching your scripts to emails) Just change it to zip foo.sh + foo.py. Then: cat foo.sh #!/bin/bash -e ./foo.py cat foo.py # Everything else has moved here. Much better.
deleted 13y ago
[deleted]
dredmorbius 13y ago
(This point is also made lower down). When you run a program, your concern should be what it is called. Not how it is written. A language-specific filename extension puts an implementation detail in userspace. If you run a binary executable, you shouldn't care whether it's written in C, C++, Fortran, or any other language (though source files, being used only by developers and compilers, generally do have extensions). Worse: if you decide for whatever reason to change the implementation language, you're either forced to track down and change all references to the program name, or to retain the (now incorrect) filename extension for backwards compatibility. And, as noted, magic(5) or the shebang line should correctly identify the file type and language for syntax highlighting -- if not, your editor is broken. Replace it with a shell script, "editor.sh". file(1) will tell you the types of files in a directory with far greater accuracy than filename extensions can.
- hacker789 13y ago
  That makes sense. I think of shell scripts as "things programmers execute", but that's obviously not always the case.
  - dredmorbius 13y ago
    They're very often things other programs execute. Cron jobs, other scripts, production jobs, etc. So having to hunt down and rename everything ... is a PITA.
txutxu 13y ago
We don't use to run grep.c, or ansible.py, or git.c, or gunzip.sh, etc... explore a directory? file -i directory/* I follow the same convention than Google, just that I use .bash for libraries instead of .sh (as they state the interpreter should be bash, I think they should apply my naming instead of .sh)

flebron 13y ago

Your benefits are so to people who are going to be editing these files. They are not benefits to people who are going to be using these files (i.e. running the script). Most people are not going to be editing the script, they are going to be using it. Thus, it makes sense to cater to them, and to not have them have to know things they don't care about, like what language the tool they are using was programmed in.

jfb 13y ago

Any serious editor will read the #! line for syntax highlighting, which has the benefit of being much more likely to be correct than the user visible and modifiable file name.

raverbashing 13y ago
Except when it doesn't have that line because it's a C/C+header file. And then the editor doesn't know what to do with that header file without extension. Yes, if you see some Google C++ code they do that Really, horrible practice.
- kondro 13y ago
  What are you doing making C header files executable?
  - raverbashing 13y ago
    Where did I say I was making it executable?
    - kondro 13y ago
      They were only advocating no extension for executable shell files, not all files.
      - raverbashing 13y ago
        Yes, I remembered seeing a C++ google product without the .h extension in header files (or other similar extensions) But apparently they stopped this nonsense
        ithkuil 13y ago
        It's not google, it's C++ convention. http://stackoverflow.com/questions/301586/what-is-the-difference-between-using-includefilename-and-includefilename-h http://stackoverflow.com/questions/301586/what-is-the-differ... Btw, many editors understand // -- C++ -- Nevertheless Google's c++ style guide (https://code.google.com/p/google-styleguide/source/browse/trunk/cppguide.xml https://code.google.com/p/google-styleguide/source/browse/tr...) in fact says that headers should have the .h suffix.
        raverbashing 13y ago
        Ah thanks for pointing that out > Btw, many editors understand // -- C++ -- Maybe, but if I vim /usr/include/c++/4.2.1/iostream doesn't work (only if I set it manually)

nsmartt 13y ago

The extension is unnecessary for syntax highlighting. Shebang lines are supposed to be used for detecting the file type. As for knowing the file type at a glance, I'm not sure how often I need this. I'm normally looking for the file by name anyway. If I needed to determine the file-type, I'd write a script to parse the shebang lines of executable files in the current directory and generate a list of the files with their hypothetical extensions (based on a hash/dictionary/whatever). I don't need that very often, so, for me, the trade is worth it.

xwowsersx 13y ago

I'm new to shell scripting and I'm clearly missing something basic. Why can't you use file extensions? This is saying not to use .sh for bash scripts and .rb for ruby scripts, etc?

packetslave 13y ago
One reason: let's say you write tool 'foo.sh' in Bash. It does what you want and you move on to other things. It's suddenly a year from now, and your foo.sh tool needs some new features, or is too slow to do the job any more because your requirements have changed. You decide it's grown too much for Bash and want to move to Python for maintainability, or Go for performance, or C++ to link with some library you need to use. Now you have to tell your team (and any other teams that have found your tool useful): "We only want to maintain one version, so don't use 'foo.sh' any more. You have to use 'foo.py' (or 'foo.exe' or whatever). Oh, and have fun changing all YOUR scripts and tools that reference 'foo.sh'!" That's one reason.
- MBlume 13y ago
  Now I'm wondering how many shops have some legacy script with a 'foo.sh' filename and a #!/usr/bin/python shebang
- tlarkworthy 13y ago
  yeah, that's a good reason. I am convinced.
  - oblio 13y ago
    Not really, I'd rather do: https://news.ycombinator.com/item?id=6688782 https://news.ycombinator.com/item?id=6688782
- oblio 13y ago
  Well, you do have some sort of deployment process, right? (as in, you're not attaching your scripts to emails) Just change it to zip foo.sh + foo.py. Then: cat foo.sh #!/bin/bash -e ./foo.py cat foo.py # Everything else has moved here. Much better.

deleted 13y ago

[deleted]

dredmorbius 13y ago

(This point is also made lower down). When you run a program, your concern should be what it is called. Not how it is written. A language-specific filename extension puts an implementation detail in userspace. If you run a binary executable, you shouldn't care whether it's written in C, C++, Fortran, or any other language (though source files, being used only by developers and compilers, generally do have extensions). Worse: if you decide for whatever reason to change the implementation language, you're either forced to track down and change all references to the program name, or to retain the (now incorrect) filename extension for backwards compatibility. And, as noted, magic(5) or the shebang line should correctly identify the file type and language for syntax highlighting -- if not, your editor is broken. Replace it with a shell script, "editor.sh". file(1) will tell you the types of files in a directory with far greater accuracy than filename extensions can.

hacker789 13y ago
That makes sense. I think of shell scripts as "things programmers execute", but that's obviously not always the case.
- dredmorbius 13y ago
  They're very often things other programs execute. Cron jobs, other scripts, production jobs, etc. So having to hunt down and rename everything ... is a PITA.

txutxu 13y ago

We don't use to run grep.c, or ansible.py, or git.c, or gunzip.sh, etc... explore a directory? file -i directory/* I follow the same convention than Google, just that I use .bash for libraries instead of .sh (as they state the interpreter should be bash, I think they should apply my naming instead of .sh)