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 |