Re: [bug-gnulib] system module?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Andreas Büning on 6/22/2006 1:29 PM: However, I thought that this behaviour of system() was common on DOS/Win*/OS/2 systems. system(xcopy non_existing_file) returns 1 for example. That's not a problem, unless: FILE*f; int result; int ch; f = popen(xcopy non_existing_file, r); while ((ch = getc(f)) != EOF); result = pclose(f); returns 256, and if WEXITSTATUS is defined as (status8)0xff. Can someone with mingw access confirm if this system() bug is widespread? I've already checked that cygwin is not affected. Possibly, djgpp for DOS or the MinGW environment for Win* might have the same behaviour which I cannot test because I don't use them. If they do, then I will try to write a module that does an AC_RUN_IFELSE using something similar to the above; compare the results of popen and system on the same command known to fail without producing output, and see if the return values are the same. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEm+Eo84KuGfSFAYARAhhqAJ0Sy8AGeGhQGTdJ9ek5Xn8/V7CsGQCdGSP1 ulSMc2Efc8vdQqkZpYme4FU= =Fl5W -END PGP SIGNATURE-
Re: [bug-gnulib] system module?
Eric Blake asked:
Is it worth adding a system module to gnulib that detects implementations
with
this bug, and provides rpl_system to work around it?
The specification of system() in ISO C 99 does not specify
1) which is the command processor,
and in particular which are the built-in commands and how to quote
arguments when constructing a program incovcation with arguments,
2) how the command is executed (in particular, the signal handling),
3) the return value semantics.
Andreas Büning asks about the third problem, but the first and second are
more important.
Because of 1), I don't think it would be useful for gnulib to provide a
substitute. When a programmer uses the system() command, you don't know
whether he intends to invoke the system's command processor or a /bin/sh
implementation. On Windows: cmd.exe or /bin/sh? On VMS: DCL or sh?
gnulib makes it easy to invoke /bin/sh on all platforms:
execute (sh, /bin/sh, { /bin/sh, -c, command, NULL }, ...)
We cannot provide portability aids for programmers who want to use
cmd.exe or DCL.
Witness of this: GNU clisp offers facilities for invoking programs and
executing commands, but does not use system(). IIRC, it used system()
15 years ago, but
1) the confusion between COMMAND.COM and CMD.EXE on DOS and Windows,
as well as the weird argument quoting rules on Windows, that are
different in CMD.EXE than in CreateProcess,
2) the signal handling on SVR4 systems,
and some additional problem with file descriptors in EMX system(),
made it unpractical to continue using system(). (I don't remember the
details, sorry.)
Bruno
Re: [bug-gnulib] system module?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 6/22/2006 5:37 AM: Eric Blake wrote: Is it worth adding a system module to gnulib that detects implementations with this bug, and provides rpl_system to work around it? How many programs will be ported to OS/2? How active is the EMX-OS/2 community still? Andreas, could you answer this, since you were the one that reported that m4's use of system() broke on your compilation on OS/2? I don't personally have access to OS/2, so I would be relying on your testing to make sure such a module worked, anyways. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEmpX884KuGfSFAYARAmXdAJ97ordxvbdCBwdrElKPpR0yk2WydACgmm9N Pd8M5OGa4G8HPvzkLiFsHYY= =3AVT -END PGP SIGNATURE-
Re: [bug-gnulib] system module?
Eric Blake wrote: According to Bruno Haible on 6/22/2006 5:37 AM: Eric Blake wrote: Is it worth adding a system module to gnulib that detects implementations with this bug, and provides rpl_system to work around it? How many programs will be ported to OS/2? How active is the EMX-OS/2 community still? emx and its successor is the libc that is used by the OS/2 port of gcc. AFAIK, it's basically the only compiler that can handle autoconf/automake-generated configure scripts if this answers your question. However, I thought that this behaviour of system() was common on DOS/Win*/OS/2 systems. At least I also checked MS VC++ on WinXP. Their docs say --- system() Execute a command. int system( const char *command ); [...] Return Value If command is NULL and the command interpreter is found, returns a nonzero value. If the command interpreter is not found, returns 0 and sets errno to ENOENT. If command is not NULL, system returns the value that is returned by the command interpreter. It returns the value 0 only if the command interpreter returns the value 0. A return value of - 1 indicates an error, and errno is set to one of the following values: [...] - system(xcopy non_existing_file) returns 1 for example. Possibly, djgpp for DOS or the MinGW environment for Win* might have the same behaviour which I cannot test because I don't use them. Best regards, Andreas
system module?
Andreas Buening reported that OS/2 violates the CX shading in POSIX 2001 in that the return value of system() is not parseable with WEXITSTATUS: http://www.nabble.com/Re%3A-sysval-and-doc-fixes--was%3A-GNU-M4-1.4.4b-released- %28beta-release%29--t1815393.html#a4961536 In short, on OS/2, waitpid() and pclose() use (status8)0xff, but system() uses status0xff, to represent the low 8 bits returned from main() in the child process. Is it worth adding a system module to gnulib that detects implementations with this bug, and provides rpl_system to work around it? -- Eric Blake
