posix_spawn[p]: Don't execute scripts without '#!' marker through /bin/sh

2020-12-23 Thread Bruno Haible
The posix_spawn implementation in gnulib comes from glibc as of 2008. But in 2011 an important change was done in glibc: Remove the ability to specify a script that does not start with a '#!' marker as executable. Previously this file was /_assumed_/ to be a shell script. Here are 3 patches: - C

posix_spawn: more tests

2020-12-23 Thread Bruno Haible
I've added more unit tests for the posix_spawn and posix_spawnp modules. 2020-12-23 Bruno Haible posix_spawn tests: Add two more tests. * tests/test-posix_spawn-inherit0.c: New file, based on tests/test-posix_spawn-open2.c. * tests/test-posix_spawn-inherit1.c:

Re: Regression in spawni.c on native Windows

2020-12-23 Thread Bruno Haible
Hi, Adrian Ebeling wrote: > in commit 29d55bf8 (Mon Dec 14 2020), const qualifiers were added in > spawn_int.h: > > extern int __spawni (pid_t *pid, const char *path, > const posix_spawn_file_actions_t *file_actions, > const posix_spawnattr_t *attrp, c

Re: port freadahead.c & fseeko.c

2020-12-23 Thread Ron Eggler
On 2020-12-23 5:38 p.m., Bruno Haible wrote: Ron Eggler wrote: I'm attemprting to compile an image for a DIGI UL6 SBC and am getting the following error: ../../m4-1.4.17/lib/freadahead.c: In function ‘freadahead’: ../../m4-1.4.17/lib/freadahead.c:91:3: error: #error "Please port gnulib freadah

Re: port freadahead.c & fseeko.c

2020-12-23 Thread Bruno Haible
Ron Eggler wrote: > I'm attemprting to compile an image for a DIGI UL6 SBC and am getting the > following error: > ../../m4-1.4.17/lib/freadahead.c: In function ‘freadahead’: > ../../m4-1.4.17/lib/freadahead.c:91:3: error: #error "Please port gnulib > freadahead.c to your platform! Look at the defi

Autoconf version number after 2.70

2020-12-23 Thread Paul Eggert
Given the changes being discussed (which seem good ones), I suggest calling the next Autoconf release 2.71 not 2.70.1, as the latter would use a new-to-Autoconf numbering convention that might be more trouble than it's worth. There was little difference (and only a month) between Autoconf 2.66

Re: port freadahead.c & fseeko.c

2020-12-23 Thread Paul Eggert
On 12/23/20 1:56 PM, Ron Eggler wrote: How can I patch these files to work with my platform? Look in your stdio.h (commonly /usr/include/stdio.h), and the files it includes, to see how it defines ungetc etc. Then use that knowledge to update lib/freadahead.c and lib/fseeko.c. It'll require so

port freadahead.c & fseeko.c

2020-12-23 Thread Ron Eggler
Hi, I'm attemprting to compile an image for a DIGI UL6 SBC and am getting the following error: ../../m4-1.4.17/lib/freadahead.c: In function ‘freadahead’: ../../m4-1.4.17/lib/freadahead.c:91:3: error: #error "Please port gnulib freadahead.c to your platform! Look at the definition of fflush, fread

Re: gnulib / autoconf sync

2020-12-23 Thread Bruno Haible
Hi Zack, Here are patches to sync autoconf with gnulib: AC_FUNC_CHOWN chown.m4 -> functions.m4 AC_FUNC_GETGROUPS getgroups.m4 -> functions.m4 AC_FUNC_MBRTOWC mbrtowc.m4 -> functions.m4 AC_TYPE_MBSTATE_T mbstate_t.m4

Re: gnulib / autoconf sync

2020-12-23 Thread Bruno Haible
Zack Weinberg wrote: > It may be wise to > go through all of gnulib's m4 files and see if any others need the > same treatment. (Any m4 file that backports code from the development > series leading up to 2.70 is a candidate.) An m4_version_prereq is only needed for those macros which use Autocon

Re: Request to revert the C version change

2020-12-23 Thread Zack Weinberg
On Sun, Dec 20, 2020 at 12:09 PM Zack Weinberg wrote: > I'm not happy about needing to kludge backward compatibility with the > older std-gnu11.m4 into autoconf 2.70.1 but I'm going to do it. As of commit 2d0f19d84ddb13412382674fd48e6fc5c2875d0e, Autoconf *trunk* should now be backward compatible