5 ms·

Why are filename extensions awful? I find it incredibly useful to tell what kind of file something is by just glancing at it. Or do you envision tools like `ls`

• veidr 3y ago
  Yeah, I envision a future 1995 where not only does the GUI icon indicate what type of file it is, but the CLI tools also do (e.g. right before/after the "drwxr-xr-x@" or whatev)
  • paholg 3y ago
    When I type `ls`, I generally want to see file names and types, and nothing else. It would be really unfortunate to need a full `ls -l` to see file types. In fact, I always want to see file types alongside their names, so I really don't mind that the two are together.
    • js2 3y ago
      I think your imagination is failing you. The extension could be stored as a distinct field apart from the name. After all, we don't embed things like the file type (link, device, directory, etc) in the filename, nor things like the owner, group, ACL, access, creation time, etc. Separately, what `ls` displays with or without switches would be independent of how the extension is stored. Say the extension were a distinct field, `ls` could still display that as `{filename}.{extension}` by default. It's an accident of history that the extension is part of the filename.
      • eurleif 3y ago
        >Separately, what `ls` displays with or without switches would be independent of how the extension is stored. Say the extension were a distinct field, `ls` could still display that as `{filename}.{extension}` by default. But that would break piping the output of `ls` to other tools that expect a filename.
        • porridgeraisin 3y ago
          You can have tty output be different from pipe output
          • deleted 3y ago
            [deleted]
        • js2 3y ago
          You shouldn't parse the output of `ls`: https://mywiki.wooledge.org/ParsingLs https://mywiki.wooledge.org/ParsingLs https://www.shellcheck.net/wiki/SC2010 https://www.shellcheck.net/wiki/SC2010 It's brittle and the output is designed for humans, not machine parsing. Use a glob or find. In a world where extensions were their own distinct metadata, whether or not to show them would be a switch to `ls` (whose output you shouldn't be parsing) and how to retrieve that metadata from a filename w/o parsing `ls` output would be something like: ext=$(stat --format="%E" -- "$filename") You'd also have a switch to `find` to select files by extension instead of having to pattern match their names.
          • eurleif 3y ago
            This is a reasonable argument against parsing the output of `ls` within a shell script that you're going to save and reuse in arbitrary directories. It's not a reasonable argument against ever parsing the output of `ls`. If it were, it would also be an argument against humans reading the output of `ls`. The example in your first link makes its point by showing output from `ls` that the human reader can't parse. That doesn't demonstrate that the output of `ls` is "designed for humans, not machine parsing"; it demonstrates that in the general case, its output cannot be parsed by either humans or machines. My rule is that it's ok to use `ls` only in a directory where you know the filenames aren't weird. That rule is the same regardless of whether a human or a computer will be parsing its output. In general, reusable shell scripts shouldn't make assumptions about their environment, so they shouldn't use `ls`; but piping `ls` to another command in a one-off manner at an interactive shell is fine if you know the filenames in the directory aren't weird, just like it would be fine to use `ls` at the same interactive shell and simply read its output yourself.
    • criddell 3y ago
      If they weren't together, you would just define an alias that works exactly how you want it.
  • anonymouskimmer 3y ago
    Instead they went with executables all having unique icons, and icons for non-executable files changing depending on which executable was last granted permission to open them.
• hombre_fatal 3y ago
  That reminds me of relying on static type inference so much that the code is hard to follow in Github and you need to pull it into your IDE just so you can keep track of the types as you read it. While a filename extension could probably be superseded by file metadata, it's also nice when you can read the intention right in the name without additional tooling. Especially when you consider a hypothetical world without filename extensions thus every UI shows the filetype next to the filename thus "readme.md" in our world is just "readme:md" in their world, and it's not obvious what was gained nor lost.
• gsich 3y ago
  They are not. Everything else is insanity.
• rascul 3y ago
  I've learned in code not to rely on arbitrary user generated strings to designate the document type as they can be incorrect or non-existent. They're fine as a possibly unreliable indication to users, though.
• infradig 3y ago
  Exactly, filename extensions are like personal pronouns for files.
• hfuyf65 3y ago
  Not awful, but misleading. You can fake name any file extension anything ala quake approach to data files being archives.