Re: Strangeness in set command

[Andrew STUBBS <andrew dot stubbs at st dot com>]

Daniel Jacobowitz wrote:
> On Sat, Apr 05, 2008 at 08:12:43PM +0300, Eli Zaretskii wrote:
> > Does anyone object to improving the error message to mention "set
> > variable"?
>
> I don't think it will help; it's just luck you got an ambiguity since
> there are two commands starting with s.  You could get any number of
> other errors, or even silent success.  Like:
>
> (gdb) set ser.a = 1
> Undefined set serial command: ".a = 1".  Try "help set serial".
> (gdb) set args.a = 1
> (gdb) show args
> Argument list to give program being debugged when it is started is ".a = 1".

This has been bugging me for some time. Not just for interactive use, 
but also because it's quite easy to write scripts which work now, but 
might fail unexpectedly in future versions of GDB.

E.g.

(gdb) set index = 1

There's no GDB command "set index", so this sets a program variable, 
which is probably what the user intended. However, can you say for sure 
GDB will never use this name? It's exactly the sort of useful name that 
would find a use, and when it does a script with this command will go wrong.

Perhaps the best solution would be to print an expanded version, thus 
making it explicit what is going on.

E.g.

(gdb) set ser.a = 1
=> set serial .a = 1
Undefined set serial command: ".a = 1".  Try "help set serial".
(gdb) set args.a = 1
=> set args .a = 1
(gdb) show args
Argument list to give program being debugged when it is started is ".a = 1".

(gdb) set index = 1
=> set variable index = 1

I wouldn't recommend printing the command when no expansion is performed 
- that would really annoy me, especially when sourcing scripts - but I 
would suggest extending the feature to commands in scripts. Scripts 
could be silenced simply by making them explicit. This would encourage 
people to future proof their scripts.

Naturally, there would have to be a way to make the messages go away.

Just a thought

Andrew