Re: cron on 10.5.2 server

On 2008-05-03 08:20:35 +0100, Jolly Roger <jollyroger@[EMAIL PROTECTED]
> said:

> In article <682fbqF2qd9ofU1@[EMAIL PROTECTED]
>,
>  Chris Ridd <chrisridd@[EMAIL PROTECTED]
> wrote:
> 
>> On 2008-05-03 06:57:18 +0100, Jolly Roger <jollyroger@[EMAIL PROTECTED]
> said:
>> 
>>> In article <682cq3F2qi61hU1@[EMAIL PROTECTED]
>,
>>> Chris Ridd <chrisridd@[EMAIL PROTECTED]
> wrote:
>>> 
>>>> I wonder if the bug in crontab alluded to at the end is still
present?
>>> 
>>> My take is that's not a bug, but is just the way it is, because of the
>>> way crontab parses the EDITOR environment variable.
>> 
>> OK, well the "feature" is certainly still in the 10.5.2 code:
>> 
>>
<http://www.opensource.apple.com/darwinsource/10.5.2/cron-30/crontab/crontab.c
>>> 
> 
> Are you referring to line 435?:
> 
>           execlp(editor, editor, Filename, (char *)NULL);

Yep.

> It does seem strange that they are passing editor (which contains the
> contents of the EDITOR environment variable), in its entirety for the
> first *and* second parameter. The first parameter is supposed to the
> pathname to the executable (edit), and the second parameter is supposed
> to be a list of arguments or switches to pass to the executable (-w). It
> seems they are instead passing "edit -w" and "edit -w" for both
> parameters, which is what causes the error:
> 
> # crontab -e
> crontab: edit -w: No such file or directory
> crontab: "edit -w" exited with status 1

The next argument's what the execed program will read as argv[0], so it 
is usually OK to pass the same string twice. Clearly in this case 
crontab is trying to exec a program literally called "edit -w".

My best guess on the behaviour is that it was considered too risky to 
try securely parsing the $EDITOR value into multiple strings.

Cheers,

Chris