discussion of "The Art of Unix Programming"

Discussion in 'General Linux' started by mek42, Jan 16, 2014.

  1. mek42

    mek42 Member

    Messages:
    31
    Likes Received:
    15
    Trophy Points:
    8
    Another thread here referenced this work (link immediately below) and this thread is to discuss the work.

    http://www.catb.org/~esr/writings/taoup/html/index.html

    My first question, ESR claims Unix is without file attributes. Aren't permissions a file attribute? What am I misunderstanding?

    DevynCJohnson likes this.
  2. DevynCJohnson

    DevynCJohnson Well-Known Member Staff Member Staff Writer

    Messages:
    1,336
    Likes Received:
    1,073
    Trophy Points:
    113
    Haider92 likes this.
  3. MikeyD

    MikeyD Active Member

    Messages:
    232
    Likes Received:
    112
    Trophy Points:
    43
    I think the key difference is ESR mentions file attributes at the OS level. You're right that Linux has file attributes, but since Unix/Linux recognizes the contents of a file to determine how to handle said file rather than some arbitrary attribute associated with the file, it isn't limited to certain programs in order to be interpreted correctly. An ASCII text file will generally look the same whether you use vi, pico, nano, etc and regardless of the platform (as long as the shell is the same.) For example, writing a text file on SUN OS and opening it on Redhat will look identical.

    On the other hand, a '.doc' file won't look the same if it is opened in notepad or wordpad and many programs won't even open it (Excel, Powerpoint, etc.) These restrictions don't exist on Linux. Hell you can 'cat' an executable file in Unix if you want (it will be nothing but gibberish, but you still have the option)

    The wording could be better, but I think that is the general difference (or I may be way off, but that was my interpretation at least)
  4. mek42

    mek42 Member

    Messages:
    31
    Likes Received:
    15
    Trophy Points:
    8
    Is the filename extension really an attribute of the file? I thought he was referring to things like the sticky bit or archive / read-only bits.

    Speaking of, on Linux systems, where do file permissions live? Are they part of the pointer-thingee that the filesystem uses to know where to find the file on the disk? (Please correct me if my filesystem understanding is grossly wrong.)
    DevynCJohnson and ryanvade like this.
  5. KenJackson

    KenJackson Active Member

    Messages:
    129
    Likes Received:
    28
    Trophy Points:
    28
    It must be in the directory entry. I just did this experiment to verify:
    Code:
    touch afile
    ln afile bfile
    ls -li ?file
    chmod 666 bfile
    ls -li ?file
    The touch command created a new empty file named afile.
    The ln command created a hard link, which is a new directory entry to the file.
    ls -li shows the two files have the same i-node number, thus they are the same file.
    chmod changed the permissions on one but not the other, as shown by the subsequent ls.
    Therefore, the permissions must be stored in the directory entry, not in the i-node.
  6. mek42

    mek42 Member

    Messages:
    31
    Likes Received:
    15
    Trophy Points:
    8
    Is there a utility that makes directories directly human readable, as opposed to querying them like ls does?
  7. ryanvade

    ryanvade Administrator Staff Member Staff Writer

    Messages:
    1,273
    Likes Received:
    431
    Trophy Points:
    83
    I believe the File System itself holds the permissions...
    http://en.wikipedia.org/wiki/File_system_permissions

    Which partially explains why installing Linux on a file system like NTFS or Fat32 is a very bad idea.

    The other reason is, of course, fragmentation and slower speeds. ;)

    And since Directories are just FILES, there is probably a utility SOMEWHERE that can let you open them as FILES. Whether or not it is human readable is unlikely.
    DevynCJohnson likes this.

Share This Page