Improve GDB's first user experience by reducing "print_gdb_version" output

Improve GDB's first user experience by reducing "print_gdb_version" output

[Guinevere Larsen via Gdb]

Hi all,

I've been thinking about how to improve the user experience, especially 
for first time users. One thing that stands out to me is the very 
verbose first output a new user is greeted with:

GNU gdb (GDB) 17.0.50.20250526-git
Copyright (C) 2024 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
     <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb)

For the *vast* majority of our users, only 4 of those lines are useful 
at all: the GDB version (to ask for help), where to find the 
documentation, the "help" command, and the "apropos" command. Arguably, 
where to report bugs could be useful, but the worst ones already print 
it and otherwise users are incredibly unlikely to report them 
(especially given the email requirements to create an account). Worthy 
of note, the important lines are the last ones, so even if a new user 
was eager enough to start reading everything, they'd likely gloss over 
everything assuming this entire thing is just copyright.

I propose that the text be updated to something similar to this:

GNU gdb (GDB) 17.0.50.20250526-git
For a list of commands, use "help"
For all commands related to a certain word, use "apropos word"
For a thorough explanation of what GDB can do, check the manual at:
     <http://www.gnu.org/software/gdb/documentation/>
For information on GDB's copyright, warranty or configuration, use
     "show copying/warranty/configuration"
(gdb)

This makes the text smaller, the start is more focused on what most 
users will be interested in, and keeps all the very relevant information 
still available for those interested.

I'm sending this here in case there is some rule that forces us to write 
the copyright or free software status at initialization, before spending 
the time to turn this into a patch.

-- 
Cheers,
Guinevere Larsen
She/Her/Hers

Re: Improve GDB's first user experience by reducing "print_gdb_version" output

[Paul Smith via Gdb]

On Tue, 2025-05-27 at 17:43 -0300, Guinevere Larsen via Gdb wrote:
> I'm sending this here in case there is some rule that forces us to
> write the copyright or free software status at initialization, before
> spending the time to turn this into a patch.

I had remembered that interactive programs should generate copyright
information at startup, but the most I can find in the current GNU
Maintainer's manual is:

> Sometimes a program has an overall copyright notice that refers to
> the whole program. It might be in the README file, or it might be
> displayed when the program starts up. This copyright notice should
> mention the year of completion of the most recent major version; it
> can mention years of completion of previous major versions, but that
> is optional.

https://www.gnu.org/prep/maintain/maintain.html#Copyright-Notices

Which is a "might" not a "should" or "must".

Re: Improve GDB's first user experience by reducing "print_gdb_version" output

[Phi Debian via Gdb]

FWIW lldb produce nothing

$ lldb ./hw
(lldb) target create "./hw"
Current executable set to '/tmp/hw' (x86_64).
(lldb)


One could argue LLVM series is not GNU yet GCC don't produce nothing either
(even with -v)

$ gcc -o hw hw.c
$

Both gdb and gcc produce the COPYRIGHT in their man(1) which IMHO is good
enough.
Why gdb and gcc diverge is a mystery to me.

The proposed minimal greeting is nice, or can be push further with no
greeting at all (like lldb) assuming gdb --help or man gdb would be the
starting point leading to apropos...

Many options are possible, but the very verbose one seems outdated to me,
even emacs don't through copyright things at start up.

Re: Improve GDB's first user experience by reducing "print_gdb_version" output

[Eli Zaretskii via Gdb]

> Date: Wed, 28 May 2025 09:33:09 +0200
> Cc: Guinevere Larsen <guinevere@redhat.com>,
>  "gdb@sourceware.org" <gdb@sourceware.org>
> From: Phi Debian via Gdb <gdb@sourceware.org>
> 
> FWIW lldb produce nothing
> 
> $ lldb ./hw
> (lldb) target create "./hw"
> Current executable set to '/tmp/hw' (x86_64).
> (lldb)
> 
> 
> One could argue LLVM series is not GNU yet GCC don't produce nothing either
> (even with -v)

Unlike GDB, GCC is not an interactive program, so it produces this
information in the output of "gcc --version" and "gcc --help".

> The proposed minimal greeting is nice, or can be push further with no
> greeting at all (like lldb) assuming gdb --help or man gdb would be the
> starting point leading to apropos...

That'd be going too far, IMO.

Re: Improve GDB's first user experience by reducing "print_gdb_version" output

[Guinevere Larsen via Gdb]

On 5/28/25 9:19 AM, Eli Zaretskii wrote:
>> Date: Wed, 28 May 2025 09:33:09 +0200
>> Cc: Guinevere Larsen <guinevere@redhat.com>,
>>   "gdb@sourceware.org" <gdb@sourceware.org>
>> From: Phi Debian via Gdb <gdb@sourceware.org>
>>
>> FWIW lldb produce nothing
>>
>> $ lldb ./hw
>> (lldb) target create "./hw"
>> Current executable set to '/tmp/hw' (x86_64).
>> (lldb)
>>
>>
>> One could argue LLVM series is not GNU yet GCC don't produce nothing either
>> (even with -v)
> Unlike GDB, GCC is not an interactive program, so it produces this
> information in the output of "gcc --version" and "gcc --help".
>
>> The proposed minimal greeting is nice, or can be push further with no
>> greeting at all (like lldb) assuming gdb --help or man gdb would be the
>> starting point leading to apropos...
> That'd be going too far, IMO.
>
Using -q or --quiet already does this, so we already allow this for 
users who would like a completely silent start (I personally have `alias 
gdb='gdb -q'` in my bashrc).

I agree that having this be the default behavior is too far. If 
anything, I'd like to tutorialize GDB a little bit more, and completely 
hiding the helpful parts of the initial message is the opposite of what 
I hope to accomplish.

-- 
Cheers,
Guinevere Larsen
She/Her/Hers

Re: Improve GDB's first user experience by reducing "print_gdb_version" output

[Paul Smith via Gdb]

On Wed, 2025-05-28 at 09:24 -0300, Guinevere Larsen wrote:
> I agree that having this be the default behavior is too far. If 
> anything, I'd like to tutorialize GDB a little bit more, and
> completely hiding the helpful parts of the initial message is the
> opposite of what I hope to accomplish.

Kibitzing over wording details aside, I really like this idea of
cleaning up the intro text to GDB and I hope you are able to get this
change through Guinevere!

Re: Improve GDB's first user experience by reducing "print_gdb_version" output

[Eli Zaretskii via Gdb]

> From: Phi Debian <phi.debian@gmail.com>
> Date: Thu, 29 May 2025 10:45:14 +0200
> 
> On Wed, May 28, 2025 at 2:20 PM Eli Zaretskii <eliz@gnu.org> wrote:
> 
>  > Date: Wed, 28 May 2025 09:33:09 +0200
> 
>  Unlike GDB, GCC is not an interactive program, so it produces this
>  information in the output of "gcc --version" and "gcc --help".
> 
> Ha Ok, I got it, yet I have hard time to find 'interactive program' that emit long copyright thing at start up.
> Looks like editors (vi, emacs) are also exempt of producing such copyright at start up.

Emacs does produce it by default, try "emacs -q" to see that.

Re: Improve GDB's first user experience by reducing "print_gdb_version" output

[Mark Wielaard]

Hi,

On Tue, May 27, 2025 at 05:38:57PM -0400, Paul Smith via Gdb wrote:
> On Tue, 2025-05-27 at 17:43 -0300, Guinevere Larsen via Gdb wrote:
> > I'm sending this here in case there is some rule that forces us to
> > write the copyright or free software status at initialization, before
> > spending the time to turn this into a patch.
> 
> I had remembered that interactive programs should generate copyright
> information at startup, but the most I can find in the current GNU
> Maintainer's manual is

The GPL itself contains the recommendation at the end (after the
actual terms and conditions) in the section "How to Apply These Terms
to Your New Programs". It is even shorter than Guinevere's suggestion,
it recommends outputting just 4 lines:

  If the program does terminal interaction, make it output a short
  notice like this when it starts in an interactive mode:

    <program>  Copyright (C) <year>  <name of author>
    This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
    This is free software, and you are welcome to redistribute it
    under certain conditions; type `show c' for details.

  The hypothetical commands `show w' and `show c' should show the
  appropriate parts of the General Public License.  Of course, your
  program's commands might be different; for a GUI interface, you
  would use an "about box".

Cheers,

Mark

Re: Improve GDB's first user experience by reducing "print_gdb_version" output

[Guinevere Larsen via Gdb]

On 5/28/25 4:44 AM, Mark Wielaard wrote:
> Hi,
>
> On Tue, May 27, 2025 at 05:38:57PM -0400, Paul Smith via Gdb wrote:
>> On Tue, 2025-05-27 at 17:43 -0300, Guinevere Larsen via Gdb wrote:
>>> I'm sending this here in case there is some rule that forces us to
>>> write the copyright or free software status at initialization, before
>>> spending the time to turn this into a patch.
>> I had remembered that interactive programs should generate copyright
>> information at startup, but the most I can find in the current GNU
>> Maintainer's manual is
> The GPL itself contains the recommendation at the end (after the
> actual terms and conditions) in the section "How to Apply These Terms
> to Your New Programs". It is even shorter than Guinevere's suggestion,
> it recommends outputting just 4 lines:

While shorter than my suggestion, it doesn't add any of the helpful 
things that a new user would want to know about GDB specifically, so we 
would need a couple more lines anyway.

Considering that the license says "output a short notice *like* this" 
(emphasis mine), I would imagine we can alter it without trouble. In 
fact, on a first invocation of emacs, I'm greeted with only a screen 
that looks very different to that message, starting by welcoming users, 
offering a tutorial, a guided tour and a link to the manual before 
mentioning copyright or warranty, which is much friendlier to someone 
attempting to learn to use it on their own.

-- 
Cheers,
Guinevere Larsen
She/Her/Hers

>
>    If the program does terminal interaction, make it output a short
>    notice like this when it starts in an interactive mode:
>
>      <program>  Copyright (C) <year>  <name of author>
>      This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
>      This is free software, and you are welcome to redistribute it
>      under certain conditions; type `show c' for details.
>
>    The hypothetical commands `show w' and `show c' should show the
>    appropriate parts of the General Public License.  Of course, your
>    program's commands might be different; for a GUI interface, you
>    would use an "about box".
>
> Cheers,
>
> Mark
>

Re: Improve GDB's first user experience by reducing "print_gdb_version" output

[Florian Weimer via Gdb]

* Mark Wielaard:

> Hi,
>
> On Tue, May 27, 2025 at 05:38:57PM -0400, Paul Smith via Gdb wrote:
>> On Tue, 2025-05-27 at 17:43 -0300, Guinevere Larsen via Gdb wrote:
>> > I'm sending this here in case there is some rule that forces us to
>> > write the copyright or free software status at initialization, before
>> > spending the time to turn this into a patch.
>> 
>> I had remembered that interactive programs should generate copyright
>> information at startup, but the most I can find in the current GNU
>> Maintainer's manual is
>
> The GPL itself contains the recommendation at the end (after the
> actual terms and conditions) in the section "How to Apply These Terms
> to Your New Programs". It is even shorter than Guinevere's suggestion,
> it recommends outputting just 4 lines:

It also contains a rule that if the notice is present, you must not
remove it and distribute the result:

|   An interactive user interface displays "Appropriate Legal Notices"
| to the extent that it includes a convenient and prominently visible
| feature that (1) displays an appropriate copyright notice, and (2)
| tells the user that there is no warranty for the work (except to the
| extent that warranties are provided), that licensees may convey the
| work under this License, and how to view a copy of this License.  If
| the interface presents a list of user commands or options, such as a
| menu, a prominent item in the list meets this criterion.

|    d) If the work has interactive user interfaces, each must display
|    Appropriate Legal Notices; however, if the Program has interactive
|    interfaces that do not display Appropriate Legal Notices, your
|    work need not make them do so.

I don't know what the rules are for removing it upstream.  The logic for
suppressing a similar message in Emacs for subsequent runs is quite
involved.

Thanks,
Florian 

Re: Improve GDB's first user experience by reducing "print_gdb_version" output

[Mark Wielaard]

Hi,

On Fri, May 30, 2025 at 01:22:04PM +0200, Florian Weimer wrote:
> * Mark Wielaard:
> >> I had remembered that interactive programs should generate copyright
> >> information at startup, but the most I can find in the current GNU
> >> Maintainer's manual is
> >
> > The GPL itself contains the recommendation at the end (after the
> > actual terms and conditions) in the section "How to Apply These Terms
> > to Your New Programs". It is even shorter than Guinevere's suggestion,
> > it recommends outputting just 4 lines:
> 
> It also contains a rule that if the notice is present, you must not
> remove it and distribute the result:

It does define the "Appropriate Legal Notices" as the copyright, no
warrenty notice and how to view the license. And they can be collapsed
into one menu/command/option item if a list of them is presented.

> |   An interactive user interface displays "Appropriate Legal Notices"
> | to the extent that it includes a convenient and prominently visible
> | feature that (1) displays an appropriate copyright notice, and (2)
> | tells the user that there is no warranty for the work (except to the
> | extent that warranties are provided), that licensees may convey the
> | work under this License, and how to view a copy of this License.  If
> | the interface presents a list of user commands or options, such as a
> | menu, a prominent item in the list meets this criterion.
> 
> |    d) If the work has interactive user interfaces, each must display
> |    Appropriate Legal Notices; however, if the Program has interactive
> |    interfaces that do not display Appropriate Legal Notices, your
> |    work need not make them do so.
> 
> I don't know what the rules are for removing it upstream.

I don't think there are different rules for up or downstream. You only
have to preserve those lines of the notice that fall under the
"Appropriate Legal Notices".

Cheers,

Mark

Re: Improve GDB's first user experience by reducing "print_gdb_version" output

[Eli Zaretskii via Gdb]

> Date: Tue, 27 May 2025 17:38:57 -0400
> From: Paul Smith via Gdb <gdb@sourceware.org>
> 
> On Tue, 2025-05-27 at 17:43 -0300, Guinevere Larsen via Gdb wrote:
> > I'm sending this here in case there is some rule that forces us to
> > write the copyright or free software status at initialization, before
> > spending the time to turn this into a patch.
> 
> I had remembered that interactive programs should generate copyright
> information at startup, but the most I can find in the current GNU
> Maintainer's manual is:
> 
> > Sometimes a program has an overall copyright notice that refers to
> > the whole program. It might be in the README file, or it might be
> > displayed when the program starts up. This copyright notice should
> > mention the year of completion of the most recent major version; it
> > can mention years of completion of previous major versions, but that
> > is optional.
> 
> https://www.gnu.org/prep/maintain/maintain.html#Copyright-Notices
> 
> Which is a "might" not a "should" or "must".

You can see an example in "emacs -q".

Re: Improve GDB's first user experience by reducing "print_gdb_version" output

[Eli Zaretskii via Gdb]

> Date: Tue, 27 May 2025 17:43:18 -0300
> From: Guinevere Larsen via Gdb <gdb@sourceware.org>
> 
> GNU gdb (GDB) 17.0.50.20250526-git
> Copyright (C) 2024 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Type "show copying" and "show warranty" for details.
> This GDB was configured as "x86_64-pc-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <https://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
>      <http://www.gnu.org/software/gdb/documentation/>.
> 
> For help, type "help".
> Type "apropos word" to search for commands related to "word".
> (gdb)
> 
> For the *vast* majority of our users, only 4 of those lines are useful 
> at all: the GDB version (to ask for help), where to find the 
> documentation, the "help" command, and the "apropos" command. Arguably, 
> where to report bugs could be useful, but the worst ones already print 
> it and otherwise users are incredibly unlikely to report them 
> (especially given the email requirements to create an account). Worthy 
> of note, the important lines are the last ones, so even if a new user 
> was eager enough to start reading everything, they'd likely gloss over 
> everything assuming this entire thing is just copyright.
> 
> I propose that the text be updated to something similar to this:
> 
> GNU gdb (GDB) 17.0.50.20250526-git
> For a list of commands, use "help"
> For all commands related to a certain word, use "apropos word"
> For a thorough explanation of what GDB can do, check the manual at:
>      <http://www.gnu.org/software/gdb/documentation/>
> For information on GDB's copyright, warranty or configuration, use
>      "show copying/warranty/configuration"
> (gdb)

This line is NOT redundant, and conveys important information:

  This GDB was configured as "x86_64-pc-linux-gnu".

Also, why did you decide to change the wording of this line:

  Type "apropos word" to search for commands related to "word".

I think the original wording was good.

Re: Improve GDB's first user experience by reducing "print_gdb_version" output

[Guinevere Larsen via Gdb]

On 5/28/25 8:39 AM, Eli Zaretskii wrote:
>> Date: Tue, 27 May 2025 17:43:18 -0300
>> From: Guinevere Larsen via Gdb<gdb@sourceware.org>
>>
>> GNU gdb (GDB) 17.0.50.20250526-git
>> Copyright (C) 2024 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later
>> <http://gnu.org/licenses/gpl.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.
>> Type "show copying" and "show warranty" for details.
>> This GDB was configured as "x86_64-pc-linux-gnu".
>> Type "show configuration" for configuration details.
>> For bug reporting instructions, please see:
>> <https://www.gnu.org/software/gdb/bugs/>.
>> Find the GDB manual and other documentation resources online at:
>>       <http://www.gnu.org/software/gdb/documentation/>.
>>
>> For help, type "help".
>> Type "apropos word" to search for commands related to "word".
>> (gdb)
>>
>> For the *vast* majority of our users, only 4 of those lines are useful
>> at all: the GDB version (to ask for help), where to find the
>> documentation, the "help" command, and the "apropos" command. Arguably,
>> where to report bugs could be useful, but the worst ones already print
>> it and otherwise users are incredibly unlikely to report them
>> (especially given the email requirements to create an account). Worthy
>> of note, the important lines are the last ones, so even if a new user
>> was eager enough to start reading everything, they'd likely gloss over
>> everything assuming this entire thing is just copyright.
>>
>> I propose that the text be updated to something similar to this:
>>
>> GNU gdb (GDB) 17.0.50.20250526-git
>> For a list of commands, use "help"
>> For all commands related to a certain word, use "apropos word"
>> For a thorough explanation of what GDB can do, check the manual at:
>>       <http://www.gnu.org/software/gdb/documentation/>
>> For information on GDB's copyright, warranty or configuration, use
>>       "show copying/warranty/configuration"
>> (gdb)
> This line is NOT redundant, and conveys important information:
>
>    This GDB was configured as "x86_64-pc-linux-gnu".

Strictly speaking, none of the lines in the introduction are fully 
redundant, they will all be useful in niche situations. My claim is that 
for most users, and especially new users, this reads as visual noise 
that obscures the helpful commands to start using GDB. And worse in this 
specific situation, I would expect that many cases where that knowledge 
would be important, the information would have scrolled off the screen 
and a refresher would be needed either way.

Further thinking about the end goal, it would be good to have an even 
more descriptive message if GDB thinks that this can be an entirely new 
user, which explains more things and would be disabled by adding 
something to a gdbinit, something like "set existing-user 1", and 
explaining what the gdbinit even is. With that, if a user ends up 
finding that knowing the configuration is important, they will be aware 
that they can add "show configuration".

> Also, why did you decide to change the wording of this line:
>
>    Type "apropos word" to search for commands related to "word".
>
> I think the original wording was good.
>
The wording here isn't meant to be taken literally, it was chosen 
quickly to illustrate what kind of changes I had in mind. The quick 
change was just to standardize the suggestions as "for <intended 
outcome>, use <command>", but that detail side of the discussion can be 
left for when a patch making these changes

-- 
Cheers,
Guinevere Larsen
She/Her/Hers