* Command line utilities argument types.
@ 2007-06-01 19:12 Nurdin Premji
2007-06-01 19:13 ` Phil Muldoon
` (2 more replies)
0 siblings, 3 replies; 7+ messages in thread
From: Nurdin Premji @ 2007-06-01 19:12 UTC (permalink / raw)
To: frysk
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?
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Command line utilities argument types.
2007-06-01 19:12 Command line utilities argument types Nurdin Premji
@ 2007-06-01 19:13 ` Phil Muldoon
2007-06-01 21:33 ` Nurdin Premji
2007-06-01 20:34 ` Nurdin Premji
2007-06-01 21:05 ` Andrew Cagney
2 siblings, 1 reply; 7+ messages in thread
From: Phil Muldoon @ 2007-06-01 19:13 UTC (permalink / raw)
To: Nurdin Premji; +Cc: frysk
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Command line utilities argument types.
2007-06-01 19:13 ` Phil Muldoon
@ 2007-06-01 21:33 ` Nurdin Premji
0 siblings, 0 replies; 7+ messages in thread
From: Nurdin Premji @ 2007-06-01 21:33 UTC (permalink / raw)
To: Phil Muldoon; +Cc: frysk
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Command line utilities argument types.
2007-06-01 19:12 Command line utilities argument types Nurdin Premji
2007-06-01 19:13 ` Phil Muldoon
@ 2007-06-01 20:34 ` Nurdin Premji
2007-06-01 21:05 ` Andrew Cagney
2 siblings, 0 replies; 7+ messages in thread
From: Nurdin Premji @ 2007-06-01 20:34 UTC (permalink / raw)
To: frysk
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?
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Command line utilities argument types.
2007-06-01 19:12 Command line utilities argument types Nurdin Premji
2007-06-01 19:13 ` Phil Muldoon
2007-06-01 20:34 ` Nurdin Premji
@ 2007-06-01 21:05 ` Andrew Cagney
2007-06-02 1:10 ` Nurdin Premji
2 siblings, 1 reply; 7+ messages in thread
From: Andrew Cagney @ 2007-06-01 21:05 UTC (permalink / raw)
To: Nurdin Premji; +Cc: frysk
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Command line utilities argument types.
2007-06-01 21:05 ` Andrew Cagney
@ 2007-06-02 1:10 ` Nurdin Premji
2007-06-09 17:57 ` Nurdin Premji
0 siblings, 1 reply; 7+ messages in thread
From: Nurdin Premji @ 2007-06-02 1:10 UTC (permalink / raw)
To: Andrew Cagney; +Cc: frysk
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Command line utilities argument types.
2007-06-02 1:10 ` Nurdin Premji
@ 2007-06-09 17:57 ` Nurdin Premji
0 siblings, 0 replies; 7+ messages in thread
From: Nurdin Premji @ 2007-06-09 17:57 UTC (permalink / raw)
To: frysk
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.)
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2007-06-08 17:36 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-06-01 19:12 Command line utilities argument types Nurdin Premji
2007-06-01 19:13 ` Phil Muldoon
2007-06-01 21:33 ` Nurdin Premji
2007-06-01 20:34 ` Nurdin Premji
2007-06-01 21:05 ` Andrew Cagney
2007-06-02 1:10 ` Nurdin Premji
2007-06-09 17:57 ` Nurdin Premji
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).