uname -a default options

[Rodney W. Grimes]

> On Wednesday, August 21, 2019, Gordon Bergling <gbergling at gmail.com> wrote:
> 
> > Hi Rod,
> >
> > after reading the POSIX spec [1] I agree that the default options behind
> > ?-a" can not be changed.
> >
> > While reading the source of usr.bin/uname/uname.c I recognized that
> > FreeBSD?s uname is getting its information from sysctl calls. Can you point
> > me to right direction where in sys/ the sysctl ?kern.version? (KERN_VERSION
> > internally) is set?
> >
> > I would like create a small patch that changes ?-v?
> > from "FreeBSD 12.0-STABLE r351343 GENERIC?
> > to ?r351343 GENERIC? for a further discussion.
> 
> 
> Please no. Keep them at the current behavior.

Do you have some rational that the value -v should
contain data that is already in -s and -r?

I do know that -v gets "different" stuff if REPRODUCIBLE build is
turned off, but I do not see the reason to include the values that
are already avaliable in -s and -r.

> >
> > Kind Regards,
> >
> > Gordon
> >
> > [1] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/uname.html
> >
> > > Am 17.08.2019 um 18:16 schrieb Rodney W. Grimes <
> > freebsd-rwg at gndrsh.dnsmgr.net>:
> > >
> > >> On Sat, 2019-08-17 at 15:08 +0200, Gordon Bergling wrote:
> > >>> Hello List,
> > >>>
> > >>> "uname -a" is currently mapping the -a option to ?-mnrsv?, which
> > >>> results in something similar like
> > >>>
> > >>> $ uname -a
> > >>> FreeBSD lion.0xfce3.net <http://lion.0xfce3.net/> 12.0-STABLE FreeBSD
> > >>> 12.0-STABLE r350835 GENERIC  amd64
> > >>>
> > >>> What would you think about reducing the option mapping for ?-a? to ?-
> > >>> vmn? , which would result in a less repetitive version string like
> > >>> the one below.
> > >>>
> > >>> $ uname -vmn
> > >>> lion.0xfce3.net <http://lion.0xfce3.net/> FreeBSD 12.0-STABLE r350835
> > >>> GENERIC  amd64
> > >>>
> > >>> Adapting this would be trivial, but before I hack something together,
> > >>> I would like to get some feedback if such a change would be welcomed?
> > >>>
> > >>> Best regards,
> > >>>
> > >>> Gordon
> > >>>
> > >>
> > >> I think there are likely very many existing scripts in the world that
> > >> parse the output of uname -a and would break if the fields moved around
> > >> or disappeared.
> > >
> > > I agree that we should not change the output of uname -a, for one
> > > it is a POSIX spec'ed command, though I would not expect scripts
> > > to be parsing the output of -a, they should actually invoke the
> > > more specific item(s) they need and parse those, a much less error
> > > prone methods.
> > >
> > > I would however like to note that Linux (or atleast Ubuntu 19.04)
> > > has a man page that -a says "All of the below" and are infact returning
> > > more info than the Posix man page which says -a is -mnrsv
> > >
> > > rgrimes at mgmt:~$ uname -a
> > > Linux mgmt 5.1.0-rc2+ #14 SMP Sun Aug 4 09:23:12 UTC 2019 x86_64 x86_64
> > x86_64 GNU/Linux
> > > rgrimes at mgmt:~$ man uname
> > > rgrimes at mgmt:~$ uname -mnrsv
> > > Linux mgmt 5.1.0-rc2+ #14 SMP Sun Aug 4 09:23:12 UTC 2019 x86_64
> > > rgrimes at mgmt:~$ uname -m
> > > x86_64
> > > rgrimes at mgmt:~$ uname -n
> > > mgmt
> > > rgrimes at mgmt:~$ uname -r
> > > 5.1.0-rc2+
> > > rgrimes at mgmt:~$ uname -s
> > > Linux
> > > rgrimes at mgmt:~$ uname -v
> > > #14 SMP Sun Aug 4 09:23:12 UTC 2019
> > >
> > > FreeBSD:
> > > root {1003}# uname -a
> > > FreeBSD w530a.dnsmgr.net 12.0-RELEASE FreeBSD 12.0-RELEASE r341666
> > GENERIC  amd64
> > > root {1004}# uname -m
> > > amd64
> > > root {1005}# uname -n
> > > w530a.dnsmgr.net
> > > root {1006}# uname -r
> > > 12.0-RELEASE
> > > root {1007}# uname -s
> > > FreeBSD
> > > root {1008}# uname -v
> > > FreeBSD 12.0-RELEASE r341666 GENERIC
> > >
> > > So it is really our -v string that is full of redundant
> > > data that MAY want to be evaluated for trimming.
> > >
> > > --
> > > Rod Grimes
> > rgrimes at freebsd.org
> >
> > _______________________________________________
> > freebsd-hackers at freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
> >

-- 
Rod Grimes                                                 rgrimes at freebsd.org