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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 20713 in the body.
You can then email your comments to 20713 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Karl Berry <karl <at> freefriends.org>
To: bug-automake <at> gnu.org
Subject: aclocal/tar.m4 and solaris 5.10
Date: Mon, 1 Jun 2015 21:02:32 GMT

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).

Clearly nothing critical.  Just reporting ...

Best,
Karl

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

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

From: Karl Berry <karl <at> freefriends.org>
To: vapier <at> gentoo.org
Cc: 20713 <at> debbugs.gnu.org
Subject: Re: aclocal/tar.m4 and solaris 5.10
Date: Mon, 21 Feb 2022 16:26:34 -0700

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

I guess it couldn't hurt, although I doubt it makes any difference in
practice.

    if test $am_uid = "unknown"; then

Don't we usually avoid quoting constant strings? I.e.:
if test "$am_uid" = unknown; then

      AC_MSG_WARN([ancient id detected; assuming current UID is ok, but dist-ustar might not work])

"Might"? Either it works or it doesn't? Anyway, who ever uses ustar?
Never seen it.

Anyway, seems like such a warning "might" be useful when producing an
archive with automake (running make dist), but not when running
configure. When merely doing "./configure && make", ustar is irrelevant.

Anyway #2, I think the chances of someone wanting to produce a ustar
archive on a system with old id is zero.

Thus I suggest just fixing the syntax stuff and letting it go at that. 

    the point of the checks isn't just to annoy the user.

No :)? That's what it seems like. Helpful to the package developer;
annoyance to the configure user. -k

Message #18 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 19:57:30 -0500

[Message part 1 (text/plain, inline)]

On 21 Feb 2022 16:26, Karl Berry wrote:
>     should we change "unknown" to $GID & $UID respectively ?
> 
> I guess it couldn't hurt, although I doubt it makes any difference in
> practice.

i feel like you just accidentally wrote Automake's motto :p

>     if test $am_uid = "unknown"; then
> 
> Don't we usually avoid quoting constant strings? I.e.:
> if test "$am_uid" = unknown; then

tbh, i have no idea what the quoting style/preference is in the GNU world,
if there actually is one.  i know i see plenty of underquoting, and plenty
of odd `test` styles that aren't well documented (like using the "x" prefix
to avoid testing empty strings).

>       AC_MSG_WARN([ancient id detected; assuming current UID is ok, but dist-ustar might not work])
> 
> "Might"? Either it works or it doesn't? Anyway, who ever uses ustar?
> Never seen it.

we won't know whether it works until we actually try to create an archive.
and depending on the system, that might be too late (see below).

> Anyway, seems like such a warning "might" be useful when producing an
> archive with automake (running make dist), but not when running
> configure. When merely doing "./configure && make", ustar is irrelevant.

sure, but we don't probe tools during `make dist`, we do it during configure

> Anyway #2, I think the chances of someone wanting to produce a ustar
> archive on a system with old id is zero.
> 
> Thus I suggest just fixing the syntax stuff and letting it go at that. 

ustar might not be the most common nowadays.  i think there's merit to
issuing a warning so we aren't in the situation of people reporting bugs
that `make dist` threw a weird error they don't understand, and if their
system was in such a bad state, why weren't they warned about it ?  in
fact, isn't that what led to these checks in the first place ?  we have
reports from users:
https://bugs.gnu.org/8343
https://bugs.gnu.org/13588

>     the point of the checks isn't just to annoy the user.
> 
> No :)? That's what it seems like. Helpful to the package developer;
> annoyance to the configure user. -k

configure user can (re)create dist tarballs too.  not the common flow, but
it can be helpful when you're hacking on a system and want to pull the state
back out.  or when trying to comply with the GPL requirements :).

the reason your system hit this code path is because it wasn't able to handle
the formats earlier in the list (gnutar in this case).
-mike

[signature.asc (application/pgp-signature, inline)]

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

From: Karl Berry <karl <at> freefriends.org>
To: vapier <at> gentoo.org
Cc: 20713 <at> debbugs.gnu.org
Subject: Re: aclocal/tar.m4 and solaris 5.10
Date: Tue, 22 Feb 2022 16:29:18 -0700

    i have no idea what the quoting style/preference is in the GNU world,

Nothing GNU-wide, but among autotools and related packages
written/maintained by approximately the same group of people, I believe
  test x"$foo" = x1
is the most-usual style. Though "x$foo" is common too,
since it makes no difference.

The "test" item, most of the way down in the "Limitations of Shell
Builtins" node of the Autoconf manual, reports a lot of the things that
have led to the common forms/workarounds.
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Limitations-of-Builtins.html#Limitations-of-Builtins

Not including the not-quoting of constant strings though, granted,
since that also makes no difference.

I can't recall any other style guide for shell coding conventions, either.


Anyway, back to the bug topic.

    i think there's merit to issuing a warning 

Ok, I yield. No appetite to argue further over this tiny issue.

    configure user can (re)create dist tarballs too.  not the common flow, 
    
Quite an understatement there :).

    the reason your system hit this code path

I was not running make dist. I was just running configure on Solaris 5.10.
As far as I can recall.

   it can be helpful when you're hacking on a system and want to pull
   the state back out.
    
Personally, I would never trust make dist not to alter the state
that it was supposedly snapshotting. But whatever. --thanks, karl.

Message #24 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: Wed, 23 Feb 2022 00:39:38 -0500

[Message part 1 (text/plain, inline)]

On 22 Feb 2022 16:29, Karl Berry wrote:
> The "test" item, most of the way down in the "Limitations of Shell
> Builtins" node of the Autoconf manual, reports a lot of the things that
> have led to the common forms/workarounds.
> https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Limitations-of-Builtins.html#Limitations-of-Builtins

thanks, this is what i was looking for.  maybe i should actually read the
autotools manuals one day instead of using them purely as references.

>     the reason your system hit this code path
> 
> I was not running make dist. I was just running configure on Solaris 5.10.
> As far as I can recall.

i'm sure that was the case (i.e. you ran configure but never dist).  but if
we can only test tools during configure, and the dist step requires results
from that probing, but we're not allowed to probe dist-specific tools during
configure, then we're in a bit of a catch-22.

i'm not aware of other parts being delayed/split based on their usage.  for
example, if i just `make && make install`, one could argue that configure
checking for deps/behaviors that only matter to `make check` are incorrect.

off the top of my head, i think Automake's `missing` tool is about the only
exception to this approach/rule, and even then, that's pretty thin -- it's
only seeing if a specific program exists, not whether it supports specific
functionality or is otherwise buggy.

>    it can be helpful when you're hacking on a system and want to pull
>    the state back out.
>     
> Personally, I would never trust make dist not to alter the state
> that it was supposedly snapshotting.

to be clear, when i said "state", i meant "the source code".  obviously i
wouldn't expect (or want) `make dist` to pick up any intermediates or build
outputs.  i'm not sure along what lines your distrust of dist flows, but i
will point out that this logic is entirely Automake's, so it would be a
little unusable if you consider `make dist` unreliable as a maintainer of
Automake :).
-mike

[signature.asc (application/pgp-signature, inline)]

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

From: Karl Berry <karl <at> freefriends.org>
To: vapier <at> gentoo.org
Cc: 20713 <at> debbugs.gnu.org
Subject: Re: aclocal/tar.m4 and solaris 5.10
Date: Wed, 23 Feb 2022 14:47:58 -0700

    if we can only test tools during configure, and the dist step
    requires results from that probing ...

Fair enough. Patch is fine on that basis. --thanks, karl.

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

From: Dagobert Michelsen <dam <at> opencsw.org>
To: Karl Berry <karl <at> freefriends.org>
Cc: 20713 <at> debbugs.gnu.org
Subject: Re: bug#20713: aclocal/tar.m4 and solaris 5.10
Date: Thu, 24 Feb 2022 08:35:23 +0100

Hi Karl,

Am 01.06.2015 um 23:02 schrieb Karl Berry <karl <at> freefriends.org>:
> 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

This is a long-standing issue on Solaris and the fix I use is prepending /usr/xpg4/bin
to PATH as there are multiple versions of id installed by default as documented in id(1m).


Best regards

  — Dago

-- 
"You don't become great by trying to be great, you become great by wanting to do something,
and then doing it so hard that you become great in the process." - xkcd #896

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

From: Karl Berry <karl <at> freefriends.org>
To: dam <at> opencsw.org
Cc: 20713 <at> debbugs.gnu.org
Subject: Re: bug#20713: aclocal/tar.m4 and solaris 5.10
Date: Thu, 24 Feb 2022 15:19:24 -0700

Hi Dagobert - thanks. I'm aware of /usr/xpg4/bin. But automake should at
least not fail unexpectedly, hence my report. I think Mike's patch will
suffice. --cheers, karl.

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

From: Mike Frysinger <vapier <at> gentoo.org>
To: 20713 <at> debbugs.gnu.org
Subject: [PATCH] m4: handle id failures when checking ustar support
Date: Thu, 24 Feb 2022 22:23:34 -0500

Fixes automake bug https://bugs.gnu.org/20713.

If `id` fails, display a specific warning message to the user.

* m4/tar.m4: Check $am_uid & $am_gid if they're unknown.
---
 m4/tar.m4 | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/m4/tar.m4 b/m4/tar.m4
index 7e3df4f98e1c..8f4d2f21394b 100644
--- a/m4/tar.m4
+++ b/m4/tar.m4
@@ -46,15 +46,19 @@ m4_if([$1], [v7],
       am_uid=`id -u || echo unknown`
       am_gid=`id -g || echo unknown`
       AC_MSG_CHECKING([whether UID '$am_uid' is supported by ustar format])
-      if test $am_uid -le $am_max_uid; then
-         AC_MSG_RESULT([yes])
+      if test x$am_uid = xunknown; 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
+        AC_MSG_RESULT([no])
+        _am_tools=none
       fi
       AC_MSG_CHECKING([whether GID '$am_gid' is supported by ustar format])
-      if test $am_gid -le $am_max_gid; then
-         AC_MSG_RESULT([yes])
+      if test x$gm_gid = xunknown; then
+        AC_MSG_WARN([ancient id detected; assuming current GID is ok, but dist-ustar might not work])
+      elif test $am_gid -le $am_max_gid; then
+        AC_MSG_RESULT([yes])
       else
         AC_MSG_RESULT([no])
         _am_tools=none
-- 
2.34.1

Previous Next

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