I have been meaning to look at p1.pl. One of the sugestions was to use
Text::ParseWords module in p1.pl and go through @ARGV to allow spaces.
Sorry I haven't had a lot of time to get into it.
-sg
On Tue, 22 Oct 2002, Stanley Hopcroft wrote:
> Dear Ladies and Gentlemen,
>
> This problem is unfortunately deeply rooted in Netsaints design goal of
> having /bin/sh run the service checks.
>
> /bin/sh wants to be passed a string like
>
> Program 'This is the first arg' 'the second arg' and the rest
>
> which it will then parse iteslf in the expected way.
>
> The embedded Perl interpreter on the other hand wants the arguments
> parsed for it and passed to it either as an argument vector or on the
> Perl stack - in any case, the arguments are separated by the caller and
> not by Perl.
>
> The existing implementation trades off the common case of single word
> arguments (against greater complexity) by passing to Perl _one_
> argument string containing the command line options and arguments and
> having p1.pl split it on white space.
>
> However, Netsaint is already doing extensive argument and command line
> processing so it may be possible to exploit this for Perl.
>
> There may therefore be two ways of improving this situation
>
> 1 Improve the parsing of the arguments by p1.pl
>
> ==> so $ar in pl.pl is processed into @ARGV according to the usual
> conventions.
>
> This requires that _all_ potential white space filled arguments are
> quoted.
>
> This means that (at least) process_macros() would have to quote the
> values of the macros it finds so that p1.pl will eventually see them
> quoted and know where the values start and finish.
>
> This seems a bit yukky since _all_ service checks get the quoted values
> - conditional on the embedded Perl support.
>
> 2 Pass arguments to Perl on the Perl stack.
>
> This could be done by creating a new global array variable and having
> process_macros() append each value it finds to that array.
>
> get_raw_command_line() would also have to split the found command line
> on white space and add the options/switches to this array also.
>
> eg
>
> for a command command[check_by_ssh]=$USER1$/check_by_ssh -t 30 -H $ARG1$
> -l $ARG2$ -C '$ARG3$ $ARG4$
>
> 1 split on white space and put the command name in the array
>
> 2 for the rest of the command
>
> push it onto the global perl argument array.
>
> This suggests that get_raw_command_line returns the new
> global array perl_args[] with
> {
> $USER1$,
> check_by_ssh,
> '', /* reserved for temp file name */
> '', /* reserved for cache switch */
> -t,
> 30,
> -H,
> $ARG1$,
> -l ...
> }
>
> and that process_macros processes this array as well as
> the raw_command string.
>
>
> Note that this is _extra_ processing required if embedded Perl support
> is defined.
>
> The call to perl_call_argv would then (basically) use this array as its
> argument vector and the call to perl_call_pv would push each value from
> this list onto the Perl stack. These are trivial changes.
>
> This way requires little change to p1.pl (replacing $ar in p1.pl by the
> rest of @_) but substantial hacking elsewhere.
>
> Apart fromm ascertaining that should Perl be called with the arguments
> preparsed into array slots, the white space problem goes way, I have
> done nothing.
>
> Please would you consider commenting on the 2 approaches suggested above
> - I think 2 is the best - or suggest a better way ?
>
> Yours sincerely.
>
>
--
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: sghosh@sghosh.org