On Tue, Jun 19, 2012 at 6:19 PM, Johan Tibell
<johan.tibell@gmail.com> wrote:
Another problem with the executable-path like distinction is that it's no longer possible to find out which executable (i.e. ghc) is running the script. At a minimum the Script and Interactive constructors would have to expose that.
getExecutablePath :: IO FilePath
has a clear meaning: return the path to the executable that's currently executing.
Except it does not.
First, as the author of the executable-path library, it seems to me that the GHC docs are indeed correct saying that this is impossible to implement on some systems. My (conjectural) example for such systems are older BSD systems (FreeBSD before v6.0 iirc, NetBSD, OpenBSD). And these are even pretty standard Unix systems!
Another serious issue is that the notion itself does not seems to be well-defined. For example think about symlinks (soft, hard?). Probably there exist other more strange Unix features I'm not aware of, which are complicating the matter further. Symlinks also exist on Windows by the way, though not advertised much.
So, while of course I agree that there is a need for such a function (hence the 3 independent libraries on Hackage trying to provide it), unfortunately the situation is rather muddy.
If we want a function that provides the script/interactive/executable guessing, we should provide both functions. The guessing one should have this warning:
-- N.B. This function might return Executable in the case of Script/Interactive and vice versa.
I agree, clearly the proper solution is to provide both functions. That's also what executable-path does, with big warnings and all. Though I think that the runtime itself can (or could) reliably determine whether it is a script or interactive session, bytecode or compiled, so there is no need to guessing; and since the meaning of this function is implementation-dependent anyway, there is no harm making it GHC-specific. It is also not unprecedented to have GHC-specific functionality in base.
Balazs