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

[Alexander Harju]

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/591efefe/attachment.htm>