On Thu, Nov 08, 2001 at 02:02:12AM -0500, Glenn Maynard wrote: > Here's the basic problem: > > lftp 0:/> cls cs > cs/ > lftp 0:/> cls cs/ > ai/ db/ indent.exe xtypes.zip > > This is a known, documented problem; the fundamental problem being no > fast, portable way to find out if a path is a file or a directory. This > affects find (and hence du); you can't give it a filename.
Automatically change functionality depending on file type is not always good. E.g.: mkdir -p aaa/aaa ls aaa or touch aaa ls aaa produce the same output, but the meaning is different. Traditions are another matter, of course. > I suppose it could be tried brute-force. ie, given "cls my/dir", try to > list "my/dir"; if that fails, try "my/". If that succeeds, assume "dir" > is intended to be a file, and just return a FileSet with it; if it also > fails, fail the job. (This should be optional, to implement things like > cls -d when you actually *want* to see directories themselves.) It > should probably also fail if it tried to chdir into my/dir, failed, > tried my/, succeeded, and dir turned out to be a directory (unless the > "ls -d" option is on). Maybe something like this can be done. > This could be done cleanly in ListInfo, adding a path argument. If it I don't think ListInfo should handle path-to-file argument. Anyway, it would have to list all parent directory to get the info. Maybe another GetFileInfo class should be created. > supported wildcards, it might eventually be able to merge with Glob, too. > I havn't looked at either, so I don't know how difficult this would be to > implement. (I don't really understand why they need to be separate; their > functionality seems to be very similar.) Glob uses ListInfo. Glob has to work on all directory levels, e.g. */*/*, ListInfo works on a single directory. > By the way, du is implemented; I'll wait until you get through the > previous small patch before sending it. Ok, good. -- Alexander.
