7

When I do 'ls -l', I might get something like this:

-rw-r--r-- 1 root root 209 Mar 30 17:41 fname

The first field is the -, which means this is a file.

If it was a directory and not a file, the first field would be a d.

Why did the creators of Unix decide to use a d for directory, which is clear and intuitive, yet use a - for a file? Why not use f for a file?

Edit
Really interesting responses. Lots of different ideas, and they all make sense, even if some seem more inadvertently true than implemented for that reason and/or are documented as that being the reason.

Monica Heddneck
  • 170

1 Answers1

12

Historically, one of the big design decisions in Unix was to consider everything as a file.¹ This transpires in early ls and stat manpages; for example, in V3 (February 1973), the stat manpage (which describes the mode used by ls) says that

The mode is a six-character string whose characters mean the following:

  1. s: file is small (smaller than 4096 bytes)
    l: file is large
  2. d: file is a directory
    x: file is executable
    u: set user ID on execution
    -: none of the above

etc.

In V4 (October 1973) the mode starts to resemble what we have today; the ls manpage says

The mode printed under the -l option contains 10 characters which are interpreted as follows:

the first character is
d if the entry is a directory;
b if the entry is a block-type special file;
c if the entry is a character-type special file;
- if the entry is a plain file.

The next 9 characters are interpreted as three sets of three bits each.

So it seems the creators of Unix really thought that a plain file is “just” the default, nothing special, so it doesn’t deserve a character — everything is a file, and only files which aren’t plain files need additional description. One could think of - as signaling the absence of “specialness”.

¹ Strictly speaking, the design decision was to make everything accessible through the file system, not to consider everything as a file; but as a result, everything had to be made available as some sort of file, and this required being able to distinguish different types of files. See section 3 of The UNIX Time-Sharing System.

Stephen Kitt
  • 434,908
  • wait a minute tho....if a plain text file is the expected default, then shouldn't Unix say, "Hey guys, this is just the default thing we like, so give it a hearty "YES"!'. But the dash seems to represent a 'no'. Like 'r-x' means 'no' for 'write'. The dash's meaning is going back and forth as a Yes and a No, so to speak (at least if you look at it this way...) – Monica Heddneck Sep 22 '18 at 20:17
  • I take the dash as meaning “default”. Files are plain files (not plain text files, just plain files, as opposed to directories and special files) by default, unreadable by default (i.e. if they don’t have the read bit set), etc. – Stephen Kitt Sep 22 '18 at 20:20
  • A file in computer science is just collection of bytes organized together in some logical form. What normally users think of a "file" is not the same meaning to the computer. So think of it as "collection of bytes". Unix/Linux itself won't really care what particular arrangement of bytes that is, besides the special types relevant to the OS itself - those types that Stephen cited in the answer. Now, special applications, like your desktop environment or GNOME specifically, those additionally will look at the header of file - that's called mime type. – Sergiy Kolodyazhnyy Sep 22 '18 at 20:27
  • 4
    @Sergiy bit of a nitpick, the rest of your comment is fine, but no, the MIME type isn’t the header... (How are file types known if not from file suffix?) – Stephen Kitt Sep 22 '18 at 20:31
  • @StephenKitt Agreed, I probably should have explained that from the magic number, which is the header part. – Sergiy Kolodyazhnyy Sep 22 '18 at 20:33
  • 2
    @Sergiy, no, there is no header. There are heuristics to try to guess a file’s type but there is no guaranteed header, or magic number, etc. All sorts of fun and games can be had by abusing those guesses. – Stephen Kitt Sep 22 '18 at 20:34
  • @StephenKitt Technically, the header is irrelevant to the OS itself, so there your statement "there is no header" holds true, and yes it's not guaranteed and OS itself doesn't require it. But when we're talking about specific applications, like GNOME or file utility - those do take first several bytes of a file into account. That's what I was trying to deliver in my first comment. – Sergiy Kolodyazhnyy Sep 22 '18 at 20:41
  • 2
    @Sergiy I know what you’re trying to convey, but in my experience it’s too simplistic and it ends up confusing users. file, and the shared MIME database, apply a sequence of detection tests, some of which look at the first few bytes of a file. But claiming that the first few bytes of a file give an indication of its type gives readers the wrong impression. There is no guaranteed way of determining a file type (unlike Mac OS Classic or PalmOS where each file had a type and creator code). – Stephen Kitt Sep 22 '18 at 20:47
  • @StephenKitt OK, I should have expressed that better. Then again, I can only do so much in the comments. – Sergiy Kolodyazhnyy Sep 22 '18 at 20:49