[Haskell-cafe] Re: Hugs vs GHC (again)was: Re: Somerandomnewbiequestions

[Marcin 'Qrczak' Kowalczyk]

Aaron Denney <wnoise at ofb.net> writes:

> Does open("/dev/fd/n") or ("/proc/self/fd/n") act as dup() or a fresh
> open() to underlying file?)

As a dup(), with a side effect of resetting the file pointer to the
beginning.

It would not help anyway: if it's a terminal or pipe, it *has* to act
as a dup() (in this case the file pointer is obviously not reset),
it's not seekable, and thus pread/pwrite fail.

"wc -c" tries to measure the size in bytes by seeking, and proceeds
to actually read the contents only if the file is not seekable (or if
it's also told to count words or lines, obviously). This applies to
stdin too. In this case it must remember to subtract the starting
position from the size (and to bump the result to 0 if it would be
negative), in order to give consistent results whether it manages to
skip reading the contents or not.

> I actually don't see the problem with interacting with other
> processes that we've forked.

File positions are not evil. They allow to treat files and devices
in a uniform way.

If you run a program which
- writes some opening words to stdout
- forks a subprocess, which executes another program, which writes
  something to stdout
- the parent waits for the subprocess to finish
- writes closing words to stdout
then all output will appear in order: the opening words, then the part
from the other program, and finally the closing words. This applies
*also* when stdout has been redirected to a file. In this case it's
essential that the file position is shared between all processes!
So even if stdout is a regular file, output should be done using
write(), not pwrite().

If processes don't synchronize their writes and write at the same
time, then output will be intermixed. They can choose to synchronize
themselves; in particular one process can avoid writing anything while
the other process is running. So it's not true that allowing them to
share a file position will necessarily be unsafe and will risk mangled
data. Unix doesn't guarantee that programs will behave well, but it
allows well-behaving programs to cooperate.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/