System.Environment exports:

getProgName :: IO String

maybe System.Posix.ByteString should export a similar function:

getProgName :: IO ByteString

Yeah, that's actually not the same as argv[0], it has the path to the binary stripped. So you can't really use it to restart yourself because you have no way to know what directory the binary was in. It's frustrating because you can see in the source that it's going to some effort to intentionally strip off information that you can't get elsewhere. Anyway, it probably would make sense to have the ByteString version since it's hand-in-hand with getArgs and is a FilePath.

On Mon, Nov 14, 2011 at 12:05, Balazs Komuves wrote:

Unfortunately, there is no standardized way on different unix systems to access the path of the executable running (it's not even fully clear what it means in the presence of symlinks, etc). Actually it seems to be impossible to do this (without argv[0]) on certain BSD systems.

Also note: - argv[0] won't be a full pathname if the program was found via $PATH search - it is possible for users to pass arbitrary argv[0] to the exec() family of system calls - some programs use special argv[0] values (this probably doesn't practically matter), notably shells look for a leading "-" (which is normally provided by "login" or "sshd" etc.) to indicate a login shell that should source ~/.profile etc. - there are various other special cases, such as a number of Unixlikes implementing setuid shell scripts securely by passing a /dev/fd/* reference as argv[0] to avoid symlink attacks. Again, you *probably* don't need to care about this one, but there may be others on various systems. In short, argv[0] should not be relied on as the executable name. (The usual way this is managed is that the real executable is something like foo.real and foo is a shell script which passes in the path to foo.real as a parameter. During installation/configuration the shell script is modified as necessary to provide the correct path.) -- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

On 11/11/2011 20:55, Herbert Valerio Riedel wrote:

On Fri, 2011-11-11 at 16:23 +0000, Simon Marlow wrote:

...

I propose to commit the attached patch to the unix package and release it with GHC 7.4.1. The commit log is reproduced below. Comments please!

+1 :-)

Just one minor thing:

...

- There is a new type: RawFilePath = ByteString

Can't that be made a proper type (e.g. via a newtype) instead of being a mere type-alias?

I'd rather *not* do that: - The unix library doesn't generally make newtypes - take a look at all the other types it exports. - It's a low-level API, abstraction is not the goal here. - We know from the POSIX spec that a path is a sequence of bytes and nothing more. This interface makes that explicit. Cheers, Simon