argus-clients: funny command line parsing

[Wolfgang Barth]

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