Command line utilities argument types.

Command line utilities argument types.

[Nurdin Premji]

I'm going to be refactoring how the command line utilities will parse 
their arguments to make them as unified as possible.

I've identified 4 types of input that can be passed to a command line 
utility: Pids, Core files, a command (executable with options), or nothing.

Here is my interpretation of which command line utilities can take what 
types of arguments.

fcatch: pids, or a command.
fcore: pids.
fhpd: pids, corefiles, a command or nothing.
fstack: pids or cores.
fstep: pids or a command.
ftrace: pids or a command.

Is there anything I'm forgetting, or adding?

Re: Command line utilities argument types.

[Phil Muldoon]

Nurdin Premji wrote:
> I'm going to be refactoring how the command line utilities will parse 
> their arguments to make them as unified as possible.
>
> I've identified 4 types of input that can be passed to a command line 
> utility: Pids, Core files, a command (executable with options), or 
> nothing.
>
> Here is my interpretation of which command line utilities can take 
> what types of arguments.

How would you classify options (like logging and other behavior 
modifiers, like -a for all maps output for fcore)? Or is that not going 
to be touched by this refactor?.

FWIW fcore can take one or many pids, can take logging options and can 
take an optional -a parameter to dump all maps instead of selecting the 
maps based on historical precedence of what to write/what to elide.
Regards

Phil

Re: Command line utilities argument types.

[Nurdin Premji]

This is bug:
<http://sourceware.org/bugzilla/show_bug.cgi?id=3752>

Nurdin Premji wrote:
> I'm going to be refactoring how the command line utilities will parse 
> their arguments to make them as unified as possible.
>
> I've identified 4 types of input that can be passed to a command line 
> utility: Pids, Core files, a command (executable with options), or 
> nothing.
>
> Here is my interpretation of which command line utilities can take 
> what types of arguments.
>
> fcatch: pids, or a command.
> fcore: pids.
> fhpd: pids, corefiles, a command or nothing.
> fstack: pids or cores.
> fstep: pids or a command.
> ftrace: pids or a command.
>
> Is there anything I'm forgetting, or adding?

Re: Command line utilities argument types.

[Andrew Cagney]

Nurdin Premji wrote:
> I'm going to be refactoring how the command line utilities will parse 
> their arguments to make them as unified as possible.
>
> I've identified 4 types of input that can be passed to a command line 
> utility: Pids, Core files, a command (executable with options), or 
> nothing.

Would these be reported using a callback-interface?

>
> Here is my interpretation of which command line utilities can take 
> what types of arguments.
>
> fcatch: pids, or a command.
> fcore: pids.

and corefiles; hey why not, let one edit an existing core.
and for the sake of completion, it could also run a command then dump 
core on entry

> fhpd: pids, corefiles, a command or nothing.
> fstack: pids or cores.
> fstep: pids or a command.
> ftrace: pids or a command.
>
> Is there anything I'm forgetting, or adding?

Andrew

Re: Command line utilities argument types.

[Nurdin Premji]

Phil Muldoon wrote:
> Nurdin Premji wrote:
>> I'm going to be refactoring how the command line utilities will parse 
>> their arguments to make them as unified as possible.
>>
>> I've identified 4 types of input that can be passed to a command line 
>> utility: Pids, Core files, a command (executable with options), or 
>> nothing.
>>
>> Here is my interpretation of which command line utilities can take 
>> what types of arguments.
>
> How would you classify options (like logging and other behavior 
> modifiers, like -a for all maps output for fcore)? Or is that not 
> going to be touched by this refactor?.
>
> FWIW fcore can take one or many pids, can take logging options and can 
> take an optional -a parameter to dump all maps instead of selecting 
> the maps based on historical precedence of what to write/what to elide.
> Regards
>
> Phil
>
I think the idea will be that the refactor will create a parser and 
return it, (probably add the logging options automatically) so utility 
specific options can be added to the parser after. So it won't be 
touching other options.

Re: Command line utilities argument types.

[Nurdin Premji]

Andrew Cagney wrote:
> Nurdin Premji wrote:
>> I'm going to be refactoring how the command line utilities will parse 
>> their arguments to make them as unified as possible.
>>
>> I've identified 4 types of input that can be passed to a command line 
>> utility: Pids, Core files, a command (executable with options), or 
>> nothing.
>
> Would these be reported using a callback-interface?
>
That is a great idea. I will use 3 callbacks to notify of pids, cores, 
and commands.
I'm thinking
parsePid (ProcId pid)
parseCore (File core)
parseCommand (String[] command)

I don't know whether the first two should return a single pid/core and 
be called once for every pid/core found or arrays of pid/cores and only 
be called once. The third callback would only ever be called once.

Re: Command line utilities argument types.

[Nurdin Premji]

Nurdin Premji wrote:
> Andrew Cagney wrote:
>> Nurdin Premji wrote:
>>> I'm going to be refactoring how the command line utilities will 
>>> parse their arguments to make them as unified as possible.
>>>
>>> I've identified 4 types of input that can be passed to a command 
>>> line utility: Pids, Core files, a command (executable with options), 
>>> or nothing.
>>
>> Would these be reported using a callback-interface?
>>
> That is a great idea. I will use 3 callbacks to notify of pids, cores, 
> and commands.
> I'm thinking
> parsePid (ProcId pid)
> parseCore (File core)
> parseCommand (String[] command)
>
> I don't know whether the first two should return a single pid/core and 
> be called once for every pid/core found or arrays of pid/cores and 
> only be called once. The third callback would only ever be called once.
I have extended CommandLineParser in frysk.util to do the above, with 
callbacks parsePids(ProcId[] pids) parseCores(File[] coreFiles) and 
parseCommand(String[] command).

A CommandLineParser will call only one of these three callback 
functions. (There is no mixing of pids with cores withs commands.)