System.Environment provides no access to argv[0]
The docs for getProgName
say:
Computation getProgName returns the name of the program as it was invoked.
However, this is hard-to-impossible to implement on some non-Unix OSes, so instead, for maximum portability, we just return the leafname of the program as invoked. Even then there are some differences between platforms: on Windows, for example, a program invoked as foo is probably really FOO.EXE, and that is what getProgName will return.
I think the "just return the leafname" part is stupid, because it means there is no way for me to get at C's argv[0]
. How does mangling argv[0]
increase portability? It just makes Haskell incompatible with everything else out there. Also, if your platform has argv[0]
, you might as well return it as-is.
Why do I want argv[0]
at all? Well, the ability to write a drop-in replacement for a C program that does something like fprintf(stderr, "%s: %s: %s\n", argv[0], filename, strerror(errno))
would be nice (where "drop-in" = character for character the same output). My current project is an IRC bot that can restart itself via exec()
, preserving state in its command line arguments. However, I usually don't "install" the bot, I just run it from some directory. In this case argv[0]
would be perfect: if it contains slashes, the bot was run from some directory (and exec()
will find it there); if it doesn't, the executable was found in the path (and exec()
will find that too).
To summarize: I think the inability to get at argv[0] from Haskell is a bug. If you don't want to change getProgName
, please consider adding another function (getNativeProgName
?).
Trac metadata
Trac field | Value |
---|---|
Version | 6.10.2 |
Type | Bug |
TypeOfFailure | OtherFailure |
Priority | normal |
Resolution | Unresolved |
Component | libraries/base |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | |
Operating system | |
Architecture |