executable extensions

[bloodhound23]

This is kind of a random thought on my mind at the moment, really pointless but I thought I'd ask. Does anybody have any conventions that they are using to name executables in their OS or will be using?
mine:
.fex-Flat executable
.cex-Crutch executable
of course I'll have elf etc.

By the way the Crutch operating system is under way!!!

[Brynet-Inc]

Unix-like operating systems don't typically use file extensions for binaries... configuration files often do, but they're not held back by that weird DOS/Windows 3-letter rule..

[mathematician]

Unix-like operating systems don't typically use file extensions for binaries... configuration files often do, but they're not held back by that weird DOS/Windows 3-letter rule..

No 3 letter rule in Windows; although it is still conventional. You can have pretty much as many letters as you want in an extension. (Who cares what Unix does?)

[piranha]

No 3 letter rule in Windows; although it is still conventional. You can have pretty much as many letters as you want in an extension. (Who cares what Unix does?)

Because (for me) that system is very easy to deal with.

-JL

[Telgin]

I haven't decided on how to handle it in my OS yet. More specifically, I haven't decided if my OS will require file extensions. The file system I've arrived on doesn't, and really the OS model I've arrived at shouldn't. That leaves the command line interpreter to sort out, and I'm still not sure.

I plan on having files as being marked as executable or not in the file system, so ultimately it shouldn't be necessary. Since I used Windows pretty much exclusively up until a half a year ago (and was introduced by force to Linux by my university's computer science department), I'll probably end up using the convention anyway. No limit on the length of the extension, and there probably won't be any sort of file type association anyway.

I'm lazy in this respect and since I don't need to support complicated scenarios like PE and ELF executables in the same OS, I'll probably just use Windows standard convention.

.bin or .exe for executable files (haven't decided)
.sys for system files (what exactly are these anyway, OS-use DLLs?)
.dll / .lib for dynamically / statically linked libraries

Then again, I might do something a little more extravagant, but I don't know.

[piranha]

How about:
.run or .prog for executables.

And you enter it into the command prompt without or with the extension, and it finds it.

-JL

[xyzzy]

No 3 letter rule in Windows; although it is still conventional. You can have pretty much as many letters as you want in an extension. (Who cares what Unix does?)

For executables, there needs to be .exe, otherwise explorer/cmd won't execute it. Although the lower level of the system probably doesn't actually care.

Anyway, my OS does what UNIX does, no extensions on binaries.

[AJ]

Hi,

I don't plan to support flat binaries, so don't need a file extension from that point of view. Generally, I would like to forget about file extensions for most structured file types (although this does mean scanning the file for format before choosing the appropriate action for a particular file type).

Cheers,
Adam

[ucosty]

You could store the file type in an attribute like Mac OS pre X

[Solar]

I wouldn't use extensions for executables, because it poses a dilemma.

You execute not only executables, you execute scripts, too.

Naming your scripts "*.exe" is wrong, because a script can be edited, an executable cannot.

Naming your scripts "*.script" or something is pretty arbitrary, and doesn't add much usefull information.

Naming your scripts with a "language wart" ("*.py" or "*.pl" or "*.sh" or "*.rexx" or whatever) isn't very helpful either, because why should you have to remember what language your script "prime" is written in, just to be able to call it?

I think Unix got it right there - something executable either starts with "ELF" (binary .exe), or with "#!{interpreter}", which tells the shell (and the editing programmer) what language it is in, without bothering the end user.

Unfortunately, not only is the {interpreter} part not constant across Unix flavors (e.g. /bin/bash vs. /usr/bin/bash), no, all-too-many scripts still carry around "language warts", which effectively defeats the purpose.

[Wave]

While I'm not sure about whether to have extensions or not, I can say for sure that Solar's argumentation isn't right.

You execute not only executables, you execute scripts, too.

In the Unix world, you do. In the Windows world, you don't. You execute an executable which then executes the script.

Naming your scripts "*.exe" is wrong, because a script can be edited, an executable cannot.

Naming your scripts "*.script" or something is pretty arbitrary, and doesn't add much usefull information.

I agree with that.

Naming your scripts with a "language wart" ("*.py" or "*.pl" or "*.sh" or "*.rexx" or whatever) isn't very helpful either, because why should you have to remember what language your script "prime" is written in, just to be able to call it?

On Windows, there is a list of "auto-extensions" (by default it includes exe and bat). When you want to run hello.bat you just type hello. That could be used for any number of language extensions. To call print.rexx you just type print. The shell then finds print.rexx, then it finds the rexx interpreter (associated with .rexx files) and runs it.

[inflater]

Binaries for PortixOS had extension firstly .PXE, and then .PES (Preliminary Executable System), but I think the name "Primitive Executable Support" would be more better...
"pes" stands in Slovak for "dog".

[Solar]

While I'm not sure about whether to have extensions or not, I can say for sure that Solar's argumentation isn't right.

You execute not only executables, you execute scripts, too.

In the Unix world, you do. In the Windows world, you don't. You execute an executable which then executes the script.

Effectively you do this on Unix, too. ("./myScript.pl" and "perl ./myScript.pl" are effectively identical.)

Naming your scripts with a "language wart" ("*.py" or "*.pl" or "*.sh" or "*.rexx" or whatever) isn't very helpful either, because why should you have to remember what language your script "prime" is written in, just to be able to call it?

On Windows, there is a list of "auto-extensions" (by default it includes exe and bat). When you want to run hello.bat you just type hello.[/quote]

Which allows the end user to ignore the language wart while he types, but still adds information to "user space" that a user (at best) doesn't care about and (at worst) gets confused about.

On the other hand I freely admit that a language wart would allow for speedy ordering of scripts by implementation language. Hm. It's not such a clear-cut decision after all.

To call print.rexx you just type print. The shell then finds print.rexx, then it finds the rexx interpreter (associated with .rexx files) and runs it.

...and gets confused if there is a print.pl and a print.py as well... nah, I'm still opposed to language warts.

[01000101]

I like file extensions and associations. It gives a clear definition (at first glance) of what the file is... also with the association, icons are another great way to make certain files stand out or show their association.

The 3-char extension is just common practice, and not a rule. Although, have a +3 char extension can just look really messy. Most abbreviations are < ~3, so it seems natural to use that.

[JamesM]

R.e. "language warts" - I use them for all scripts which are not meant to be run from the shell. For example, script A is run from the shell and calls script B - script A would have the executable flag set, and no extensions, and script B wouldn't be executable, and have a language extension.

I also use them for use with old versions of crappy version control systems which don't handle chmod's very well (*cough* CVS *cough*) - it gives me a hint as to how to run the script!