Program executables..

I grew up on Commodore PET and MS Basic. When I write a program on FreeBSD I prefer to use an extension on my executable. Call me brainwashed but example.com and example.exe were self evident.
My point is many Unix programs use no extension for the executable. Why? Scripts seem to be well labeled with .sh but executables are unlabeled. Of course this is by choice as I use the .app extension personally. I choke up when I see Unix using .ini for configs(php.ini).

Where it really comes to play is looking at a directory with ls and you can't tell the difference between a directory and executable if named the same. With expanded ls-flags you can tell but my point is why not use extensions? Especially with command prompt history feature.
 
I grew up on Commodore PET and MS Basic. When I write a program on FreeBSD I prefer to use an extension on my executable. Call me brainwashed but example.com and example.exe were self evident.
My point is many Unix programs use no extension for the executable. Why? Scripts seem to be well labeled with .sh but executables are unlabeled. Of course this is by choice as I use the .app extension personally. I choke up when I see Unix using .ini for configs(php.ini).

Where it really comes to play is looking at a directory with ls and you can't tell the difference between a directory and executable if named the same. With expanded ls-flags you can tell but my point is why not use extensions? Especially with command prompt history feature.

The file permissions give a hint as to which files are executables, and that info is often picked up for display. But, I get your point. I think the most eloquent solution to this actually does not use extensions, but depends on file system meta-data. The RISC/OS (ADFS) file system does this best (it really depends on it), and the BeFS (Haiku, BeOS) file system has it built in, and I'm pretty sure the apple file systems can do it (but it's not automatic for either). Windows and nix*/nux* can do it only with pain (extended attributes are sorta tacked-on IIRC).

Permissions are meta data, but very primitive form. A full blown meta-data file system would identify all sorts of files and attributes (not just executables).
 
My point is many Unix programs use no extension for the executable. Why?
That whole three letter extension business is a MS-DOS relic. Unix (and several other operating systems) has never relied on it.

Scripts seem to be well labeled with .sh but executables are unlabeled.
That's more a convention than a requirement. There's no technical reason why those shell scripts have .sh. They'll work just as fine without it.

Where it really comes to play is looking at a directory with ls and you can't tell the difference between a directory and executable if named the same.
That's actually not possible.
Code:
dice@maelcum:~/test %
dice@maelcum:~/test % ls -al
total 2
drwxr-xr-x  2 dice  dice   2 Jan 22 17:54 .
drwxr-xr-x  6 dice  dice  22 Jan 21 21:43 ..
dice@maelcum:~/test % touch a
dice@maelcum:~/test % ls -al
total 3
drwxr-xr-x  2 dice  dice   3 Jan 22 17:54 .
drwxr-xr-x  6 dice  dice  22 Jan 21 21:43 ..
-rw-r--r--  1 dice  dice   0 Jan 22 17:54 a
dice@maelcum:~/test % mkdir a
mkdir: a: File exists

You can more easily tell the difference between files, directories, pipes, symlinks etc. if you add the -F option to ls:
Code:
dice@maelcum:~/test % ls -l
total 1
-rw-r--r--  1 dice  dice  0 Jan 22 17:54 a
drwxr-xr-x  2 dice  dice  2 Jan 22 17:56 b
dice@maelcum:~/test % ls -lF
total 1
-rw-r--r--  1 dice  dice  0 Jan 22 17:54 a
drwxr-xr-x  2 dice  dice  2 Jan 22 17:56 b/

Code:
     -F      Display a slash (`/') immediately after each pathname that is a
             directory, an asterisk (`*') after each that is executable, an at
             sign (`@') after each symbolic link, an equals sign (`=') after
             each socket, a percent sign (`%') after each whiteout, and a
             vertical bar (`|') after each that is a FIFO.
From ls(1)
 
Traditions. <- Cue to Zero Mostel here, singing the opening number of "A Fiddler on the Roof"

On Unix, the tradition is that executables don't need an extension. Note that you can't tell from the name of an executable what language it is written in. For fun, go to /usr/bin, and run the file command to find out what type of files the various executables are. You will find several dozen executables that are shell scripts, and their names do not end in ".sh". Now repeat that exercise in /usr/local/bin, and depending on what stuff you have installed, you'll find a variety of languages, including things in various scripting languages (on my system there is lots of Python, some Perl, and a few weird ones).

This also works for compiling source code. The tradition is that foo.c gets compiled to foo.o, and then linked into foo.

The really important part of the tradition is this: Unix does not care about extension. The fact that humans often (but not always) put a "." in the middle of a file name, and a traditional word behind it, does not matter to the operating system itself. There is nothing that prevents you from creating an executable that's called foo.c or foo.o. There is also nothing that prevents you from putting your Fortran source code into a file named foo or even foo.c; you'll have to write some gnarly makefile rules to get it to compile, but it will work. The "." in the file name is not special to the OS itself, it is just used as a convention.

There are other operating systems that have different traditions. Sir Dice pointed out MS-DOS. It inherited that tradition from cp/m, where file names had to have the 8.3 format, and a file without extension would have to be called foo. with a trailing dot. cp/m in turn inherited that tradition from various Digital Equipment operating systems (RSX-11, VMS, TOPS-xx and so on), where extensions were also used. I remember that under VMS, scripts used the ".com" extension, and compiled executables the ".exe" extension, and there was some mechanism to install executables as "aliases" in your shell, so to run them you could just say "foo" instead of having to type "foo.exe".

Here would be my recommendation: When in Rome, do like the Romans. When using FreeBSD, stick to the Unix traditions, and don't use ".sh" on your shell scripts (nor ".py" on your python scripts if they are intended to be executed from the command line, and so on). Learn to be comfortable. But when using other operating systems (I recommend that you install OpenVMS on an emulator for fun), stick to their traditions.

At this point, go listen to Zero Mostel sing "If I were a rich man". He's really good.
 
I like using ls -lhG. The -G option shows binaries in red, nonexecutable in green, directories in blue, on my machine. Links show up as faint purple, but its not so easy to notice with my monitor and eyes.

From:
ls(1)

We find:
" -G Enable colorized output. This option is equivalent to defining
CLICOLOR in the environment. (See below.) This functionality
can be compiled out by removing the definition of COLORLS. This
option is not defined in IEEE Std 1003.1-2001 (``POSIX.1'')."
 
This also works for compiling source code. The tradition is that foo.c gets compiled to foo.o, and then linked into foo.
Isn't the tradition that by default, without including a target filename option, the linked output is named a.out?
At least this is still the case, as when I do a mere cc myprog.c, I get an executable a.out.
I remember that under VMS, scripts used the ".com" extension, and compiled executables the ".exe" extension, and there was some mechanism to install executables as "aliases" in your shell, so to run them you could just say "foo" instead of having to type "foo.exe".
That's interesting... didn't know that.
Just a bit more info on MSDOS history: .com files were just binary images that could be used directly, with the start address of the program being at 0x100, same as in CP/M. This was possible because they were limited to 64kB, thus didn't require actual code segment handling. This eased direct conversion from 8-bit programs to "16-bit programs" without recompiling.

Due to the .com files' limitation to 64kB code size, there were the .exe programs. These included a translation table that DOS had to "link", replace the segment placeholders with the actual location at runtime, before they could be run. There was an exe2bin program included with many old DOS versions which served to produce a directly executable image .com file (which was possible only if the code size didn't exceed 64kB, and the code used only one code segment), so that loaders that did what we know from the exec...() system call, could load .com programs without calling the DOS internals to translate a such table.

And regarding the original question: I am really glad that it's the way it is on Unices. Imagine we'd have to deal with .elf, elf2, coff, and hundreds of other "extensions"...
 
I rely on the coloring provided by the ls command, though I have the whole thing aliased simply to dir. It works well for me since it saves the trouble of inspecting the long output to look at attributes. Dots and underscores in files name are still handy to classify them so I still use that as well, though not in an extension kind of way.
 
Isn't the tradition that by default, without including a target filename option, the linked output is named a.out?
True, that's the default of the compiler/linker. Although in practice, that convention is not very useful: If you have a directory full of sources like foo.c and bar.c, then compiling both of them to a.out won't work, they'll step on each other. The default of make is to compile foo.c to foo and so on.

And, as CraigHB says, people do use extensions too. Here are two examples of conventions from projects I've worked on: One project had hundreds of shell scripts. There, the "source code" of the shell scripts were files names foo.sh. To install them (in /usr/local/bin/...), the need to be run through preprocessors, so the corresponding executable would be foo. Another project relies on a set of python programs with extensive libraries. The source code is all called ".py", for example foo.py, lib1.py, lib2.py and so on. File foo.py is already executable in the source directory, and you need to do to "install" it is copy it into /usr/local/bin/foo. If a developer wants to test a private copy of the "foo" program, they can just go into the source directory and say ./foo.py. Because it has a different "name" than the installed copy, there is less chance of confusion. On the other hand, the libraries are not marked as executable; they get installed by a make file copying them into the correct subdirectory of /usr/local/lib.... But each library file contains its own test harness, and to run the unit tests, all you need to do is to go into the source directory, and say python lib1.py.
 
The same reason devices do not have an extension. Everything is a file.

But I hate that [I]directory[/I][B].d[/B] convetion, what up with that?
 
Even a modern Windows doesn't care about extensions. Although it still respects them for backwards compatibility, there's no actual need for them any more.

In case you're wondering how Unix figures out what to do: https://en.wikipedia.org/wiki/Magic_number_(programming)

And in case you want to make dot files in Windows, add a dot at the end as well. A lot of open source software makes config dirs in the user profile directory, as well. You could totally have a *NIX compatible hierarchy there now.

Also, the only thing that makes certain extensions executable is the $PATHEXT, somewhat like that on *NIX you have to prefix the executable with at least one slash, unless it's in the path. Still, $PATHEXT is actually now just a wrapper for registry associations, which differentiate extensions, mime types, ttype identifiers and associated parsers. I guess they kept those relics so as to differentiate between several executable formats. Which is a topic on its' own.

But all of this is basically the same thing - the confusion comes from the default icons, which had to be very well designed for an average noob.
 
I rely on the coloring provided by the ls command, though I have the whole thing aliased simply to dir

Yes a lot of this has also to do with easy recognition. I have visual difficulty with doing that at speed so also like some coloration and alias my ls preferences accordingly. What I also find is handy in long directory listings is another alias showing directories separately. For this I use alias dir "ls -l | sort". You may like it.
 
It's interesting I actually prefer the Unix sort where files starting with a dot are first, caps next, and then lowercase with no priority over directories. At one point I tried using the ol' Windows sort with directories first and no regard for upper case. I ended going back to the Unix way.
 
But I hate that [I]directory[/I][B].d[/B] convetion, what up with that?

'not sure what you mean; isn't that how everybody does it?
Code:
p300:~/a.d% ls
helloWorld.c.f  loveletters.f   taxes.f
I'm kidding of course. I hadn't paused to appreciate the insanity of that .d convention before. 'wonder where that came from, also.
 
What I also find is handy in long directory listings is another alias showing directories separately.
For this I use alias dir "ls -l | sort".
That's good, but you loose color output. IMO the colorized output is more important.
 
Why not use extensions... Well, if you want to you're fully free to do so. I think that's the beauty of the whole OS: you get to have a say in how you want your server to be run without getting forced into some predetermined scheme you might not like. But it's partly for this reason why I set up an alias for ls and expanded that into ls -F, this will always prevent further confusion on the commandline.
 
Sure, extensions are just a handy way to organize files. One could just as easily use a dash as one could use a period for that matter - or a string of caps even. I do that sometimes. Interesting though, I've always used text files a lot, with DOS and *nix both. My preference is to not use any extension such as .txt. However, some operating systems, such as earlier (perhaps recent too) MS-Windows, refuse to read them because of that.
 
Back
Top