Here are some selected random notes that came out during the beta test period. Enjoy, you may find something useful in here... Read ls.doc before anything in here. Regards, Loren l-rittle@uiuc.edu Mon Mar 2 02:31:15 1992 -- Final note about links not mentioned in ls.doc yet: For the long listing, hardlinks to directories will show a 'D' in place of the 'd', hardlinks to files will show an 'L' in place of the '-' (where the 'd' for a directory would be), softlinks to anything will show an 'l' in place of the 'd' or '-'. What do you think: should hardlinks be identified in this way? I believe that since you have the info, why no use and display it to the user. [This question is not open for debate anymore -ljr] Be careful around softlinks. This version of LS is softlink smart in that it won't try to recurse into them as old versions of ls would (this causes big crash :-). But bugs in LS or the OS can cause strange things to happen if LS tries to resolve some softlinks. Mostly LS will just state that it can't resolve a link or print junk where the name of the linked to filename should go. I don't use softlink, so I'm not going to spend a lot of time fixing what may not be LS's fault. :-) [followup, I now think that LS handles softlinks as correctly as an application can at this point. If anyone notices a bug in ls code in this area, I'm would be glad to hear about it. Do NOT report bad behavior unless you can also provide a code diff to fix the problem... -ljr Mar 2, 1992] Quick note while I'm thinking about it: ls is now quite careful with ANSI color sequences. It should leave the starting color alone now. Should links get special colors (or boldness)? I don't want the ls display to look gawky like some other (unnamed) directory utilities. :-) I have a method in mind for allowing the user to specify the exact pre- and post- ANSI sequences (or maybe arbitrary character sequence) to apply to entries of a given type. BUT nothing has been implemented yet. This would be a generalization of the '-k' switch. Right now, directories are either colored differently or a trailing '/' is appended. With my new method each user could tailor exactly what sort of highlighting would be applied. '@' for softlinks, '/' for dirs might be one person's choice. ITALICS for softlinks, ALT COLOR for dirs, BOLD for hardlink (ALT COLOR and BOLD for dir hardlink) might be another's choice. Sound good? I would want to be careful of not slowing down ls. [this has been implemented. -ljr] Also, ls shouldn't transmit any ANSI codes to VT100 terminals with the '-k' option anymore. It was sending a bounds request sequence which caused junk to appear on the terminal (at least, so I hear). Will a BETA tester with a terminal please check this? Thanks. [checked out ok according to two beta testers. -ljr] I also have another option in mind, '-S', which would work like '-F' but allow one to tailor the information contained in the short listing. UNIX ls allows a form of the short listing where one gets filenames with block counts. I want the general solution to the problem. Sound good? [Still thinking, LS 5.0LJR maybe... -ljr] ChangeLog is not updated yet (and sorely out of date). [removed from public release for now. -ljr] In the long listing, hardlinks are now resolved to show the one file that the OS will reveal the file is linked to. As some have asked for, there is no way to show *all* files that are linked together. Currently, this information is shown exactly as softlink link information is. E.g. -> . I thought that this was impossible, till it was pointed out that C= choose to make links visible to the application. Basically, Lock(), NameFromLock(), UnLock() reveals where a link is linked to! Am I happy? :-/ They don't give link count, but they give the base file name... Weird... [Still not implemented, still thinking:] I also have another option in mind, '-S', which would work like '-F' but allow one to tailor the information contained in the short listing. UNIX ls allows a form of the short listing where one gets filenames with block counts. I want the general solution to the problem. Sound good? [Is there a demand for this option? Or can it wait till LS-5.0ljr --- the complete rewrite in ASM. Mike, you have won, BTW. I think that I now see the light of what you have been telling me this past year. After I finish the project, I'll tell you if the light is the right color... ;-] See REXX/, ALIASES/ and HIGHLIGHT_SETS/ for some interesting scripts. If you come up with any highlight sets that you use, please mail them for inclusion with the public release. Place a comment with your name, et cetera, if you want. Thanks. [This is an open offer to anyone -ljr] LS now uses 2.04 style buffered IO: LS is now ~%5 faster to CON: (well, DisplayHandler's CNN: --- who uses CON: anymore? :-) and as much as %15 faster to file (at least on my test system). LS is now slower to NIL:... :-) TIMES compared to last BETA, which compared quite favorably to the last public release version of LS (i.e. 4.5 is almost always as fast or faster than 4.1/2). ALL times comparisons are for SHORT listing method with standard highlighting. I have noticed that LONG listings are a bit slower with buffered IO! I'm looking into this. Currently all IO is done with the buffered routines (even the LONG listing, so they will appear a tiny bit slower...). The presort by entry type now only compares file vs. dir instead of ordering by the exact value of the dir type field. Most people seemed to think this was best. I agree. No switch will be provided as too many options are available already... :-) '-f' added back in. This option, if present, will hide directories. Entire program in C now. All (unoptimized) ASM routines were converted to C. It appears that the compiler is generating better code than Justin did... :-) >I have a simple idea for ls. If you have multiple assigns, ls only >shows one of the directories. Could you add a switch, so that ls would >show ALL assigned directories? Humm... I could... But, I won't before the next release... :-) Because, you see, this is not a simple idea... There is nothing simple about the way some crazed engineer at C= implemented this feature. :-/ (half a smile... :-) For example, assign xtra: root0: root1: root2: root3: ls -R xtra: Just thinking about some of the issues invloved is making me sick. :-) Obligatory flame at C=: How come WSH was able to implement PathMan years ago (under 1.2/1.3 even) in a system transparent way, but C= had to expose all the blasted details to the programer! The system should be hiding these implementation details from me the maintainer of a lousy directory lister... This and the soft/hard links area are currently touchy areas with me...