argus-clients: funny command line parsing

[Carter Bullard]

Hey Wolfgang,
I fixed all things and uploaded argus-clients...rc.56...

I implemented your ',' field separator for the -s option to see if it
will break anywhere, so give it a test run.  Support on both the
command line and in the .rarc file.  If it is working well,
without any shell effects,  we can state that that is the preferred
method in the docs.  We will survive poor uses of the comma,
so
    ra -s saddr, sport, dir, daddr, dport, pkts, bytes -S localhost  
-- ip

will work, on most machines, if not all.  Works for ',' and ':' as field
separators.

I took the time to make 'timespec - timespec' work correctly, and to
support a double quoted version, which interestingly didn't work as
expected.

And the "--" as a terminator for all the parameters is now in, official.

ragraph may not understand this format yet, but it may. Didn't have
time to test.

Carter


On Sep 21, 2007, at 12:59 PM, Wolfgang Barth wrote:

> Hey Carter,
>
> long discussion ;-)
>
> I'm starting ra clients from shell: bash, formerly tcsh, csh, ksh.  
> And you?
> In most shells the space character is a separator for arguments on the
> command line. So things like
>
>   -s a b c d
>
> is not really parsable by getopt functions, so you have to write  
> your own
> code. With getopt and similar functions, you can write
>
>  -s "a b c d"
>
> or use other non-shell interpreted separators like ',', or ':'.  
> Enclosing
> an argument with " causes trouble in some shells, if one script calls
> another (it funny with csh or tcsh and could end in something like \ 
> \\\" ).
>
>> 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.
>
> You should not change the behaviour quickly, but think about a  
> second way.
> At this time you use the strategie
>
>   one option, may be a lot of option arguments
>
> In my humble opinion
>
>   one option, one option argument
>
> on the command line would be much clearer. If you have problems  
> with ',' as
> separator in option arguments, you can use ':', or other chars  
> which most
> shells would not interpret. What I would say with my last email is
>
>   using shell separators like space as separator for option arguments
>   causes the most trouble in programming and debugging code.
>
>> But I wouldn't say Argus is using a "self defined, manual coded
>> command line...", unless you think that of every C program.  We
>
> Sorry for some irritations, english is not my native language ;-)  
> What I
> mean is the way you are using getopt. What I have learned is
>
>   1) getopt is parsing all options with arguments
>   2) the rest is for the program
>
> 1) only works clearly if the shell passes one argument to one  
> option. At
> this time, you have to store a current argument an look after what is
> coming next. This cannot be done by getopt standalone.
>
> And sorry, I'm not a real C programmer, mostly a Perl hacker, and I  
> love
> the elegance of combinating modules like Getopt::Long, Pod::Usage  
> and such
> things. So I don't know what POSIX means in the real programming  
> world and
> I have no clue of writing portable programs ;-)
>
>> So, with regard to the time specification, itself,  you are not too
>> unhappy with it?
>
> If you did not allow spaces in the time specification, this would  
> be ok. If
> you did, you get problems with things like -t 09/20 - 09/21: so  
> what means
> '-' at this time? Thats the current problem.
>
>> separator is rarely an issue.   You prefer ',' over ' ' ?  I'm not
>> sure that ',' is a
>
> If you follow the one-option-one-argument strategie, you can go on  
> with
> ' ' if we enclose the whole argument with "". But if you think about
> supporting the old and a new strategie in parallel, this can cause
> irritations by the users.
>
>> 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.
>
> You are the programmer, it's primarily your choice.
>
>> I used the single '-' as an option terminator because that's what sh
>> () used for 20 years.
>
> Okay, the problem is not '--', but the wrong code for parsing the time
> specification.
>
>> I'll add '--' to the ra* programs as well, but like bash.1, we'll  
>> still
>> need to support '-'.
>
> It would be great, if you can add -- as option terminator.
>
>> 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.
>
> Don't change such basics in argus-3.0. This can wait for a future  
> version.
> May be we can choice the strategie in future versions at compile
> time between getopt_long (and single arguments ;-) and the current  
> behaviour.
>
> Argus is always a really great tool, but there was heavy changing  
> behaviour
> in some programs (i.e. after a lot of client versions I had to  
> rewrite my
> graphing scripts each time). And changing the interface of ratop to  
> vi-mode with a
> small remark in single mail .... it's normally a change for a next  
> version
> or in alpha state, but you marked your code as release candidate ;-)
> Okay, may be with argus-3.1 you will do a feature freeze between  
> alpha and
> beta state and only fix bugs after this step :-)
>
> Sorry for the long mail ... if you will fix the time code problem,  
> I will
> be happy at this time :-)
>
> Wolfgang
> -- 
> <wob (at) swobspace de> * http://www.swobspace.de
>