| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
| |
Add ONLCR, OCRNL, ONOCR, ONLRET, OFILL, NLDLY, CRDLY, TABDLY, BSDLY,
VTDLY, and FFDLY.
Closes: https://github.com/haskell/unix/issues/98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Consider `ln` (or any other Unix tool):
$ ln -s file1 file2
$ ls -l file2
lrwxrwxrwx 1 niklas niklas 5 Feb 8 03:09 file2 -> file1
$ ln -s file1 file2
ln: failed to create symbolic link 'file2': File exists
The file name mentioned in the error ("link2") is the one
that *could not be created*, not the content of the pointer.
`createSymbolicLink` got this wrong so far, it would print
file1: createSymbolicLink: already exists (File exists)
which is wrong, this file doesn't already exist.
This commit fixes it.
|
|
|
|
| |
Fixes #76
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
This has the side-effect of making two more modules `Safe`-inferred
|
| |
|
|
|
|
| |
This improves on 2ddf4b2b7bf41f878bc7d8a1afa49126710f524c
|
|
|
|
|
| |
As we don't support Windows, there's no benefit in going via
`__hscore_open()`
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
It's very unlikely the current `unix` code stands any chance of even
remotely work with Hugs...
|
| |
|
|
|
|
|
|
| |
We haven't properly supported Windows for some time now, and we wouldn't
have any way to test anyway, since GHC doesn't support Cygwin anymore
either.
|
|
|
|
|
| |
This avoids incompatible-pointer warnings from the c-compiler when using
`CApiFFI`
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Since the primary purpose of `tcdrain(3)` is to block it makes much more
sense to use a `safe` FFI import.
|
|
|
|
|
|
| |
This follows the scheme suggested in #24
This fixes #55
|
|
|
|
|
|
|
|
|
| |
This all started in e968172cb0c9f4fc653c775faf3ecb661f5b1948 which tried
to get rid of redundant import warnings. But we should rather err on
having to tolerate a few warnings on exotic configurations rather than
breaking a build...
This hopefully fixes #36
|
|
|
|
|
|
|
|
|
|
| |
This patch does not modify the `BaudRate` structure but rather causes
some functions taking a `BaudRate` to throw exceptions on systems which
don't provide `B57600` and/or `B115200`. I'm not totally happy with this
patch yet, but this unbreaks compilation on platforms which don't define
at least of these constants.
This fixes #51
|
| |
|
| |
|
|
|
|
| |
This was forgotten in e14fbe2cb3bbd604dadcc3847882ca37edf548b3
|
|
|
|
|
|
|
|
|
|
|
|
| |
It seems these two signals have not been working since at least
2009. Detection of these signals seems to have never been added to
the configure.ac script and the code guarded by #ifdef then bit-rotted
(the idiom used to handle these signals seems to have been abandoned
for something simpler/better in 2009). This fix simply handles these
signals the same way the other signals are handled in
System/Posix/Signals.hsc.
Closes #30 and #31
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds two new functions in `System.Posix.Unistd`
- `fileAdvise` (aka `posix_fadvise(2)`), and
- `fileAllocate` (aka `posix_fallocate(2)`)
This is based in part on #7 and has been heavily refactored from its
original patch submission by Ricardo Catalinas Jiménez.
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds two new functions in `System.Posix.Unistd`
- `fileSynchronise` (aka `fsync(2)`), and
- `fileSynchroniseDataOnly` (aka `fdatasync(2)`)
This is based on part of #7 and has been heavily refactored from its
original patch submission by Ricardo Catalinas Jiménez.
This also bumps version to 2.7.1.0 as a minor version bump is now needed.
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous code was prone to conflicts with when the platform happens
to expose a `execvpe(3)` implementation in its libc.
This commit renames the internal implementation to `__hsunix_execvpe` as
well as adding an autoconf-detection for the presence of `execvpe(3)`,
in which case `__hsunix_execvpe()` forwards the call to `execvpe(3)`.
Moreover, the code has been cleaned up to remove likely bitrotted CPP
conditionals.
This should fix #22
(This also partially addresses #11 on platforms which have a
libc-provided `execvpe(3)`)
|
|
|
|
| |
Closes #27
|
|\
| |
| | |
`System.Posix.Files.fileAccess` fails inside OS X sandbox
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The issue is that sys/types.h header on Solaris includes somehow
/usr/include/sys/feature_tests.h which tests if _FILE_OFFSET_BITS
is defined and if not, then it defines it to 32 if we're compiling
32 bit code (x86). This is simply wrong since we'd like to have it
defined to 64. The issue is solved by including HsUnixConfig.h first
which defines _FILE_OFFSET_BITS to 64 and feature_tests.h is later
OK with that.
|
| |
| |
| |
| |
| | |
This makes sure we pick up the LFS version of `truncate` in case `off_t`
is affected by CPP defines such as `_FILE_OFFSET_BITS`.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This fixes the FFI imports to use the proper `CLong` type over the
previous incorrect `COff` type, as using the wrong argument type can
cause problems when the `long` and `off_t` types have different size.
Historic note from the manual page:
In glibc up to version 2.1.1, the return type of telldir() was off_t.
POSIX.1-2001 specifies long, and this is the type used since glibc
2.1.2 (released in 1999).
|