Double escaping in $ARGx$

[Ton Voon]

On 11 Aug 2009, at 09:30, Andreas Ericsson wrote:

> Ton Voon wrote:
>>
>> On 31 Jul 2009, at 16:10, Ethan Galstad wrote:
>>
>> Andreas writes:
>>> Why use the exclamation mark at all? It's quite straightforward to  
>>> parse
>>> shell-style quoting into arguments, and that way users can just
>>> cut-n-paste
>>> the commands to verify that they work (assuming they replace the  
>>> macros,
>>> that is).
>>
>> That's wrong. You use execve to avoid the shell quoting and to pass  
>> in
>> arguments "as-is" to the plugin without interpretation at the shell
>> level.
>
> I'm well aware of that, but hand-parsing it inside Nagios would not be
> difficult, assuming we can still pass commands with sub-shells to the
> shell for execution.

I'm not sure what you mean here. Can you give an example?

> I've changed my mind about the exclamation mark though, but using it
> in a command_line statement for a command object shouldn't mean it
> requires escaping.

I'm fine with whatever the current rules for command_line are. I don't  
plan on changing that.

> Also, I'd quite like to get a conditional parameter parsing thing for
> Nagios, so that one can do something like this:
>
> define command{
>   command_name   check_http
>   command_line   $USER1/check_http -H $HOSTADDRESS$ $?ARG1:-p$ $ARG1$
> }
>
> where '-p' and $ARG1$ only ever get added if they're actually  
> configured.
> Possibly also only if they're non-nul strings.

Outside of scope for the moment :)

Ton

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july