On Tue, Jun 19, 2012 at 9:30 AM, Simon Hengel <span dir="ltr"><<a href="mailto:sol@typeful.net" target="_blank">sol@typeful.net</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im HOEnZb">> * we can't implement this reliably,<br>
<br>
</div><div class="im HOEnZb">If I understand correctly the current System.Environment.getProgName can<br>
make this distinction somehow. But from a quick peek at the code, I<br>
can't really tell how it's done.<br></div></blockquote><div><br></div><div>It doesn't. It returns whatever string follows the last / in argv[0]. argv[0] can in theory be anything, including "my hair is on fire." :) See the earlier posts in this thread.</div>
<div><br></div><div>I don't think it's possible to implement this correctly, except if we change how GHC runs scripts (i.e. by setting an environment variable, but if you do that you might as well just check for the environment variable if you want to know if you're running as a script.)</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im HOEnZb">> * the distinction into these three groups doesn't necessarily work for all<br>
> compilers, and<br>
<br>
</div><div class="im HOEnZb">If a compiler does not support script/interactive, it could always<br>
return Binary, right?<br></div></blockquote><div><br></div><div>It might also have some 4th, non-compatible option. Even if it only haves a subset, it forces the programmer to write a pattern match that doesn't make sense (as some of the options can never happen.) getExecutablePath :: IO FilePath doesn't have this problem, as it's always defined.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im HOEnZb">> * the distinction (I assume) isn't useful in most use cases<br>
<br>
</div><div class="im HOEnZb">At this point I would find it useful to define use cases. When I was<br>
looking for that functionality, I wanted to find files relative to a<br>
script. For binaries I use Cabal's support for data files, but this<br>
only works for `cabal install`ed packages.<br></div></blockquote><div><br></div><div>I guess my point is that we cannot implement what you want correctly. We can implement a heuristic that kind-of works most of the time. That's a useful thing to have, but if so as a function built upon a more well-defined getExecutablePath.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im HOEnZb">> I think people who want to use this heuristic are better served by the<br>
> existing executable-path package. What do you think?<br>
<br>
</div><div class="HOEnZb"><div class="h5">I still think that a well-tested, reliable way to do that would be<br>
awesome. I'm not sure how hard it is to get it right, though.<br>
<br>
If we do not support interactive/script, then I think we should at least<br>
use a Maybe instead of `error`.<br></div></div></blockquote><div><br></div><div>getExecutablePath :: IO FilePath</div><div><br></div><div>is always defined. It returns the path to the currently running executable, which is e.g. /bin/ghc in case of a script.</div>
<div><br></div><div>-- Johan</div><div><br></div></div>