Proposal: Add getFullProgName

Balazs Komuves bkomuves at gmail.com
Thu Jun 21 21:10:20 CEST 2012


Hello,

On Tue, Jun 19, 2012 at 6:19 PM, Johan Tibell <johan.tibell at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20120621/f5aa0b13/attachment.htm>


More information about the Libraries mailing list