Hi Jim,
> > Or would it be better to separate the pure signal handling and tty cleanup
> > code from the code that looks up the appropriate escape sequences from
> > termlib/termcap, and create a module in gnulib with only the signal handling
> > and tty cleanup code?
>
> I'm happy to use
On Sun, Mar 24, 2019 at 07:23:16PM +0100, Bruno Haible wrote:
> Hi Rich,
>
> > -- it would preclude advance creation of a file actions object which
> > will open or dup onto high fd numbers at a later time after the rlimit
> > has been increased.
>
> This is a highly theoretical use-case, isn't
Hi Rich,
> -- it would preclude advance creation of a file actions object which
> will open or dup onto high fd numbers at a later time after the rlimit
> has been increased.
This is a highly theoretical use-case, isn't it?
If you think POSIX should not specify things the way it does, please
On Sat, Mar 23, 2019 at 09:46:28PM +0100, Bruno Haible wrote:
> The gnulib configure test in m4/posix_spawn.m4, when run on Alpine Linux 3.7,
> determines that the posix_spawn_file_actions_add* functions do not fail as
> expected for an out-of-range file descriptor.
The POSIX "shall fail"
Jim Meyering wrote:
> What do you think about using the existing run-test code when possible,
> but to resort to using that hard-coded list when cross-compiling?
> That way, the code adapts well (at least in some cases) when it finds
> a new type of system for which this is applicable.
Possible.
