Hello Michael, * Michael Grünewald wrote on Fri, Nov 12, 2010 at 09:51:55PM CET: > AC_DEFUN([AC_PROG_ID], > [AC_CACHE_CHECK([for id that handles -g, -u and -n], ac_cv_path_ID, > [ac_cv_path_ID=no > for ac_cv_path_ID_v in id /usr/xpg4/bin/id 'command -p id'; do > if test "$ac_cv_path_ID" = "no"; then > ( $ac_cv_path_ID_v -g && $ac_cv_path_ID_v -g -n && > $ac_cv_path_ID_v -u && $ac_cv_path_ID_v -u -n ) 2>&- 1>&- && > ac_cv_path_ID="$ac_cv_path_ID_v" > fi > done;]) > ID="$ac_cv_path_ID" > AC_SUBST([ID]) > ]) > -8<--- > > Of course, I did not write it all by myself, but copied an existing > macro and modified what seemed to require it. When I tried my > script at my workplace---where I have to use some version of Ubuntu, > the variable `ID' was filled up with the value `no' while the `id' > command passes the test---when I check it at the command line. Redirect standard output and standard error to /dev/null rather than closing them; if you close them the program gets an error when writing to the file descriptor, and those 'id' programs which pass the test are in fact the buggier ones. ;-) The standard Autoconf way to write this would be to use AC_CHECK_PROG or AC_PATH_PROG rather than open-coding it; also, 'command -p' doesn't seem fully portable (despite it being specified by Posix), for example the 'command' builtin of zsh 4.0.6 on AIX 5.1 doesn't accept -p; the external 'command' on that system does, but you can't rely on an external one in practice. Other than that, I'm not aware of portability issues in the 'id' program itself, its usage is specified by Posix as well. Hope that helps. Cheers, Ralf _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
