*. Really.

My first taste of Unix was a somewhat austere version of HP-UX, with basically no application beyond those shipped with the system (except for Netscape Navigator 2.0). It was my second year at university, and for the first time I had permanent access to Unix workstations. We had a brief course on "survival Unix skills" (ls, cd, cp, reading mail - with elm), and learning the rest was left as an exercise to us poor little students.

There were two text editors on these workstation. The first one was vi, but our well-intentioned teachers strongly advised us not to use this program, something along the line of "You innocent newbie, you no use vi ! bad bad bad bad !" (I can't blame them for that, some of the students had dificulties with Word).

So the only text editor we had was textedit, which was basically a clone of notepad - only uglier. We edited all our text with it, mail, C code, whatever.

Now that program had a peculiar "feature": in the "Save As" dialog box, the default name was "*". That is, if for some reason you clicked on "OK" or pressed "Enter" before specifying the filename, it was saved as "*". Someday, after writing something (I don't remember what) with that editor, I decided to save it and clicked on "Save As", but then I changed my mind and tried to "Cancel" out the dialog box. Being a mere mortal, and as such subject to failure and to Murphy's law, I clicked on the wrong button and the file was saved under the name "*".

Disk space was severely restricted (1 MB for each 1st year student), so I decided to delete this file to save some room. "How do I delete a file already ? Ah, yeah, 'rm'. Okay, here we go.."

      $ rm *
I suppose you can figure out how I felt when I realized the consequences ("what, there's no 'undelete' on that things ?")

My conclusion: Never use * as a filename, but more than this, never, ever use a program that is brain-damaged enough to save files as "*" by default. Oh, and if you can, don't use HP-UX at all. That's my conclusion.
Actually filenaming conventions are the topic of much debate in many circles. Anyone who has worked on a project with fellow programmers, sysadmins, etc... knows this problem well. Anyone who has ever taken a position in a company that's been around for any length of time is usually even more familiar with the problem. Given that Unices today support long filenames vie with that the user slant for wanting to type as little as possible and you run into some interesting combinations. For example I work for a telecommunications company that has been through many generations of sysadmins, many of who know perl. These files have been called:
(I know, I thought it was a shell script too)

One can see the confusion that this would cause when you (for example) upgrade perl/a perl module and want to make sure nothing is going to break (although perl is pretty good about backwards compatibility).

Unices allow a lot of freedom in filenaming and for the most part this is a good thing. It is important, however, to apply a bit of common sense to your filenames The DOS legacy of many of todays administrators places that trend toward the name.type format, and I think it works rather well.
perl files = name.pl
text files = name.txt
C shell files = name.csh
Korn shell files = name.ksh
you get the idea.

Please never name a file "core" or "junk", or I will have no pity when you find your files deleted, restore will not be an option.
Naming files with the type in the extension is good (or at least tolerable until better ways are supported), however executables (and that includes perl scripts, shell scripts, and even sed scripts) should have no file name extension. Well, all executables should have the same extension, and having it be nothing (and dropping the . too) is customary and will save you a lot of typing in the long run.

Why, you ask? Say you've written a simple bourne shell script that somehow conjures up a magic value. You've called it /usr/local/bin/magicmaker.sh, and all is well with the world. People like your magic values, and your script's popularity skyrockets. People are using it from their interactive shells, but also from other scripts, CGIs, crontabs, etc. In fact, the script is so popular it's bogging the system down, due to being wildly inefficient. So, you decide to rewrite what was once a dirty hack, but bourne shell is just too primitive for what you want, so you use perl. An hours work later, you've halved execution time and quartered memory usage, and you're happy with your work. But what are you going to save it as? /usr/local/bin/magicmaker.sh? A perl script ending in .sh? That's silly. /usr/local/bin/magicmaker.pl? But everyone's scripts, crontabs and habits will have to be changed.

Since the interface of the program doesn't change when you change the language it's written in, and that's what matters for those accessing it, the extension for all executables should be the same.

This of course fails to address people whose scripts read your scripts to extract data.

Log in or register to write something here or to contact authors.