using haskell as a shell language
Tue, 6 Nov 2001 03:42:51 +0000 (GMT)
On Mon, 5 Nov 2001, Juan Carlos Arevalo-Baeza wrote:
> >current directory is also kept where it is even if the script is being
> >invoked by ../../script.hs (for example) so you either need to somehow
> >pass include path arguments or have all your imports being absolute paths.
> Now, this sounds very wrong to me. The interpreter/compiler should first look for imported modules in the directory where the current source file was found, not in whatever directory is current in the OS. It's much more consistent and reliable that way, eliminating dependencies on arbitrary OS-related values.
That makes a lot of sense. Unfortunately, (to quote Tom Cruise from
Mission: Impossible") "Oh, it's much worse than you think." The name that
gets passed to the interpreter is `the top-level name of the script', so
if /home/tweed/bin/myscript.hs is actually a symlink to
/home/tweed/src/haskell/myscript.hs and I invoke it from /home/tweed/odd/
with ../bin/myscript.hs, what gets passed is "../bin/myscript.hs" (at
least under bash on linux). So whilst the interpreter could in principle
get to thinking it should look in /home/tweed/bin/ for imports by applying
"../bin/myscript.hs" to $cwd, AFAICS there's no way it can get hold of the
directory /home/tweed/src/haskell. When I figured this out I just decided
that the method that would lead to least banging of my head against wall
was just to absolute path any imports of non standard distribution code.
> Is this behavior specified in the Report? And what's the rationale for using it? I mean, not even GCC uses this kind of thing (in fact the C/C++ standards specify the proper search order for #includes).
I guess unix symlinks make handling imports automatically impossible, so
at least on some platforms handling things automatically can't be
specified by the report.
www.cs.bris.ac.uk/~tweed/pi.htm |tweed's law: however many computers
email: firstname.lastname@example.org | you have, half your time is spent
work tel: (0117) 954-5250 | waiting for compilations to finish.