Re: Possible bug in uname command

[Bob Proulx]

Alfred M. Szmidt wrote:
> They are only non-portable across different operating systems (say
> OpenBSD vs GNU).  My point is that coreutils main goal is not to be
> portable across various operating systems, if `uname -p' outputs
> `unknown' on platforms that can't provide that info, then that is
> fine.

If Hurd implements the interface to enable 'uname -p' then that would
certainly be a good thing in general.  A win-win.  But if it does not
then already at this time 'uname -p' is not really useful to there.

If you are not concerned about portability across systems and are only
concerned about GNU Hurd then it would seem that whether an option is
available or not on another system should not be a concern.

On the other hand I am concerned with portability across different
systems.  And even in the case that I were using it semi-badly I think
this would not be serious breakage.

  case $(uname -z) in # intentionally using bad -z option here
    foo)  echo foo ;;
    bar)  echo bar ;;
    *)  echo unknown uname output handler ;;
  esac

In that case:

  uname: invalid option -- z
  Try `uname --help' for more information.
  unknown uname output handler

That does not seem so bad.  A little noise to prod the author that the
option is not supported and should be handled more appropriately to be
portable to different systems.

In a more than semi-bad case:

  case $(uname -z) in # intentionally using bad -z option here
    foo)  echo foo ;;
    bar)  echo bar ;;
    unknown)  echo unknown uname output handler ;;
  esac

That would break as shown here.

  uname: invalid option -- z
  Try `uname --help' for more information.

But I think it is bad to code in the unknown case here as in this
example.  Probably not going to be really fatal.  But already a
problem today for me to program across systems because already most
systems I work with do not implement -p.  I would need something like
this:

  case $(uname -p 2>/dev/null) in
    sparc)  echo sparc ;;
    *) echo unknown uname output handler ;;
  esac

That should work fine.  At least as well as it does today.

In any case, my goal with my suggestion was only that if something is
not going to be functional and will only serve to intice a lot of bug
reports from users reporting that it is not functional then I think it
is better not to provide it at all and avoid the complaints.

Bob