argus-clients: funny command line parsing

[Carter Bullard]

Hey Wolfgang,
Sorry about the inconvenience, I'll fix the bug today.

I do like some of your suggestions , but remember, our current command
line strategy has evolved over a long time and is trying to do a lot.
But I wouldn't say Argus is using a "self defined, manual coded
command line...", unless you think that of every C program.  We  
basically
use getopt(), which is the standard command line parsing method for
Unix (POSIX and IEEE).  getopt_long, which in the Linux standard  
library,
is not POSIX standard (or at least not today?), and not portable, by  
the way.

So, with regard to the time specification, itself,  you are not too  
unhappy with it?

For points in discussion, I think our biggest deviation is the use of  
"shell like"
strategies for the  -s and -M options.  If we were to use a  
traditional approach
here, we would need to double quote them.  But usually, the choice of  
field
separator is rarely an issue.   You prefer ',' over ' ' ?  I'm not  
sure that ',' is a
good command line character because of what the shell may do with it.
I think space is the better field separator here, but we now are  
falling into the
world of opinion.  Are there other programs that use a comma on the  
command
line?

I used the single '-' as an option terminator because that's what sh 
() used
for 20 years.  GNU, I think, added the '--' as an options terminator,
about what 9-10 years ago, but it also supports '-', because of the sh 
() legacy.

I'll add '--' to the ra* programs as well, but like bash.1, we'll still
need to support '-'.

I think this is a great discusssion, and I do want the tools to be  
good, so
if you feel very strong about it, we should consider getopt_long support
for ra* programs, but after the argus-3.0 release.

Carter


On Sep 20, 2007, at 2:13 PM, Wolfgang Barth wrote:

> Hi,
>
> I've updated my argus-clients to 3.0.0-rc.55. Now my ragraph  
> scripts won't
> work anymore. I think the problem is in the command line argument  
> parsing
> of all argus client:
>
> 1) ra -r argus.log - ip
> => works
>
> 2) ra -r argus.log -t 2007/09/20 - ip
> error: invalid time range startime_t 1190239200 lasttime_t -1
> ra[17563]: 2007-09-20 19:59:47 time syntax error 2007/09/20-ip
>
> It doesn't matter which filter you use, in this case -t eats the  
> following
> '-'. But:
>
> 3)  ra -t 2007/09/20 -r /var/log/argus/argus.log - ip
> => works
>
> If -t 2007/09/20 is followed by another ra-option, -t works as  
> expected.
>
> 4) ra -r argus.log -t 2007/09/20.10-11 - ip
> => works
>
> If -t get a from-to specification, the problem disappears. You should
> terminate parsing an argument for -t if there is a space, not  
> depended of a
> following ra-option.
>
> I don't know why argus uses a self defined, manual coded command line
> parsing and not a standard long getopt routine (with -- as  
> terminator to
> interpreting command line options).
>
> I prefere a common standard syntax like
>
>    ra -s stime,saddr,daddr -r argus.log -- <filter>
>
> or better:
>
>    ra --fields=stime,saddr,daddr --input=argus.log -- 
> filter='<filter spec>'
>
> instead of
>
>   ra -s stime saddr daddr -r argus.log - <filter>
>
> The argus way is much more difficult to parse and harder to debug.
>
> Wolfgang
> -- 
> <wob (at) swobspace de> * http://www.swobspace.de
>