id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	os	architecture	failure	difficulty	testcase	blockedby	blocking	related
3199	System.Environment provides no access to argv[0]	guest		"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`?)."	bug	closed	normal	6.12.1	libraries/base	6.10.2	wontfix		ndmitchell@…	Unknown/Multiple	Unknown/Multiple		Unknown