[erlang-questions] code:lib_dir weirdness

[Mazen Harake]

This case clause (
https://github.com/erlang/otp/blob/dev/lib/kernel/src/code_server.erl#L775
) seem to check for "ebin" only and then assumes that the directory
before it is an application (#778) or an application with the
"app-vsn" format (#790) for it to return.

Didn't dig into it too much but it should work doing "erl -pa ../app/ebin"

/M

On 22 March 2011 09:40, Ulf Wiger <ulf.wiger@REDACTED> wrote:
>
> I ran into some problems with paths in an eunit test using the OTP slave library.
>
> The main issue was that it didn't work the same in another environment way as on my machine.
>
> After realising that my ERL_LIBS setting covered up some sins (duh!), I tried using
> code:lib_dir() to find the proper app directory (as the code under test was loaded from
> the rebar-generated .eunit directory).
>
> To my surprise, the call to code:lib_dir/1 returned {error, bad_name} on the other machine,
> but worked on mine. I thought I understood code:lib_dir/1, but after reading the docs, I decided
> I probably don't.
>
> The doc says that lib_dir/1:
>
> Returns {error, bad_name} if Name is not the name of an application under $OTPROOT/lib or on a directory referred to via the ERL_LIBS environment variable.
>
> (but above it, it mentions regular directories in the code path, which made me wonder if the above
> is the whole truth.)
>
> Finally, I came to the following conclusion:
>
> $ pwd
> /Users/uwiger/ETC/git/jobs
> $ erl -pa ebin
> Erlang R14B (erts-5.8.1) [source] [64-bit] [smp:4:4] [rq:4] [async-threads:0] [hipe] [kernel-poll:false]
>
> Eshell V5.8.1  (abort with ^G)
> 1> code:lib_dir(jobs).
> {error,bad_name}
> 2> code:add_path("/Users/uwiger/ETC/git/jobs/ebin").
> true
> 3> code:lib_dir(jobs).
> "/Users/uwiger/ETC/git/jobs"
>
> Ok, so far, I'm fairly confused. A few possible explanations exist. Next try:
>
> $ erl -pa `pwd`/ebin
> Erlang R14B (erts-5.8.1) [source] [64-bit] [smp:4:4] [rq:4] [async-threads:0] [hipe] [kernel-poll:false]
>
> Eshell V5.8.1  (abort with ^G)
> 1> code:lib_dir(jobs).
> "/Users/uwiger/ETC/git/jobs"
> 2> os:getenv("ERL_LIBS").
> []
>
> Apparently, code:lib_dir/1 will return a good result if a fully qualified path name exists in
> the code path to the application in question. A relative path won't do. I didn't get that
> from the documentation, nor do I know if it's the intended behaviour.
>
> BR,
> Ulf W
>
> Ulf Wiger, CTO, Erlang Solutions, Ltd.
> http://erlang-solutions.com
>
>
>
>