extend verbose output also into the kernel information, using what @kevans recommended for the running_version() too.

egypcio@tak:~ % freebsd-version 
14.0-CURRENT
egypcio@tak:~ % freebsd-version -ruv
14.0-CURRENT 1400063
14.0-CURRENT 1400063

print out verbose information, but not a long line (with build date) like it was before.

egypcio@tak:~ % freebsd-version -k
14.0-CURRENT
egypcio@tak:~ % freebsd-version -kv
FreeBSD 14.0-CURRENT #0 main-n256697-b691e485bda5

so, the above output is based on what's output from:

egypcio@tak:~ % what -qs /boot/kernel/kernel
FreeBSD 14.0-CURRENT #0 main-n256697-b691e485bda5: Fri Jul 15 09:59:10 UTC 2022

See also PR#265789, it would help if

freebsd-version -rku and -kru did not print the same regardless of the sequence of CLI arguments.

So if some patch for that would be added to this review, that would be very helpful.

In D27318#821022, @pi wrote:

See also PR#265789, it would help if

freebsd-version -rku and -kru did not print the same regardless of the sequence of CLI arguments.

So if some patch for that would be added to this review, that would be very helpful.

thanks for sharing the though!

I shared the link to the Phabricator on that Bugzilla ticket really to get more inputs here, and see what others think about it.

IMHO I do not believe that changing the order will be much of a big help here - but that's just me.

In D27318#821022, @pi wrote:

See also PR#265789, it would help if

freebsd-version -rku and -kru did not print the same regardless of the sequence of CLI arguments.

So if some patch for that would be added to this review, that would be very helpful.

I'd keep them separate, personally.

thanks for accepting this revision @pauamma
we shall just get an OK from @gbe and/or @kevans and this is good to be committed. right?

In D27318#821074, @egypcio wrote:

thanks for accepting this revision @pauamma
we shall just get an OK from @gbe and/or @kevans and this is good to be committed. right?

Yep, forgot to mention that.

In D27318#821420, @kevans wrote:

Thanks!

Approved by: kevans (src)

I would like to get back to these changes in a very few and propose a slightly minor change.

what would you folks think about the following output?

% freebsd-version -urkv
14.0-CURRENT main-n256697-b691e485bda5 kernel_version
14.0-CURRENT 1400063 running_version
14.0-CURRENT 1400063 userland_version

ONLY the verbose output would be impacted by that.

thoughts? I would be happy to change it all to fit this kind of format (which I believe can benefit scripting the proposed changes to get verbose information).

I would need an approval from src once again (@des @gbe @kevans );
considering an implicit approval from doc - as the final diff presented here didn't touch any manpage since their last approval.

Please, can you provide a full diff?

https://docs.freebsd.org/en/articles/committers-guide/#phabricator ▶ https://wiki.freebsd.org/Phabricator#Create_a_Revision_via_Web_Interface, for example. Thanks.

I'm sorry, but... why? freebsd-version(1) was never intended for human consumption, it was intended for use by configure scripts, installers, etc. Adding -j was bad enough, I'm sorry I didn't catch it in time (I suppose it's too late to remove it). If you want the kind of information -v would give you, use uname instead.

In D27318#821873, @des wrote:

I'm sorry, but... why? freebsd-version(1) was never intended for human consumption, it was intended for use by configure scripts, installers, etc. Adding -j was bad enough, I'm sorry I didn't catch it in time (I suppose it's too late to remove it). If you want the kind of information -v would give you, use uname instead.

hello there! thanks for the inputs, much appreciated.

the "never intention" to make freebsd-update(1) be consumed by humans got pretty lost these days, if I may flag that. really.
it's used by folks troubleshooting issues, and share FreeBSD's version information (and many other use cases: eg.: from a simple Nagios monitoring script, to a more complex update routine or a status report script).

recently the following Bugzilla ticket brought more attention to this differential review (and we are trying to fix at least a few of the raised issues):

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265594

regarding the mention about uname(1): folks tend to use it without adding the -U and/or -K options to it; they probably only get the "usual" uname -a output, which would not report the OSVERSION/OSRELDATE.

we are also providing a clean output right away -- different from what (e.g.) uname -abiUK would produce. so: this changes here into freebsd-version(1) would also make easier to parse/use/read.

we are using uname(1) with a proper argument to add this proposed improvement into freebsd-version(1). this will pretty much, IMHO, solve folks' problems to get a more detailed information about FreeBSD's version on their boxes.

that's my input to your "why?" question.

ping @kevans (or anyone else from src)?
mind to have a look again, to maybe approve it after all changes got applied; it should be ready-to-go.

In D27318#827073, @egypcio wrote:

ping @kevans (or anyone else from src)?
mind to have a look again, to maybe approve it after all changes got applied; it should be ready-to-go.

ping? anyone.

The ^12 thing is concerning...
Otherwise I think it looks good.

any new inputs about it? shall we finally land the patch?

CC: @kevans

ping;

• manpages, @gbe @pauamma
• src, @imp @kevans

In D27318#855240, @bcr wrote:

OK from manpages for these latest changes. Thanks for your patience working on this patch!

thank you Benedict. much appreciated!

ping

ping @src

hello folks,

I will ask this with all due respect:

• am I touching some sort of "prestige object" here on the FreeBSD base, that a very reserved (closed?) group of people is allowed to handle?
• should that be the case, please take the crown or lights out of me, "steal" the diff and allow the other developers commit it;

maybe the same kind of situation is targeting https://reviews.freebsd.org/D36241 ?

it's a huge frustration surprise to see these two revisions to improve FreeBSD base tools being "blocked" for more than 2 and a half years (total);
considering that they are simple and small changes/patches, with proper documentation and detailed information added to the src and manpages.

both updates motivated by https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265594

CC: @rwatson

You seem to want to see some sort of conspiracy in this situation but have you considered the possibility that nobody wants to approve this review simply because _it's bad_?

a) I'm not convinced the change is needed
b) I'm not even sure I understand what it's supposed to do because the description you added to the manual page does not match what the code does
c) The code does not work as intended

also,

d) I'm sorely tempted to remove the -j option which flies in the face of the intent of this script, should never have been added, and would not have been approved if I had been consulted.

finally 2 cents of review here after a long time hiatus! thank you @des

In D27318#910362, @des wrote:

You seem to want to see some sort of conspiracy in this situation but have you considered the possibility that nobody wants to approve this review simply because _it's bad_?

I seek or want to see no conspiracy here; on top of that, the review (and its patched code+documentation) was approved before -- and improved after suggestions/recommendations from those involved.

should you consider it bad like that, bringing the points into discussion is much appreciated;
shall all agree that's just bad, reject it. happy to not reproduce what happened with those "wireguard implementations" that happened in the past :3

if not, we could merge it. others that shared input and approved the review before do see the benefits of this change.

a) I'm not convinced the change is needed

mind to share a little more input here? did you understand the main motivation, at least?

I believe that the tl;dr; here would be: "instead of using uname -KU it will be possible to simply run freebsd-version -v and give new users a clear view of the exact version they are running"

the verbose version information can be used to compare changes tracked by https://docs.freebsd.org/en/books/porters-handbook/versions/

b) I'm not even sure I understand what it's supposed to do because the description you added to the manual page does not match what the code does

how is that not clear enough?
the title of this review is not the same (detailed) information added to the man page, and that text was reviewed and approved already

c) The code does not work as intended

mind to explain how did you test it and how others can reproduce that?

also,

d) I'm sorely tempted to remove the -j option which flies in the face of the intent of this script, should never have been added, and would not have been approved if I had been consulted.

that's a different subject; we are not touching that piece of code here on this review.