11

Why do developers choose to not use file extensions for certain files? Here is an example from MediaWiki -

enter image description here

This appears with intention, e.g 'CREDITS' and 'COPYING' is with legal intent, perhaps. Why do they do this? In what cases should I do this?

  • 15
  • 12
    In addition to general answers, it's worth noting that in this specific case the names are traditional. Many software distributions have a number of plain-text files in their root directory like these, each in ALLCAPS and named things like HISTORY, COPYING, README, &c.. Traditionally ls would sort files in ASCII (rather than alphabetical order), so these names would jump to the top of the content listings. The tradition stuck, and even today you find a lot of source packages on e.g. GitHub containing a README.markdown file in the root directory. – Williham Totland Nov 12 at 6:50
  • 10
    I fail to see how this is an Ubuntu question... – Thomas Ward Nov 12 at 14:39
  • 3
    Hi @ThomasWard I agree I have placed this question in the wrong forum, I am a hardware engineer and we try our best. I find the response and content here very useful, can we move this to a better location? – J-Dizzle Nov 13 at 16:08
  • 3
    @J-Dizzle This question is being discussed on meta, and migrating it to another Stack Exchange site is one of the possibilities under consideration. (You should feel free to participate in that discussion if you like.) – Eliah Kagan Nov 14 at 2:05
35

There's no established mandate in the Linux world that there must be extensions. Filesystems for UNIX-like operating systems do not separate the extension metadata from the rest of the file name. The dot character is just another character in the main filename. Instead, internal file metadata is popularly encoded within the beginning of the file to show what kind of app opens it.

If a file has no extension, and it is not executable, it's likely plaintext, especially if all uppercase.

  • 1
    not the case with the MediaWiki example here (e.g. 'README', etc.), 'HISTORY' is even 19,000 lines long! – J-Dizzle Nov 11 at 21:37
  • 2
    @J-Dizzle Please allow me to rephrase; no extension, probably plaintext. You may need a more muscular text editor to open it, but it's plaintext. – K7AAY Nov 11 at 21:39
  • 14
    I'd say, "no extension, no executable permissions, probably plaintext." Many binary files, like /bin/ls and /usr/bin/file, have no special suffix. A file that has no extension and is not marked executable is probably a text file. A file that has no extension and is marked executable may be either text (e.g., /usr/bin/tzselect, /usr/bin/startx) or binary. @J-Dizzle – Eliah Kagan Nov 11 at 21:58
  • 1
    But then e.g. gcc (the compiler) uses the file extension to determine the language of the source code (.c for C, .cc or whatever for C++, etc.). Apache (the HTTP server) often determines the MIME types of files from the file extension. Some editors use the file extension to again guess the language for syntax highlighting and such (though Emacs can read hints for that from the file (or was it vim?)). So it's not always that (only) the internal metadata is used. – ilkkachu Nov 12 at 12:28
  • 2
    @ilkkachu That's very true. As I said in my answer to the linked question, I think people are far too ready to generalise to "Linux does this, Windows does the other", when actually it's all just conventions and the behaviour of individual programs. – IMSoP Nov 13 at 14:52
4

As K7AAY says, there is no strong connection between the filename and the filetype, although I disagree that files with no extension is likely to be plain text. The way to find out with some degree of certainty is to use the file command:

$ file *
...
libperconaserverclient18-dev_5.5.44-rel37.3-1.jessie_amd64.deb: Debian binary package (format 2.0)
Percona-Server-5.5.44-37.3-r729fbe2-jessie-x86_64-bundle.tar:   POSIX tar archive (GNU)
...

The type of an executable text file is read from the first line, if it starts with #! and contains an absolute path to whichever interpreter the script needs:

$ cat s0
#!/usr/bin/bash
$ file s0
s0: Bourne-Again shell script, ASCII text executable

The path to the interpreter is not checked by file, so it could point to something non-existent:

$ cat s1
#!/a/very/long/and/winding/path/flimflam
$ file s1
s1: a /a/very/long/and/winding/path/flimflam script, ASCII text executable
  • You could argue that a script is also just plain text... actually there is no such thing as an "executable text file". You can give any file executable permissions. But you're right, if it has no extension it can still be some binary data. – pLumo Nov 12 at 13:23
  • indeed - but there are also files without extension that turn out to be something else - such as ELF 64-bit LSB shared object, ... or that catch-all, data. – j4nd3r53n Nov 12 at 13:25
  • 2
    That's actually backwards: if the file magic (the first few bytes) is not recognized by the operating system as an executable binary type (eg. 0x7f454c46 02010100 for a 64-bit 2's-complement little-endian x86_64 ELF on my Linux system), then the system will assume it to be a shell script and pass it to the default shell for interpretation. The default shell can be explicitly overridden if the file magic is '#!', in which the the remainder of the first line is interpreted as the shell to execute and pass the file as input. – Stephen M. Webb Nov 12 at 20:22
1

90% of the filenames circled are all uppercase letters. This is addressed in our sister-site Software Engineering:

All-uppercase letters stand out and make the file easily visible which makes sense because it is probably the first thing a new user would want to look at. (Or, at least, should have looked at…) As others have already said, file names starting with a capital letter will be listed before lower-case names in ASCIIbetical sorting (LC_COLLATE=C) which helps make the file visible at a first glance.

The README file is part of a bunch of files a user of a free software package would normally expect to find. Others are INSTALL (instructions for building and installing the software), AUTHORS (list of contributors), COPYING (license text), HACKING (how to get started for contributing, maybe including a TODO list of starting points), NEWS (recent changes) or ChangeLog (mostly redundant with version control systems).

This is what the GNU Coding Standards have to say about the README file.

The distribution should contain a file named README with a general overview of the package:

  • the name of the package;
  • the version number of the package, or refer to where in the package the version can be found;
  • a general description of what the package does;
  • a reference to the file INSTALL, which should in turn contain an explanation of the installation procedure;
  • a brief explanation of any unusual top-level directories or files, or other hints for readers to find their way around the source;
  • a reference to the file which contains the copying conditions. The GNU GPL, if used, should be in a file called COPYING. If the GNU LGPL is used, it should be in a file called COPYING.LESSER.

Developers interested in file naming conventions should visit Software Engineering site.

Not the answer you're looking for? Browse other questions tagged or ask your own question.