On Mon, 2007-03-12 at 17:35 +1300, Shams wrote: > Hi, > > My question would be: > > Is it the kernel or the shell and other user land program eg. bash, > ls, rm responsible for hiding the dotted files? > > Historically: > Now why is this not just a attribute (like the evil OS Windows does) > or permission of the file instead of using obsure file names ie. the dot > prefix to hide the file? > > Thanks > Shams > > -- > > "Mikkel L. Ellertson" <mikkel@xxxxxxxxxxxxxxxx> wrote in message > news:45F4229E.6050106@xxxxxxxxxxxxxxxxxxx > > William Case wrote: > >> Hi All; > >> > >> Just did some changes in my ~/.* ( dot files ) and started wondering why > >> Linux uses dot files for its 'user' data. Its a small annoyance to have > >> to specify .* each time I use them. The annoyance is primarily not > >> because it's difficult but because it is odd -- different from anything > >> else and data files get mixed (kinda) with my working documents. Why > >> not just have a standard additional directory for 'config', or whatever > >> name, to hold all the user application type data. Is the reason > >> historical or is there a pragmatic purpose? > >> > > This is the way Linux hides files and directories. You will notice > > that they do not show up in a normal ls listing, or in the file > > selection window of most programs. If you have your file manager set > > up not to show hidden files/directories, they will not show up there > > ether Originally Unix used teletypes for interface and paper tape for program loads. Thus the ascii character set without lower case. This is handled by 7 bits (and can be handled by 5 bits). Thus a character would not have the bit 7. The reason this is important is that in Microsoft, as in CPM, the msb of the first three characters of the file name stores the read only, archive and hidden attributes. Since the character set didn't include extra bits, the period accomplished the job and was more visible to the root users who administered the system. Other schemes have been used, one was a header that contained all kinds of attributes in a highly secure system. Apple used to use a "fork" which had a short file that contained attribute and application information on each file but was stored separately for compatibility with main frame and minicomputer systems. An old Cyber system used a list that followed the file. I don't recall now how DG and DEC handled it, but they had their own systems as well, but almost everyone recognized that it was necessary to have files that the typical user didn't need to see, that had to have a convenient location on a per/user basis (the users home directory), and that could easily be recovered, moved copied and controlled by system administrators. Of all the systems I have used the Unix form seems the least restrictive, simplest to implement, and sufficiently robust. In other words, once you become familiar with it, you will prefer it to most other methods. YMMV. Unix also used to have a generally accepted practice that all user config files were to be in straight text, so they could be human readable. I am happy to see that Linux seems to be retaining that philosophy. Microsoft brought so much misery with their encoded classes and binary formats that I hated it whenever one of the people I worked with had a problem on their systems. I admired grately the one administrator who had enough seniority to put a placard in her window that said, " I don't do windows!". My personal opinion, but apparently shared. Regards, Les H
