
Johan Tibell wrote:
Hi Heinrich,
On Wed, Jun 20, 2012 at 2:02 AM, Heinrich Apfelmus
wrote: The only trouble I have is that these semantics don't seem to be useful. For what purpose would you like to know the executable path? The only use case that I have encountered is to find data files relative to the program, but in this case, I need it to work equally well in GHCi, runghc and compiled.
The most common use case I can think of is having the binary invoke itself in some way e.g. using execv. The particular use case I have in mind is having the binary copy itself elsewhere (i.e. to another machine) and then execute itself again.
Ah, I see. This use case does not strike me as very common, but I don't think that this is a criterion against inclusion. It may be a good idea to mention the use case in the Haddock documentation, and to point out that running the function in an interpreter context will return the path of the interpreter, just to make it clear what the function can and cannot do. In any case, I'm happy with the proposal now ( getExecutablePath returning precisely the path of the executable). Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com