Where are the other open flags about unix HOT 11 CLOSED

The design is kind of gross there, I would have newtyped over the int and provided a Monoid instance. That said we're probably stuck with it now. Please send a pull request if you need the other flags (it will require a major version bump).

from unix.

I cannot say much about the other flags, but O_CLOEXEC is important because it is the only way you are guaranteed in the general case not to leak FDs in a multi-threaded program that forks.

from unix.

@gregorycollins If I want to add some things to this, how would I deal with cross-platform compatibility and what platforms to I have to take care of?

Relatedly, this is the intersection of supported O_* flags for Linux and BSD:

O_APPEND
O_CLOEXEC
O_CREAT
O_DIRECT
O_DIRECTORY
O_EXCL
O_NOCTTY
O_NOFOLLOW
O_NONBLOCK
O_SYNC
O_TRUNC

And of those, the following are not implemented in the unix package:

O_CLOEXEC
O_CREAT
O_DIRECT
O_DIRECTORY
O_NOFOLLOW
O_SYNC

from unix.

Also, O_CLOEXEC doesn't seem to be supported on OSX < 10.7, see this Go thread.

from unix.

is there any reason why the alternative monoidal interface couldn't be added?

from unix.

@cartazio how exactly would you suggest doing that w/o breaking backward compatibility?

from unix.

add a new module? :)
something like System.Posix.IO.NG or something?

from unix.

...or just by adding a new open function with a new name.

I think we should deprecate the old style --- as noted on this bug, it doesn't cover all of the available flags, and extending the type or providing platform-specific flags is problematic because you will break pattern-matching if callers do that for some reason. The current API is also wasteful -- six heap allocations and all of those bools have to be walked by openFd. Newtype-over-int will probably get unboxed into a register.

from unix.

thats a better idea :)

from unix.

@gregorycollins If I want to add some things to this, how would I deal with cross-platform compatibility and what platforms to I have to take care of?

Relatedly, this is the intersection of supported O_* flags for Linux and BSD:

O_APPEND
O_CLOEXEC
O_CREAT
O_DIRECT
O_DIRECTORY
O_EXCL
O_NOCTTY
O_NOFOLLOW
O_NONBLOCK
O_SYNC
O_TRUNC

And of those, the following are not implemented in the unix package:

O_CLOEXEC
O_CREAT
O_DIRECT
O_DIRECTORY
O_NOFOLLOW
O_SYNC

unix-2.8.0.0 will have:

data OpenFileFlags =
 OpenFileFlags {
    append    :: Bool,           -- ^ O_APPEND
    exclusive :: Bool,           -- ^ O_EXCL, result is undefined if O_CREAT is False
                                 --
                                 -- __NOTE__: Result is undefined if 'creat' is 'Nothing'.
    noctty    :: Bool,           -- ^ O_NOCTTY
    nonBlock  :: Bool,           -- ^ O_NONBLOCK
    trunc     :: Bool,           -- ^ O_TRUNC
    nofollow  :: Bool,           -- ^ O_NOFOLLOW
                                 --
                                 -- @since 2.8.0.0
    creat     :: Maybe FileMode, -- ^ O_CREAT
                                 --
                                 -- @since 2.8.0.0
    cloexec   :: Bool,           -- ^ O_CLOEXEC
                                 --
                                 -- @since 2.8.0.0
    directory :: Bool,           -- ^ O_DIRECTORY
                                 --
                                 -- @since 2.8.0.0
    sync      :: Bool            -- ^ O_SYNC
                                 --
                                 -- @since 2.8.0.0
 }

O_DIRECT doesn't seem to be part of POSIX: https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/

So I think this can be closed.

from unix.

@hasufell Thank you, that is very useful.

I am very looking forward to the unix-2.8.0.0 release; with #59 in there we will finally have a chance to tack The CLOEXEC problem across the Haskell ecosystem.

Also thanks for your other recent unix efforts!

from unix.