Re: [Toybox] RFC: "ps -o ?", "logger -p ?", "kill -s ?"

[Robert Thompson]

It's nice where the "what do I put here?" and the "that particular
argument isn't supported in this version" logic cases can be folded
together.  Just list valid choices for that argument, then terminates
unsuccessfully (non-zero error code, but without the normal "I didn't
understand you" error messages.

It is nice to be able to differentiate between known-unsupported
arguments and unrecognized arguments. '--foo: "x" is not supported in
this version', vs "--foo: unknown argument 'x'. Valid choices are a,
b, c, bar."

As a nice side effect,  the code doesn't need to recognize a special
list-options argument...





On 2/20/18, enh  wrote:
> wasn't that the whole reason behind adding the suggestion to the
> syntax error message?
>
> ps: Missing argument to -o (see "ps --help")
>
> i think the only real problem is the old bug where commands like top
> don't show the -o/-O help from ps. (a quick workaround would be to
> mention the "see also" in the top help.)
>
>
> On Tue, Feb 20, 2018 at 10:43 AM, Rob Landley  wrote:
>>
>>
>> On 02/20/2018 12:15 PM, Rob Landley wrote:
>>> A lot of commands take a list of possible inputs to one of their options,
>>> and
>>> there should be a way to query "what are the inputs". The way qemu does
>>> it is to
>>> let you supply ? as the input (ala "qemu-system-i386 -M ?")
>>>
>>> The problem is ? is a shell wildcard so you have to quote it. Otherwise
>>> it works
>>> _almost_ all the time, and then barfs if you have a single character
>>> filename in
>>> your current directory because the shell swapped it out before running
>>> your command.
>>>
>>> Is there an obvious better api for this?
>>>
>>> Advantages of the qemu approach are A) a certain number of people out
>>> there are
>>> already familiar with this, B) if you see "ps -o ?" even once it's pretty
>>> easy
>>> to guess/remember what it does. Much more so than say "ps -o -".
>>> Disadvantage is
>>> shell wildcard...
>>>
>>> Hmmm...
>>
>> Ah, qemu seems to have noticed the wildcard problem, and changed their
>> recommendation:
>>
>>   $ qemu-system-i386 -M x
>>   qemu-system-i386: -M x: unsupported machine type
>>   Use -machine help to list supported machines
>>
>> Ok, I suppose the magic name "help" is reasonable...?
>>
>> (I could also output the list for any unknown type, but there should be an
>> error
>> message at the top, and then it's not "for i in $(ps -o helo)"; do az $i;
>> done"
>> scriptable.)
>>
>> (One thing I've wondered about is where to _document_ this, and the error
>> message telling you how to get help is the obvious place...)
>>
>> Rob
>> ___
>> Toybox mailing list
>> Toybox@lists.landley.net
>> http://lists.landley.net/listinfo.cgi/toybox-landley.net
> ___
> Toybox mailing list
> Toybox@lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net
>
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] RFC: "ps -o ?", "logger -p ?", "kill -s ?"

[enh]

wasn't that the whole reason behind adding the suggestion to the
syntax error message?

ps: Missing argument to -o (see "ps --help")

i think the only real problem is the old bug where commands like top
don't show the -o/-O help from ps. (a quick workaround would be to
mention the "see also" in the top help.)


On Tue, Feb 20, 2018 at 10:43 AM, Rob Landley  wrote:
>
>
> On 02/20/2018 12:15 PM, Rob Landley wrote:
>> A lot of commands take a list of possible inputs to one of their options, and
>> there should be a way to query "what are the inputs". The way qemu does it 
>> is to
>> let you supply ? as the input (ala "qemu-system-i386 -M ?")
>>
>> The problem is ? is a shell wildcard so you have to quote it. Otherwise it 
>> works
>> _almost_ all the time, and then barfs if you have a single character 
>> filename in
>> your current directory because the shell swapped it out before running your 
>> command.
>>
>> Is there an obvious better api for this?
>>
>> Advantages of the qemu approach are A) a certain number of people out there 
>> are
>> already familiar with this, B) if you see "ps -o ?" even once it's pretty 
>> easy
>> to guess/remember what it does. Much more so than say "ps -o -". 
>> Disadvantage is
>> shell wildcard...
>>
>> Hmmm...
>
> Ah, qemu seems to have noticed the wildcard problem, and changed their
> recommendation:
>
>   $ qemu-system-i386 -M x
>   qemu-system-i386: -M x: unsupported machine type
>   Use -machine help to list supported machines
>
> Ok, I suppose the magic name "help" is reasonable...?
>
> (I could also output the list for any unknown type, but there should be an 
> error
> message at the top, and then it's not "for i in $(ps -o helo)"; do az $i; 
> done"
> scriptable.)
>
> (One thing I've wondered about is where to _document_ this, and the error
> message telling you how to get help is the obvious place...)
>
> Rob
> ___
> Toybox mailing list
> Toybox@lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] RFC: "ps -o ?", "logger -p ?", "kill -s ?"

[Rob Landley]

On 02/20/2018 12:15 PM, Rob Landley wrote:
> A lot of commands take a list of possible inputs to one of their options, and
> there should be a way to query "what are the inputs". The way qemu does it is 
> to
> let you supply ? as the input (ala "qemu-system-i386 -M ?")
> 
> The problem is ? is a shell wildcard so you have to quote it. Otherwise it 
> works
> _almost_ all the time, and then barfs if you have a single character filename 
> in
> your current directory because the shell swapped it out before running your 
> command.
> 
> Is there an obvious better api for this?
> 
> Advantages of the qemu approach are A) a certain number of people out there 
> are
> already familiar with this, B) if you see "ps -o ?" even once it's pretty easy
> to guess/remember what it does. Much more so than say "ps -o -". Disadvantage 
> is
> shell wildcard...
> 
> Hmmm...

Ah, qemu seems to have noticed the wildcard problem, and changed their
recommendation:

  $ qemu-system-i386 -M x
  qemu-system-i386: -M x: unsupported machine type
  Use -machine help to list supported machines

Ok, I suppose the magic name "help" is reasonable...?

(I could also output the list for any unknown type, but there should be an error
message at the top, and then it's not "for i in $(ps -o helo)"; do az $i; done"
scriptable.)

(One thing I've wondered about is where to _document_ this, and the error
message telling you how to get help is the obvious place...)

Rob
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

[Toybox] RFC: "ps -o ?", "logger -p ?", "kill -s ?"

[Rob Landley]

A lot of commands take a list of possible inputs to one of their options, and
there should be a way to query "what are the inputs". The way qemu does it is to
let you supply ? as the input (ala "qemu-system-i386 -M ?")

The problem is ? is a shell wildcard so you have to quote it. Otherwise it works
_almost_ all the time, and then barfs if you have a single character filename in
your current directory because the shell swapped it out before running your 
command.

Is there an obvious better api for this?

Advantages of the qemu approach are A) a certain number of people out there are
already familiar with this, B) if you see "ps -o ?" even once it's pretty easy
to guess/remember what it does. Much more so than say "ps -o -". Disadvantage is
shell wildcard...

Hmmm...

Rob
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net