Re: Path and argument problem... solution?

[Jan-Henrik Haukeland]

Christian Hopp <address@hidden> writes:

> Just little things...
> 
> 1) Beautification... I try to give lonesome quotes comments with
>    quotes to fix syntax highlighting. (status->done)
> 
> 2) I think we should use my string quote trimmer to have the
>    possibility to use double quotes in single quoted strings. (second
>    example above)   (status->done)

Yes, please, add your code. You forgot to attach it to the mail you
sent so I had problems including it :)

> 3) We should capture escaped chars (at least the important ones): "\t",
>    "\n", "\ ".  (status->not yet done)

You're right about that. Any ideas?

> 4) We should add a possibility to a some kind of variables like
>    "$pid", "$service", "$checksum", ...  in first I thought of using
>    an environment variable for it but there is no execve, just execle.
>    And that would be a not so nice hack.  An other possibility would
>    be to substitute the variables at start time. (status->wish)

I'm not quite sure what you mean, please explain. BTW environment
variable in exec sounds pretty dangerous.

> > Another thing. The spawn command for starting programs from monit
> > should send an alert message when it fails to execute a program.
> >
> > Because we need to free memory before the execv it's not easy to do
> > this nice. For now I have changed the function's signature to take a
> > Process_T object as well as a Command_T object. The idea is that the
> > mailinglist in the Process_T object can be used to send an alert mail
> > if spawn (i.e. execv) fails to start a program. I have to think a bit
> > more on how to do this and any suggestions are welcome!
> 
> Return it as a wait to the fork and do the exit after a timeout?

Because of the double fork I do not think this is possible?

> > Finally, on the side note, I have started to subscribe to a new coding
> > style
> 
> I have tried my best to adept your style guide... 

I have no complaints about your code, on the contrary, it looks good.

> but I became a programmer of a language which does not need this
> puny brackets... python. (-:

Urk, isn't python the language where indentions are significant?

-- 
Jan-Henrik Haukeland