FTP LIST Specification - Peter N Lewis, Feb 1994. Target Audience: FTP server authors and FTP client authors who wish to parse the LIST command to display information in a local (non-english or graphical) manner. Premise: There is no way to change existing servers in a reasonable amount of time. For a long time the FTP LIST output has been unspecified and yet there are more and more programs each year that rely on this format in one way or another. To try to combat this problem I am proposing a specification of a LIST format that is easily decoded and very close to the current common format. Please note that I am offering up this specification in the hope of increasing compatibility amongst servers and clients but no one is under any obligation to pay any attention to this document. It is necessary to distinguish between the output format and the method of decoding the format since we wish to allow all decoders to interpret as many of the current versions of the LIST format, while trying to reduce the variation in the output. The output should be something like this: -rw------- 1 peter 848 Dec 14 11:22 00README.txt or - whatever you feel like 848 Dec 14 11:22 00README.txt This specification only defines the first character, and the information (size/date/name) at the end of the line. The infoirmation between is at the discretion of the server author, although you need to be careful to avoid displaying something that will match the date format. The first character should be one of [-dl]. "-" means a file, "d" means a directory and "l" means a link. In many cases it may be preferable to resolve the link and display it simply as a file or directory, since the client otherwise has no way to tell which it is except by trying to change directory into it (or by using the -p switch, see later). Currently the only way I've been able to find to determine if a link is a file or directory is to check if it has an extension (ie terminates in a dot followed by 1 to 3 characters) (this is obviously less than an ideal solution) The rest of the line should be found by matching <3-letter-month-code> (regexp: / ([A-Za-z][A-Za-z][A-Za-z]) .[0-9] [0-9 ][0-9]/ where $1 is a valid english month) and using the earliest such match (since that string may be part of the file name. The month name match should be case insensitive, and should match one of the twelve English three-letter month abbreviations: Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec. Servers should always use the English version. Clients should of course display the date in the local language and format where possible. Some servers may currently use French month names, so you might like to also accept them (though it would be better to have the servers change to English). Once you have found that, you can determine the file size by looking at the number immediately before that match location. This number may be missing or invalid for directories, links, or other "file types" (and thus should be ignored except for files). The date format is either: MMM DD hh:mm OR MMM DD YYYY OR MMM DD YYYY In the first case, the year is taken to be the most recent past occurence of the date. Servers should choose to switch over well before this becomes close to allow for variations in the local time (not to mention user confusion). And the file name follows the date and continues to the end of the line. If the file name is a link, it may include a pointer to the original, in which case it is in the form "name -> link". This is really very bad, since that is also a perfectly valid file name under unix and other systems (especially the Macintosh). Servers should not do this where possible (resolve the link, correct the filesize and display as a file or directory is in general a better plan). The information between the first character and the size (for files) or date (for other types) should be ignored. Servers may put any system dependent information here (although as noted about, you should avoid displaying anything that looks like a date). When decoding, it is important to note that many implementations include a line at the start like "total ". Clients should ignore any lines that don't match the described format. If no matches are found, and more than a few lines are read, then the server is probably non-conformant, so you might consider using the NLST command. Also, listings may include the special files "." and "..". I have no idea what you do with them or how you tell if they are special. Servers should not display them where possible. Servers should try to support the important unix "ls" switches: -p - add / on the end of directories, especially important for links. -F - add /, *, @, = to the end of various files. -l - in the long format described above (ie LIST should ignore it) -R - recursive listing (some mirroring software relies on this) Site maintainers should consider the problem of determining the type of a link and try to maintain the original name or at least the original extensions (this will also help users as well as client software). Caveates: A better sollution would be to implement a structured list command, but this is not practical (even if this were done, it would be years before a reasonable percentage of servers were converted, and thus this document remains necessary). Although it looks unix-centric, and english-centric, the intention is the exact opposite. By standardizing the list display, we allow clients to display dates in the local language, and listings in a local and/or graphical format. BNF: ::= | | ::= SPC SPC ::= "-" | "d" | "l" ::= | ::= | ::= SPC SPC