For a very long time I thought that .txt or .exe extensions are Windows world heresy and have no real use in GNU/Linux or Unix-like world. But then relativelly recently, I know it's stupid - but I realized that it does provide some value, for example if you want to move all text files from a mixed file directory, you'd just "mv *.txt", while without an extension it would take more actions, piping from file or something like that - more typing, more complexity. What do you think? Do you create all your text files with .txt?
Another one are shell scripts. Most of us are probably using .sh in the name, but you know that in GNU/Linux /bin/sh is a symlink to /bin/bash in 99% of distros. So we are not using Bourne shell, or something strictly POSIX compliant, we are using BASH, I thought, why not using .bash for bash scripts, and .sh for posix compliant ones. What do you think? Am I missing something which would make it dumb, or incompatable somewhere? It should be even better for Unix/Linux cross usage. Why isn't it a standard?
Most interesting are binaries, .exe or .exec could also be useful in some ways, but I don't think that renaming all your system binaries would be very smart idea :)
So names and extensions can provide valuable info, or ease of use, on top of what we already have in form of extensions. Your thoughts?

That's a fascinating topic, thanks for bringing it up.
I often use file extensions as visual helpers or when scripting to filter files by extension.

They are definitely useful for recognition by other programs, such as text editors for instance.
More than this, I wrote about default programs (and here) and the extension is definitely used to discover the mime type of the file, and thus the default program to use to open them.

It doesn't end there even, on Linux you can use the binfmt functionality with the E type format to say that the executable is chosen based on the filename extension. So you can, in theory, recreate the Windows behavior on Linux. If I recall properly, that's how WSL (Windows Subsystem for Linux) implements being able to call .exe like explorer.exe.

(12-11-2020, 02:57 PM)stratex Wrote: you know that in GNU/Linux /bin/sh is a symlink to /bin/bash in 99% of distros.

Name your source. I doubt that.

(12-11-2020, 02:57 PM)stratex Wrote: I thought, why not using .bash for bash scripts, and .sh for posix compliant ones.

That’s why the shebang exists. If /bin/sh points to a not-quite-POSIX shell, the system has a broken configuration in my opinion. Not something to be fixed in the userland.

My (non-code) text files are usually named according to their format - .org, .md, .txt are the extensions I use most. One of the reasons is that I also use Windows. :)

(12-11-2020, 03:48 PM)jkl Wrote: Name your source. I doubt that.

at least true on Arch.

Which are not 99% of distros.

(12-11-2020, 03:48 PM)jkl Wrote: Name your source. I doubt that.

It would actually be interesting to do a check on at least the top 10 Linux distro on distrowatch and see what is the default shell. That would definitely cover at least the most used distros.

(12-11-2020, 03:48 PM)jkl Wrote: My (non-code) text files are usually named according to their format - .org, .md, .txt are the extensions I use most. One of the reasons is that I also use Windows. :)

Always up to little snarky comments, but do you care to be more descriptive in your analyzes of why you find that adding the extension explicitly is more useful. I guess that you're referring to the visual aspect, towards the end-user.

Here's an additional thread: https://askubuntu.com/questions/803434/d...ing-system

One thing that wasn't brought are files which would be interpreted as another type if only based on the magic bytes/file signature, files like .doc for example would be interpreted as zip files.

The problem is that the Unix filesystem doesn't embed file-types (or miscellaneous file attributes), creating the need for stuff like magic bytes or file extentions. I'd imagine it would be better if you could extend a glob with something like "*:type=exec" or "summer_1025*:type=image/*".

Indeed, the UNIX way file naming is extension-less short names, relying on magic numbers, file content, shebangs, file permissions and the path (files in /usr/man/* are probably man pages) to guess the file type. But when those meta-information are not available, like when moving files between systems or downloading them, file extensions come in handy.

I keep my documents and plain text files extensionless. And when I need to move files around, most of the times I do this visually and interactively rather than statically via shell globing (I use a script I made that opens vim with all files listed, each one in a line, and then I do renaming or moving via the editor). But probably I will give this idea up when I need to write some script. Adding a .txt file doesn't hurt and is way better than using file(1) or find(1) to select files by type.

(12-11-2020, 04:36 PM)zge Wrote: The problem is that the Unix filesystem doesn't embed file-types (or miscellaneous file attributes), creating the need for stuff like magic bytes or file extentions. I'd imagine it would be better if you could extend a glob with something like "*:type=exec" or "summer_1025*:type=image/*".

Haiku solves this problem by adding metadata to their database-based filesystem, file types are just a "column" for the file in the database. I don't know how this can be used on the command line, like globing. A database/metadata-based filesystem would be nice and solve problems like those as well.

(12-11-2020, 03:48 PM)jkl Wrote: That’s why the shebang exists.

It is not the same thing. You perhaps didn't get what I ment. You can't quickly look at ls and see shebangs of all your .sh files. It's user conviniance thing, not system configuration thing.

(12-11-2020, 03:48 PM)jkl Wrote: Name your source. I doubt that.

It was said figuratively.

(12-11-2020, 04:24 PM)venam Wrote: do you care to be more descriptive in your analyzes of why you find that adding the extension explicitly is more useful.

1. Certain online code hosting services only look at the file extension to determine how to format a README - including mine.
2. GNU Emacs primarily looks at the file extension to determine which major mode to load. Probably also true for other text editors.

Assuming that we can agree that multimedia file extensions have additional benefits.

Some software expects file extensions ((la)tex for example, expects .tex and writes a bunch of files with .aux, .bbl, .log etc). sane writes file extensions when scanning etc, etc. I guess I could jump through some hoops to remove them but frankly, I'm too lazy for that and just follow along. Also, most programs looking for a config file look for a file with a prescribed location/name.

When I write scripts, I don't add any extension because that would mean more typing when I want to invoke it. So, no .sh for me.

Otherwise, I don't really think about it much but I find that in general I don't use an extension when it's not necessary. So usually, no .txt but .odt, doc(x) because of software requirements. Totally inconsistent but the path of least resistance.

(12-11-2020, 02:57 PM)stratex Wrote: So we are not using Bourne shell, or something strictly POSIX compliant, we are using BASH, I thought, why not using .bash for bash scripts, and .sh for posix compliant ones.

Executables are the one place where I usually don’t use a file name extension. It happens surprisingly often that I re-implement a script in another scripting language or in C. When that happens, I don’t want to update all other programs/scripts to now use `make-html-index.py` instead of `make-html-index.sh` and then 3 months later just `make-html-index`, because I finally went for C (or Go or Rust or …).

All other files usually get an extension – if I intend to keep them around. I want a simple `ls` to indicate which kind of file it probably is. Then of course there is stuff like `README`, where I don’t use an extension. Now that I think about it, it’s much more inconsistent than I was aware of.

(12-11-2020, 03:48 PM)jkl Wrote:

(12-11-2020, 02:57 PM)stratex Wrote: you know that in GNU/Linux /bin/sh is a symlink to /bin/bash in 99% of distros.

Name your source. I doubt that.

In debian and all of it's derivatives, except for ubuntu 18 and up, Redhat and all of it's derivatives, and Arch and all of it's derivatives /bin/sh is a symlink to /bin/bash. If it's not 99% it's because there aren't enough linux distros.

(12-11-2020, 02:57 PM)stratex Wrote: I thought, why not using .bash for bash scripts, and .sh for posix compliant ones.

(12-11-2020, 03:48 PM)jkl Wrote: That’s why the shebang exists. If /bin/sh points to a not-quite-POSIX shell, the system has a broken configuration in my opinion. Not something to be fixed in the userland.

even though /bin/sh is a symlink to /bin/bash, that doesn't mean that it behaves the same as /bin/bash, from the manpage https://linux.die.net/man/1/bash :

If bash is invoked with the name sh, it tries to mimic the startup behavior of historical versions of sh as closely as possible, while conforming to the POSIX standard as well.

Please excuse my formatting, it's my first time replying to a thread like this.

(13-11-2020, 09:03 PM)mattrose Wrote: In debian and all of it's derivatives, except for ubuntu 18 and up, Redhat and all of it's derivatives, and Arch and all of it's derivatives /bin/sh is a symlink to /bin/bash. If it's not 99% it's because there aren't enough linux distros.

I'm too lazy to look it up now but last time I used Debian they were replacing bash with dash.
EDIT: ok, so I am more curious than lazy. Debian uses dash as non-interactive shell and bash as interactive shell.

(13-11-2020, 09:03 PM)mattrose Wrote: even though /bin/sh is a symlink to /bin/bash, that doesn't mean that it behaves the same as /bin/bash, from the manpage https://linux.die.net/man/1/bash :

Thanks, I didn't know that.

(13-11-2020, 09:03 PM)mattrose Wrote: Please excuse my formatting, it's my first time replying to a thread like this.

Perfectly fine!

(14-11-2020, 12:01 AM)Dworin Wrote: EDIT: ok, so I am more curious than lazy. Debian uses dash as non-interactive shell and bash as interactive shell.

Goodness, is debian getting in on that silliness as well? Ubuntu originally developed dash because they felt that it was too slow and was critical path for speeding up ubuntu's boot time. Then they went to systemd, which doesn't rely on it at all, so why are they still using it??

(14-11-2020, 01:07 AM)mattrose Wrote: Goodness, is debian getting in on that silliness as well? Ubuntu originally developed dash because they felt that it was too slow and was critical path for speeding up ubuntu's boot time. Then they went to systemd, which doesn't rely on it at all, so why are they still using it??

"dash" means "Debian Almquist SHell". It wasn't made by canonical, it's initially a port of NetBSD ash for Debian. It was adopted by Ubuntu first as /bin/sh. I think it is still the case today. As for Debian, they adopted it with thdir Squeeze release.

Regarding extension, I'm on vain's boat. No extension for executables (especially shell scripts). Everything gets an extention so I have a meaningful view of what is what using "ls". Files whose name have a special meaning (README, Makefile, ...) don't get an extension. As a rule of thumb, I put an extension when the output of "ls -l" doesn't tell me the kind of file it is.

Using extensions is indeed pretty useful for bulk scripting, as you don't need special use case when you have, eg. pictures and videos in a folder, and want to resize all pictures.

(13-11-2020, 05:02 PM)vain Wrote: Executables are the one place where I usually don’t use a file name extension. It happens surprisingly often that I re-implement a script in another scripting language or in C. When that happens, I don’t want to update all other programs/scripts to now use `make-html-index.py` instead of `make-html-index.sh` and then 3 months later just `make-html-index`, because I finally went for C (or Go or Rust or …).

That's really something I never thought about. I often find myself in the same boat, re-implementing a script from one language to another and I have to change the extension. I like the idea, I'll use it from now on.
So no more extensions for executables.

No extensions on scripts or "special" files for me as well. A good example of taking advantage of extensions is
which I have to use regulary to make a pdf report out of scanned images for school.