discussion of "The Art of Unix Programming"



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)
 
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.)
 
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?

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.
 
Is there a utility that makes directories directly human readable, as opposed to querying them like ls does?
 
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.
 

Members online


Latest posts

Top