Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!leah!rpi!rpi.edu!tale From: tale@pawl.rpi.edu (David C Lawrence) Newsgroups: comp.unix.wizards Subject: Re: Dot files always first in directory? Message-ID: Date: 5 May 89 15:32:15 GMT References: <11108@bloom-beacon.MIT.EDU> <3540@udccvax1.acs.udel.EDU> <2778@buengc.BU.EDU> Sender: usenet@rpi.edu Reply-To: tale@pawl.rpi.edu Followup-To: comp.unix.wizards Distribution: comp Lines: 31 In-reply-to: bph@buengc.BU.EDU's message of 5 May 89 10:13:37 GMT In <11108@bloom-beacon.MIT.EDU> jik@athena.mit.edu (Jonathan I. Kamens) writes: jik>It it safe to assume when writing a program which manipulates jik>directories that . and .. will always be the first two entries in a jik>directory? In article <2778@buengc.BU.EDU> bph@buengc.BU.EDU (Blair P. Houghton) writes: bph> To beat this horse quite dead, any leading character that would bph> sort before the period will place the filename before the . and bph> .. in a directory listing. The ascii characters that will do bph> this are space, !, ", #, $, %, &, ', (, ), *, +, ,, and -. I bph> haven't tried it, but I bet you can get the nonprinting ascii bph> characters to do it too. There are 32 of those. Now here is where it really matters: are you using a script or C to get at the directory. Jonathan showed, in either the original posting or in a follow-up, that he wanted an example in C. Even in the script, it is only the default output of ls(1) that will sort names the way you offer; ls -f will give them the way they are arranged in the block. #.newsrc# currently is the last thing listed in my home directory by an ls -f. With Sun machines, . and .. are stated as being the first two entries in a directory block "by convention". In fact, fsck will complain if it comes across a d block which first two inodes do not point to itself and to its parent respectively (exception being the root directory whose parent does not exist; .. == .). I suspect that if Jonathan is writing for multiple architectures for Athena then he should check the manuals for different machines he knows he will have to support, just to be sure. -- tale@rpitsmts.bitnet, tale%mts@itsgw.rpi.edu, tale@pawl.rpi.edu