Hacker News Reader

Comment by hacker789 | Hacker News Reader

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?

View on HN

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.

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.

What are you doing making C header files executable?

Where did I say I was making it executable?

They were only advocating no extension for executable shell files, not all files.

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

It's not google, it's C++ convention.

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/tr...) in fact says that headers should have the .h suffix.

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)

(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.

That makes sense. I think of shell scripts as "things programmers execute", but that's obviously not always the case.

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.

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.

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.

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)

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?

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.

Now I'm wondering how many shops have some legacy script with a 'foo.sh' filename and a #!/usr/bin/python shebang

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.

> Much better.

You now have two files to do one thing, and your solution doesn't work (it doesn't pass the arguments from the shell script to the python, or pass the exit code back, and it's making an extra process which can screw up monitoring). You could add the extra code to make it work; but even if you did, you're going to a lot of extra effort to become equal, not better :P

Most of the things you mentioned can be solved in ~15 minutes, surely not a lot of extra effort.

And I'm not sure how a script that calls another script screws up monitoring.

Plus, if someone cares about high level stuff like monitoring but is worried that people's tools might break if he changes script.sh to script.py later on, I think he needs to sort out the lower level stuff first. Like distribution and packaging :)

But why would you want to? As said before, somebody executing a script doesn't need to see what language it's in.

Portability across OSes, especially for non-shell scripts?

Or you could just ... name it 'foo' to begin with?

yeah, that's a good reason. I am convinced.

Not really, I'd rather do: https://news.ycombinator.com/item?id=6688782

Reply on news.ycombinator.com