[erlang-questions] code:lib_dir weirdness

Mike Oxford <>
Tue Mar 22 09:59:41 CET 2011


Did you happen to try using "-pa ./ebin"

I have no reference, but I'm curious if the leading "./" would help.
-mox

On Tue, Mar 22, 2011 at 1:40 AM, Ulf Wiger
<>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
>
>
>
>


More information about the erlang-questions mailing list