[Nagiosplug-devel] RFC: New threshold syntax

[Andreas Ericsson]

Max wrote:
> On Wed, Mar 19, 2008 at 7:17 AM, Andreas Ericsson <ae at op5.se> wrote:
>>  Yes, because many people will forget the quotes lots and lots of
>>  times. Syntaxes that so obviously will lead to irritation is stupid.
>>  definition. I know from personal experience that people will almost
>>  always omit quoting the first time a program is run if they're not
>>  a) 100% alert
>>  b) very used to Unix
>>  c) the developer who wrote the app
>>  d) previously bitten numerous times by the same issue
> 
>>  The problem with overloading a shell operator is that the plugin
>>  author gets zero chance of giving decent feedback to the user what
>>  he did wrong, because he can't see the entire commandline the user
>>  gave, and someone not savvy enough with unix but still wishing to
>>  run Nagios won't have any idea what so ever that <> are input/output
>>  redirection commands for the shell to interpret.
>>
>>  So yes, the idea of using shell operators in command arguments is
>>  clearly bogus.
> 
>>  user to "be more careful when creating his command definitions" and
>>  you'll just have made one HP openview sales rep very happy.
> 
> Ok, so you are a pessimist about the ability of normal users to be
> competent with shell syntax and I am an optimist.
> 
> I don't agree that most users will forget to quote arguments, that
> hasn't been my experience with people new to Linux or Unix, but I
> certainly can't talk to your experience.
> 
>>  Except that '<' is *also* bogus, and will break horribly for any program
>>  running a script that can accept input on stdin.
> 
> Again works fine if quotes are used and the person is not on some
> ancient shell as you clearly pointed out that will break things even
> with quoting.
> 

So what do we do with users running Nagios on AIX? Tell them to go
screw themselves, because "oh look, we've thought up this wonderful
new way of specifying critical and warning ranges at the same time"?

Or they could ofcourse just not upgrade the plugins package, but
that doesn't work in the long run.

>>  >>> just rip an SQL-parsing implementation directly, with subquery
>>  >>> support
>>  >>> tucked right in.
>>  Ugly, since SQL has different quoting / escape rules than shell, so
>>  you have to mix the two in order to be able to utilize it fully. Iow,
>>  same can of worms that Max wants to open, but opened from underneath
>>  and only powerusers will get bitten, as opposed to everyone.
> 
> Then why did you bring the idea to the table?  That was your idea in
> your earlier email.
> 

I was being ironic. An SQL parser that handles the standard only is
far too complex to parse arguments with.

> I don't want to 'open a can of worms', I want syntax that is easy to
> maintain and understand for new users and syntax that is rich enough
> to model complex conditionals for advanced users that still maintains
> some form of readability, to me it seems like this will all be going
> down the road of not having the holy grail of argument standards but
> instead continuing the lines of having best practices, maybe just
> having best practices for those less experienced with plugin writing
> and Linux/Unix and another set for those who are more experienced with
> the two.
> 

So two sets of arguments to maintain? Maintenance nightmare, imo.

> Appreciate the lengthy explanation of why you thought my idea was
> stupid, bogus, idiotic, whatever other insults you wish to add.

I never said idiotic. I said "<" is also bogus, because it leads to
bogus error messages when users forget to add the quotes. And they
will, trust me on that. Not to mention that it's horrible to write
parsers for shell-specific chars in shell, and I imagine the perl
parser will look quite funny too (which, going by your email, you'll
half-volunteer to write).

I did say stupid though, and I stand by it. Note that I didn't call
you stupid, but your idea, which is a different matter entirely.
Even brilliant people sometimes have dumb ideas because they don't
see all the consequences of it, or perhaps they just don't have to
deal with them, which, for practical purposes, equates to roughly
the same thing.

>  Would
> have been nice if you explained that up front and substituted your
> obviously knowledgeable understanding of the problems that might cause
> for some users on some systems instead of just insulting me without
> any explanation.
> 

What gain is there for either of us if I spoonfeed you the answers? I
was hoping you'd start thinking a bit further than "this looks neat and
almost like perl. I *like* it!". That way you could have learned
something.

For the future; it's a good idea to see what other semi-similar programs
are doing. For the record, I can't think of a single cli program that
requires shell characters in its command line.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231