[erlang-bugs] file:path_open chokes on anything but enoent errors

[Thomas Järvstrand]

Also, the below examples are from the erlang preprocessor documentation so
the ability to use relative paths in the include-directive is definitely
intentional and as such it should work in a predictable way.

> -include("my_records.hrl").
> -include("incdir/my_records.hrl").
> -include("/home/user/proj/my_records.hrl").
> -include("$PROJ_ROOT/my_records.hrl").
>
>
I do agree with the sentiment that relative paths (and even
include-directives without the _lib) should be avoided entirely if at all
possible.

T


On Fri, Oct 26, 2012 at 4:31 PM, Thomas Järvstrand <
thomas.jarvstrand@REDACTED> wrote:

> Please ignore the double negation in my previous email :)
>
> file:path_open(["path1", "path2"], "foo/bar", SomeMode) should not fail
> just because path1 happens to contain a regular file called foo.
>
> T
>
> On Fri, Oct 26, 2012 at 4:26 PM, Thomas Järvstrand <
> thomas.jarvstrand@REDACTED> wrote:
>
>> Well, the correctness of the include-directive can definitely be
>> questioned, I didn't write it, I was just the one who ran into a problem
>> with it :P
>>
>> Regardless, in the general case I don't think that
>> file:path_open(["path1", "path2"], "foo/bar", SomeMode) should not fail
>> just because path1 happens to contain a regular file called foo.
>>
>> Thomas
>>
>> On Fri, Oct 26, 2012 at 3:17 PM, Alexander Harju <
>> alexander.harju@REDACTED> wrote:
>>
>>> I don't think this is a bug at all.
>>> -include(...) should not contain a path.
>>> Use compile:file("one.erl", [{i, Dir},...])
>>>
>>> // Alex
>>>
>>> On Fri, Oct 26, 2012 at 1:39 PM, Thomas Järvstrand <
>>> thomas.jarvstrand@REDACTED> wrote:
>>>
>>>> Figured out what the error was and this is definitely a bug.
>>>>
>>>> Steps to reproduce:
>>>> Create a "project" with the following tree
>>>> *
>>>> *
>>>>>
>>>>> * test-project $ tree*
>>>>> *.*
>>>>> *|-- include*
>>>>> *|   `-- f.hrl*
>>>>> *`-- src*
>>>>> *    `-- one.erl*
>>>>>
>>>>
>>>> f.hrl:
>>>>
>>>>> *-define(foo, foo).*
>>>>>
>>>>
>>>> one.erl:
>>>>
>>>>> *-module(one).
>>>>> -include("../include/f.hrl").
>>>>> one() -> ?hej.*
>>>>>
>>>>
>>>> Now:
>>>>
>>>>> * src $ cd test-project/
>>>>>  test-project $ touch ../include
>>>>>  test-project $ erl
>>>>> ...
>>>>> 1> c("src/one.erl").
>>>>> src/one.erl:2: can't find include file "../include/f.hrl"
>>>>> src/one.erl:3: undefined macro 'foo'
>>>>> error
>>>>> *
>>>>
>>>>
>>>> So, this fails because a component of the filename relative to cwd is
>>>> not a directory, whereas relative to the location of the source-file, it
>>>> would be a directory.
>>>>
>>>> Thomas
>>>>
>>>> On Fri, Oct 26, 2012 at 11:58 AM, Thomas Järvstrand <
>>>> thomas.jarvstrand@REDACTED> wrote:
>>>>
>>>>> Hi!
>>>>>
>>>>> from the file-module:
>>>>>
>>>>>> *path_open_first([Path|Rest], Name, Mode, LastError) ->
>>>>>>     case file_name(Path) of
>>>>>>     {error, _} = Error ->
>>>>>>         Error;
>>>>>>     FilePath ->
>>>>>>         FileName = fname_join(FilePath, Name),
>>>>>>         case open(FileName, Mode) of
>>>>>>         {ok, Fd} ->
>>>>>>             {ok, Fd, FileName};
>>>>>>         {error, enoent} ->
>>>>>>             path_open_first(Rest, Name, Mode, LastError);
>>>>>>         Error ->
>>>>>>             Error
>>>>>>         end
>>>>>>     end;*
>>>>>>
>>>>>
>>>>> For some reason that I haven't deduced yet, my os seems to return
>>>>> enotdir instead of enoent when resolving a relative include. Compiling
>>>>> module with include-directives relative to the source in the shell will
>>>>> result in the call file:path_open([".",
>>>>> "path/to/src.erl"],"../../../relative/path/to/include", [read]), which
>>>>> fails because the second path in the list is never tried due to file:open/2
>>>>> returning enotdir.
>>>>>
>>>>> I have not yet figured out why I get this return value from the
>>>>> c-code, but shouldn't this be more permissive regardless? I feel that at in
>>>>> addition to enoent there should at least be support for eisdir and enotdir.
>>>>>
>>>>> Regards
>>>>> Thomas
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> erlang-bugs mailing list
>>>> erlang-bugs@REDACTED
>>>> http://erlang.org/mailman/listinfo/erlang-bugs
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20121026/a4110cf3/attachment.htm>