[erlang-questions] filelib:is_* is missing something necessary.

[Björn Gustavsson]

On Sat, Nov 28, 2009 at 3:09 PM, Michael Richter <ttmrichter@REDACTED> wrote:

> It seems to me that they're implemented in terms of
> *read_file_info/1*instead of
> *read_link_info/1* and I was wondering if it might not be possible to make
> one of the following changes, depending on what people in the community
> found most useful (I'm easy either way, personally):
>
>   1. Change the return values such that, say, *is_file/1* returns *true* if
>   the named file is a straight file, but returns *symlink* if it is a
>   symbolic link *to a file*.  (In any other situation -- directory, symlink
>   to directory, special file, etc. -- it would still return *false*.)

I general, we don't do backward incompatible changes, so this
solution is out. (Also, we don't like is_* functions that return
other values than 'true' or 'false'.)

>   2. Add a predicate *is_symlink/1* so that I can first check if
>   something's a directory and then follow through with a check if it's a
>   symbolic link to one.

Sounds better.

> Currently I've just rewritten the predicates for my code, but in general I
> prefer to use system libraries wherever possible so I'd really like to see
> one of the two above approaches (or perhaps a third, superior one) written
> in.  My predicate for *is_symlink/1* looks like this:
>
> is_symlink(Name) ->
>    case file:read_link_info(Name) of
>        {ok, FileInfo} -> FileInfo#file_info.type =:= symlink
>    end.

Are you sure want it to crash if you call it with a name of a file that
does not exist? is_regular/1, for instance, returns 'false' if the file
does not exist.

Maybe you would like to provide a patch? The instructions for
patch submission are here:

http://wiki.github.com/erlang/otp/submitting-patches

In order for the code to be included in the 'pu' branch so that
others can test it and comment on, the code itself and a good
commit message is all that is needed.

In order for the patch to be included in Erlang/OTP, you (or
someone else) will also need to write documentation and test
cases. Since the functionality is clearly missing, it is very likely
that we will actually include it in OTP.

-- 
Björn Gustavsson, Erlang/OTP, Ericsson AB