...

1) what exactly is "fullname" supposed to do in configure?

if fullname 2>>/dev/null # cope with symbolic links in directory

What it says in the comment... :-) If `fullname' is available it gives the absolute pathname to its argument, i.e. it expands symbolic links fully in the directory part.

I can't see this under Solaris either, so the number of systems having it might be limited?

...

Updating targets/ix86-CYGWIN_NT-5.0/hmake3.config... fullname: not found

If your system doesn't have it, it won't be executed. You definitely shouldn't see the `not found' message, because that was redirected to /dev/null.

?? you seem to assume that the redirection affects the executing shell itself, whereas, IMO, it only affects the command. so, if the shell can't find the command, no redirection, and the shell reports the error as usual, no?

Curiously enough, the only reason I introduced `fullname' was because of Cygwin. Remember the business with $(PWD) vs $(shell pwd) in Makefiles (Cygwin requires the latter)? Well in Unix systems, the two forms give different results if there are symbolic links in the directory path. Hence `fullpath' is used as a hack to try to patch up the difference.

I admire everyone who is fighting to smooth over incompatibilities to produce portable systems!-)

No, and if you look closely it isn't the line I wrote either... :-) It actually reads $ grep '^NHC98INCDIR' ...

oops, my bad!

I think I can see how this is failing now. Consider this code:

runAndReadStdout cmd = do ... s <- readFile output removeFile output -- file will not be removed until readFile closes it return (safeinit s) -- strip trailing newline added by shell

I was indeed homing in on that strange artifact (btw, don't you want to force the call to safeinit, so that readFile can complete and removeFile can proceed?).

The file-removal assumes the unix-like property that you can unlink a file while it still has a (lazy) reader attached to it, and the file contents will stick around until the reader has finished with it. It is perfectly possible to create a new (different) file with the same name as the old one whilst the old one is still being read.

Ah, I had almost forgotten about that old magic:) Old wizards used to say: don't use magic for ordinary tasks. It may be cute that it works on real systems, but it isn't really needed here, so why not go for the ordinary, boring way?

Am I right in guessing that the Cygwin filesystem doesn't have these semantics?

Windows doesn't seem to agree with these semantics, so you might not want to run your Haskell-code in plain-Windows hugs/ghc.. Cygwin itself tries to smooth things over, but there seem to be an awful lot of ways that can go wrong. The particular problem most relevant to our case seems to be described here: http://www.cygwin.com/ml/cygwin/2001-07/msg01799.html in other words, the open-unlink-read thing kind of works, but if you then try a write on top of it all (as in the second call to runAndReadStdout), the current unlink hackery doesn't seem to cope (I don't know the details, but one rumour has it that unlinks of open files are simply queued for later removal), which might explain the permission problem. Forcing the call to safeinit, so that output is no longer open via readFile when removeFile is called, should get rid of that? Claus