|
From: Julian S. <js...@ac...> - 2009-04-23 09:41:48
|
Some possibly disjointed comments:
> I think it would be better to separate out the commas at command-line
> processing time, rather than later.
Agree.
> Another idea is to match not the executable name, but rather the entire
> command line, ie. the executable plus the arguments.
This seems like a much more general solution, yes.
> I wonder
> if tracing all children is a better default than tracing no children.
Euh .. I prefer not to do that. You could wind up tracing
a huge tree of processes unexpectedly, if not careful.
How about this. It gives the kind of flexibility you want, whilst
preserving existing behaviour. (remember the kinds of protestation
we've had in the past w.r.t. changing meaning/behaviour of
command line options)
--trace-children=no retained, and is still the default
--trace-children=yes retained, and behaves as present
--skip-children=<command-line-w-wildcards-as-you-suggest>:
(1) when --trace-children=no or is absent, produces a warning that
--skip-children= is irrelevant when --trace-children=no
(2) --trace-children=yes by itself traces all children
(3) --trace-children=yes together with --skip-children= behaves as
you'd expect.
For (1), an alternative would be to declare --trace-children=no
together with --skip-children= as nonsensical, print an error message
and refuse to start. But that would be a nuisance in the case
where I'm doing some kind of weird experiment, and running with
--trace-children=yes --skip-children=...
and then I temporarily switch to
--trace-children=no --skip-children=...
I just want it to continue with a warning; having to delete a potentially
long list of --skip-children= params just because --trace-children=no
would be a drag.
J
|