GNU bug report logs - #20713
aclocal/tar.m4 and solaris 5.10 where `id -u` is not supported

Previous Next

Package: automake;

Reported by: Karl Berry <karl <at> freefriends.org>

Date: Mon, 1 Jun 2015 21:03:02 UTC

Severity: normal

Tags: confirmed

Done: Mike Frysinger <vapier <at> gentoo.org>

Bug is archived. No further changes may be made.

Full log


Message #12 received at 20713 <at> debbugs.gnu.org (full text, mbox):

From: Mike Frysinger <vapier <at> gentoo.org>
To: Karl Berry <karl <at> freefriends.org>
Cc: 20713 <at> debbugs.gnu.org
Subject: Re: aclocal/tar.m4 and solaris 5.10
Date: Mon, 21 Feb 2022 04:52:47 +0000 (UTC)
On Mon, 01 Jun 2015 21:02:32 +0000, Karl Berry wrote:
> Running a configure script on solaris 5.10 generated with automake-1.15,
> I got these errors about id, which being pre-POSIX, does not support -u:
>
>       id: illegal option -- u
>       Usage: id [-ap] [user]
>       id: illegal option -- g
>       Usage: id [-ap] [user]
>       checking whether UID 'unknown' is supported by ustar format... ./configure: line 4190: test: unknown: integer expression expected
>       no
>       checking whether GID 'unknown' is supported by ustar format... ./configure: line 4200: test: unknown: integer expression expected
>       no
>
> It comes from aclocal-1.15/tar.m4, which says:
>       ... Errors in the 'id' calls
>       # below are definitely unexpected, so allow the users to see them
>
> Well, they are not "unexpected" on this system, so it's not especially
> helpful to see them.  Still, I suppose it is not worth worrying about.
> And I'm sure it is not worth parsing the output of this old id (with no
> args passed) to get the info, but for the record, that would be:
> uid=1053(karl) gid=1053(karl)
>
> But what I do think would make sense is to avoid the subsequent error of
> using a numeric test expression on a known non-numeric (the string
> "unknown") when id fails.  After all, that much is tar.m4's own doing.
> Perhaps simply change
>   if test $am_uid -le $am_max_uid; then
> to
>   if test $am_uid != unknown && test $am_uid -le $am_max_uid; then
> (and ditto gid).

should we change "unknown" to $GID & $UID respectively ?

if the `id` call fails, seems like we could at least still issue a warning.
the point of the checks isn't just to annoy the user.

if test $am_uid = "unknown"; then
  AC_MSG_WARN([ancient id detected; assuming current UID is ok, but dist-ustar might not work])
elif test $am_uid -le $am_max_uid; then
  AC_MSG_RESULT([yes])
else
  AC_MSG_RESULT([no])
  _am_tools=none
fi
-mike




This bug report was last modified 3 years and 128 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.