I am writing a simple c program which checks its command-line arguments
and classifies them according to whether they are directories, regular
files, symbolic links or other. (If one of the arguments is not a path to
any kind of file or directory, an error message is emitted.)

The problem is that my program incorrectly reports symbolic links as
regular files.

What is a/the proper way to portably detect symbolic links in a unix-like
environment? I am using linux, but it seems like it should be possible to
do this portably.

For example, how portable are readlink() and lstat()?

Here is my current code. It is supposed to print the file or directory
name followed by an 'L' for symlinks, a 'D' for directories, an 'R' for
regular file, and an 'O' for any other file or directory which can be
stat()ed. Anything which cannot be stat()ed will produce an error message
of some kind.

/********* begin code **********************/

#include <stdio.h>
#include <string.h>
#include <errno.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>


int main (int argc, char **argv)
{
int result, i;
struct stat buf;
extern int errno;

for(i = 1; i < argc; i++)
{
errno = 0;
result = stat(argv[i], &buf);

if (result == -1)
printf("%s: %s\n", *argv, strerror(errno));
else
{
if (S_ISLNK(buf.st_mode))
printf("%s L\n", argv[i]);
else if (S_ISREG(buf.st_mode))
printf("%s R\n", argv[i]);
else if (S_ISDIR(buf.st_mode))
printf("%s D\n", argv[i]);
else printf("%s O\n", argv[i]);
}
}

return 0;
}



/****************end of code **********************/

Thanks for taking a look at it.

--Mac

[ Post a follow-up to this message ]

On Fri, 16 Apr 2004, Mac wrote:

> For example, how portable are readlink() and lstat()?

They're both standard, and are the answer you're looking for.
Replace your call to stat() with a call to lstat().

HTH,

>   extern int errno;

Don't do this; #include <errno.h> instead.

HTH,

--
Rich Teer, SCNA, SCSA

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-online.net

[ Post a follow-up to this message ]

On Sat, 17 Apr 2004 07:05:32 +0000, Rich Teer wrote:

> On Fri, 16 Apr 2004, Mac wrote:
> 
>
> They're both standard, and are the answer you're looking for.
> Replace your call to stat() with a call to lstat().
>
> HTH,

Yes, thanks very much.

> 
>
> Don't do this; #include <errno.h> instead.

I did both. I guess I don't see the harm in what I did. But I certainly
admit that it isn't necessary. To me it is just a way of emphasizing that
errno comes from somewhere else.

>
> HTH,

Yes, thanks.

--Mac

[ Post a follow-up to this message ]

"Mac" <foo@bar.net> writes:
 
>
> I did both. I guess I don't see the harm in what I did. But I certainly
> admit that it isn't necessary. To me it is just a way of emphasizing that
> errno comes from somewhere else.

Often errno is declared in some special way, such as having one copy
per thread.  Just declaring it as 'extern' will break things in those
cases.

--
Måns Rullgård
mru@kth.se

[ Post a follow-up to this message ]

examnotes <mru@kth.se> writes:

>"Mac" <foo@bar.net> writes:
 
[vbcol=seagreen]
>Often errno is declared in some special way, such as having one copy
>per thread.  Just declaring it as 'extern' will break things in those
>cases.

Not nessarily:

#define errno (*(___errno()))

makes this just work fine:

extern int errno;

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

[ Post a follow-up to this message ]

On Sat, 17 Apr 2004, Mac wrote:

> Yes, thanks very much.

My pleasure.

> I did both. I guess I don't see the harm in what I did. But I certainly

No harm (that I can think of), but not necessary, and might mask
errors.

> admit that it isn't necessary. To me it is just a way of emphasizing that
> errno comes from somewhere else.

An experienced programmer will know this, and if you're going to do it,
then to be consistent you should do the same for all the other externals
in your program, like printf, lstat, etc.  (And no, I'm not suggesting
even for an attosecond that you actually do this!)

--
Rich Teer, SCNA, SCSA

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-online.net

[ Post a follow-up to this message ]

On Sun, 18 Apr 2004 12:55:38 +0200, Måns Rullgård wrote:

> "Mac" <foo@bar.net> writes:
> 
>
> Often errno is declared in some special way, such as having one copy
> per thread.  Just declaring it as 'extern' will break things in those
> cases.

Interesting. I don't have any real experience with threads, but it is
clear that "errno" is something that would need to be dealt with specially
in a threaded environment.

Without threads, I believe "extern int errno" HAS to work. I'll study up
on threads before I use them.  ;-)

regards,
Mac

[ Post a follow-up to this message ]

On Sun, 18 Apr 2004 19:10:00 +0000, Rich Teer wrote:

> On Sat, 17 Apr 2004, Mac wrote:
> 
>
> My pleasure.
> 
>
> No harm (that I can think of), but not necessary, and might mask
> errors.
> 
>
> An experienced programmer will know this, and if you're going to do it,
> then to be consistent you should do the same for all the other externals
> in your program, like printf, lstat, etc.  (And no, I'm not suggesting
> even for an attosecond that you actually do this!)

I agree with all your arguments except this last one. Errno isn't a
function, so different rules apply. But anyway, in the future I'll just
use it (after inclcuding errno.h).

Thanks again.

--Mac

[ Post a follow-up to this message ]

> I agree with all your arguments except this last one. Errno isn't a
> function, so different rules apply.

On what do you base that assertion? How do you know errno can never be
a macro encapsulating a function? For that matter, how do you know
errno can never be a short? Or a long? Or unsigned, for that matter?

Unless memory fails me, I don't believe ANSI or POSIX makes any promise
other than that "errno" is some kind of object that can be compared
with positive integral values. I'm not even sure it requires that
errno be "non-const".

b

[ Post a follow-up to this message ]

"Brian Raiter" <blr@drizzle.com> wrote, on Mon, 19 Apr 2004:

> Unless memory fails me, I don't believe ANSI or POSIX makes any promise
> other than that "errno" is some kind of object that can be compared
> with positive integral values. I'm not even sure it requires that
> errno be "non-const".

The current POSIX standard says the following things about how
errno is defined (these are not literal quotes):

errno is an lvalue with type int, defined in <errno.h> either
as a macro or as an identifier with external linkage.

The only valid way for applications to obtain the definition
of errno is by including <errno.h>.

If errno is a macro and an application suppresses the macro then
the behaviour is undefined.

I think what this means for the following code mentioned earlier in
the thread:

#include <errno.h>
extern int errno;

is that it will either fail to compile, or will compile and run
exactly the same as it would if the second line had not been there.

--
Geoff Clare <nospam@gclare.org.uk>

[ Post a follow-up to this message ]