DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=29689>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=29689 [net] Unix parser does not handle special files. ------- Additional Comments From [EMAIL PROTECTED] 2004-06-20 18:22 ------- Well, we can certainly do that. However, maybe we ought to take care of all the cases: Here is what man ls (as interpreted by http://www.mcsr.olemiss.edu/cgi-bin/man-cgi?ls+1 - this just happened to be the first such entry google found for me, how authoritative is it? ) says: The mode printed under the -l option consists of eleven possible characters. (note sc, I only count 9). The first character may be one of the following: d if the entry is a directory; l if the entry is a symbolic link; b if the entry is a block special file; c if the entry is a character special file; s if the entry is a XENIX semaphore; m if the entry is a XENIX shared data (memory); p if the entry is a fifo (named pipe) special file; S if the entry is an AF_UNIX address family socket; - if the entry is a regular file. So solving all of these would entail a regex of [sbcdlf-mpS]. Before committing such a change, though, I would like to ask, is this list authoritative, and if so, SHOULD ftp be returning XENIX semaphores (whatever they are), XENIX shared data, AF_UNIX address family sockets, fifo special files, etc. Also, are these meanings common to all systems or do the letters have different meanings on different systems? Any thoughts? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
