code:lib_dir weirdness

Ulf Wiger <>
Tue Mar 22 09:40:36 CET 2011

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
$ 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).
2> code:add_path("/Users/uwiger/ETC/git/jobs/ebin").
3> code:lib_dir(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).
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.

Ulf W

Ulf Wiger, CTO, Erlang Solutions, Ltd.

More information about the erlang-questions mailing list