...

I have a perfectly OK use of getPermissions: in hmake, there is a routine that scans the PATH variable looking for an executable with a given name. Basically, it is a Haskell implementation of the unix 'which' command. There is no actual use of the executable, just a test to report/reject the candidate pathname.

You wouldn't be losing much by using doesFileExist rather than getPermissions.

But on unix, it would be totally incorrect to return a file of the right name but with the wrong permissions. This is what my Haskell `which` originally did, and it bit me hard on a couple of occasions, hence the extra check.

On Windows it turns out to be really hard if not impossible to check for execute permission - the only reliable way is to actually try to execute the file.

Mounting a FAT filesystem on unix (or indeed any filesystem via Samba) also makes all files appear to be executable. These are just broken platforms, and I don't think they should hold us hostage or dictate our preferred API. I'm not saying that the current API is perfect - it could certainly be improved. But I'm just pointing out that there are valid use-cases for what we have currently. If you have concrete suggestions for a new API, I would certainly be interested. Regards, Malcolm

Malcolm Wallace wrote:

...

...

I have a perfectly OK use of getPermissions: in hmake, there is a routine that scans the PATH variable looking for an executable with a given name. Basically, it is a Haskell implementation of the unix 'which' command. There is no actual use of the executable, just a test to report/reject the candidate pathname. You wouldn't be losing much by using doesFileExist rather than getPermissions.

But on unix, it would be totally incorrect to return a file of the right name but with the wrong permissions. This is what my Haskell `which` originally did, and it bit me hard on a couple of occasions, hence the extra check.

...

On Windows it turns out to be really hard if not impossible to check for execute permission - the only reliable way is to actually try to execute the file.

Mounting a FAT filesystem on unix (or indeed any filesystem via Samba) also makes all files appear to be executable. These are just broken platforms, and I don't think they should hold us hostage or dictate our preferred API.

Tempting as it is, I couldn't possibly label Windows as "broken" :-) Since this is supposed to be a portable API, the fact that you can't implement it on certain platforms definitely *should* be an indication that it is the wrong API.

I'm not saying that the current API is perfect - it could certainly be improved. But I'm just pointing out that there are valid use-cases for what we have currently. If you have concrete suggestions for a new API, I would certainly be interested.

One suggestion is to just get rid of this functionality - code that needs to do access-control stuff must use OS-specific APIs. This is arguably the right thing. What we have now is a "best-effort" API: it tries to do something reasonable, but may do something bogus. Some people find this distasteful, but it can be useful at times (as you and others have pointed out). I'm not really convinced one way or the other, which is why I started this RFD. Cheers, Simon

Neil Mitchell wrote:

...

returns True for execute permission on Windows, and the one in GHC 6.8.1 returns True if the filename ends in something like ".exe" or ".bat" (both are wrong, just wrong in different ways).

The GHC one is pretty wrong, since ".com" is also a valid extension for executables.

Um, I said "something like ...". The code in fact is Microsoft's implementation of stat(), in the CRT. The list it uses is: /* see if file appears to be executable - check extension of name */ if (p = _tcsrchr(name, _T('.'))) { if ( !_tcsicmp(p, _T(".exe")) || !_tcsicmp(p, _T(".cmd")) || !_tcsicmp(p, _T(".bat")) || !_tcsicmp(p, _T(".com")) ) uxmode |= _S_IEXEC; } Cheers, Simon