* Debian `potato' (that's the as-yet-unreleased successor to 2.1)
* kernel 2.2.13
* /lib/libc.so.6 -> libc-2.1.2.so*
* fileutils 4.01
The following program is intended to simply display the st_mode field
of the result of calling `stat' on the files named on the command line.
#include <stdio.h>
#include <sys/stat.h>
int main (int argc, char *argv[])
{
struct stat stat_buf;
for (argc--, argv++;
argc;
argc--, argv++)
{
if (0 == lstat (*argv, &stat_buf))
{
#define TEST_FOR(token) if (S_ ## token (stat_buf.st_mode)) { printf ("`%s' is a
%s\n", *argv, #token); }
TEST_FOR(ISDIR );
TEST_FOR(ISCHR );
TEST_FOR(ISBLK );
TEST_FOR(ISREG );
TEST_FOR(ISFIFO );
TEST_FOR(ISLNK );
TEST_FOR(ISSOCK );
}
else
{
perror (*argv);
}
}
}
The behavior I'm seeing looks like this (the file `input' is a
symbolic link, to `/var/spool/mail/inpu', if that matters):
17:04:06 [offby1]$ ./stat input
`input' is a ISLNK
17:04:47 [offby1]$ ./stat input/
`input/' is a ISDIR
17:04:48 [offby1]$
Note that the st_mode field differs depending on whether the file name
ends with a slash.
I suspect this behavior is wrong; the manual (Edition 0.08 DRAFT of
the libc manual, in File: libc.info, Node: Reading Attributes.) says
If FILENAME is the name of a symbolic link, `lstat' returns
information about the link itself; otherwise, `lstat' works like
`stat'.
I'd say that `input/' is indeed the name of a symbolic link, and
therefore lstat should return information about the link itself.
In any case, it's not entirely clear *what* the correct behavior
should be, so at the very least, the manual should be clarified.
For reference, here's the text of communication between Jim and I, in
which I complained about similar behavior in `ls'. I assume that that
behavior (which is still happening on my system) is caused by the
behavior in lstat that I described above.
>>>>> "Jim" == Jim Meyering <[EMAIL PROTECTED]> writes:
Jim> Eric Hanchrow <[EMAIL PROTECTED]> writes:
Jim> | I don't know if this is a bug, but it's surprising behavior.
Jim> |
Jim> | Here's what I'm seeing. In these examples, in my shell's working
Jim> | directory, there's a symbolic link named `input', which points to
Jim> | `/var/spool/smail/input/'.
Jim> |
Jim> | Let's examine the symlink in different ways.
Jim> |
Jim> | $ ls -l input
Jim> | lrwxrwxrwx 1 offby1 offby1 23 Dec 2 14:38 input ->
/var/spool/smail/input/
Jim> |
Jim> | $ ls -l input/
Jim> | total 0
Jim> |
Jim> | That's the surprising behavior: `ls -l' gives different results
Jim> | depending on whether I put a slash at the end of the file name. In
Jim> | the first case (when I did not append a slash), it returned
Jim> | information about the link itself; in the second case (when I did
Jim> | append a slash), it returned information about the directory to which
Jim> | the link pointed, as if I'd passed it the `--dereference' option.
Jim> |
Jim> | Note that when I don't pass `-l', it doesn't matter whether I append a
Jim> | slash or not:
Jim> |
Jim> | $ ls input
Jim> | $ ls input/
Jim> |
Jim> | Is this the correct behavior? If so, is it documented somewhere?
Jim> |
Jim> | I'm using Debian 2.0 ("Hamm") Linux.
Jim> |
Jim> | Here's some information on my system, and the version of fileutils
Jim> | that I have ...
Jim> |
Jim> | $ uname -a
Jim> | Linux snowball 2.0.36 #1 Tue Dec 1 22:02:46 PST 1998 i686 unknown
Jim> |
Jim> | $ command ls --version
Jim> | ls (GNU fileutils) 3.16
Jim> Thanks for the report.
Jim> I think this was fixed in fileutils-4.0.
Jim> It is certainly fixed in my development sources.
