Skip to content

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
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information