Mini-Rant: Executables with filename extensions

[marcmagus]

I just want to mention, for the record, that I hate filename extensions on anything with the executable bit set. Yes, I'm looking at you, authors of Perl and Python scripts.

When I'm at the command-line and want to run a command (say, "todo"), I want to type "todo" and have it work. I don't want to have to type "todo.pl", nor do I want to have to type "todo<TAB>" to get my shell to do it for me. I shouldn't have to know, or care, or even be reminded of what scripting language the script I'm invoking was written in. Isn't the entire point of the "she-bang" magic line available in all modern shells that you can run a script without having to know what kind of script it is?

Can anybody give me a single good reason we keep tacking all this ugly garbage onto the end of our scripts? It's not like editors can't use that same first line to figure out what kind of script it is and turn on appropriate syntax features. (I'm sorry, it's 2008. If your editor can't handle that, what's wrong with your editor?)

So why is my world filled with "todo.pl" and "moap.py" and "generate.sh" (in all probability requiring bash, no less)? Will you all just cut it out? I'm sick of having to symlink and alias around your annoying naming conventions.

Comments

[thorog.livejournal.com]

I'd say it's because with any interpreted language you're combining two roles - the source code and the program.

To the person running the program, no, you don't care what sort of file it is. To the machine running the program, it doesn't care what the extension is as long as it has the first line set out properly. But to the coder, it's really useful to know what format it is.

"Ah, but you should know what language you're coding in anyway! It's not like you're using three languages in the same project."

Well, no. But I might have several types of file still. I might have some ruby files, some yaml config files, some plaintext reference files, maybe some pictures. Suddenly having .rb or .py or .sh on the end of my file is useful, because I can see which are code files.

Yeah, I know, all these files should be segregated by folder anyway. Sometimes you can't do that.

Anyway, it's OK with compiled languages. I can have all my files named .c and .h, and when I compile it I get something that's extensionless. That's because the source and the program are separated. No such luck with interpreted stuff.

And some people take your opinion. I've seen plenty of ruby setup packages where the main file is just configure or setup. And I've renamed my own stuff to remove the .rb or whatever once I'm using it from the command line.

[marcmagus]

Yes, you're right. I just think they're wrong. ;)

a) If it doesn't have an extension, it's almost certainly source code. All those other types of files have extensions because it's actually useful to know what the file type is when you're looking at it sitting in the directory listing.

b) You might be working in a mixed environment. I've worked on a project which actually does use three different scripting languages for three different tiers of logic. Never mind the ugliness. They're separated by directory. But even if they weren't: your editor should be able to tell you what language you're in, and you can always hop to the top of the file and check if you actually get confused. Seriously. And if you're not editing the file, you don't need to know what type it is.

c) Ok, I suppose I'm actually vaguely convinced that it might be occasionally sufficiently useful to know the language that it's worth tagging the source with it. But by all that's holy, there's no excuse to be shipping it like that.

[thorog.livejournal.com]

a) Yup, a point I didn't bring up because it weakened my argument :P. However I feel there's a certain ingrained feeling among geeks that no extension -> binary file. Not necessarily true - c.f. makefiles, readmes.

b) The thing being there that you're suggesting what is essentially a two-step process - open the file, check the header - vs. a one-step - check the file extension. And geeks are lazy.

c) Yeah, the problem (I think) goes right back to compiled/interpreted. Most stuff I stick in ~/bin I remove the extension from (for exactly the reasons you find - I really hate reaching for the . key when I'm typing a filename), about the same time I chmod a+x. But there still isn't that nice clear-cut boundary between coding and using.

[marcmagus]

I'm not granting your b. I'm suggesting a two-step process in the situation where I'm opening the file whose name I remember but whose filetype I'm not sure of. But I can turn the cost you imply around on the current solution: with extensions I need to remember the extension in order to open the file (for editing or to execute), or at the very least need to use some sort of programmatic filename completion to do it for me. And you assume that people actually look at the extension (or even the filename) when they're opening a file in these sorts of situations, which I don't grant. (When source browsing and you jump across files to the file containing the definition of a called function, you don't need to know the name of the file you're opening in order to open it.)