[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn system() replacement ?

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2002-01-28 18:04:06 CET

Karl Fogel <kfogel@newton.ch.collab.net> writes:

> Philip Martin <philip@codematters.co.uk> writes:
> > Ah, I see, apr_proc_create calls execve which explicitly sets the
> > environment :-(
> >
> > What is needed is an APR function that calls execv thus allowing the
> > environment to be inherited.
>
> Philip, does this mean that your earlier suggestion:
>
> > If you really intend to use a shell there are two options. Either add
> > an additional parameter to svn_io_run_cmd to determine which of
> > APR_PROGRAM/APR_SHELLCMD to use, or call apr_proc_create directly.
>
> wouldn't work? Or that it would be undesirable for the same reasons
> that calling system() is undesirable?

It won't work unless or until APR is changed. I don't think it is
sensible to invoke an editor without inheriting the environment, who
knows what I want and/or need from my environment for my editor to
run. Perhaps I need DISPLAY, maybe I need LD_LIBRARY_PATH, svn cannot
guess.

We still need to run a shell so that if SVN_EDITOR is set to an editor
without a path, "ed" for example, the shell will use PATH to find the
executable. Invoking system() on Unix will usually both run a shell
and propogate the environment.

The whole concept of invoking an editor via an environment variable
means that svn has security holes, such a program should not be
installed setuid for instance. Of course, this is not really a problem
since svn is not intended to be secure. It may, however, explain why
APR has no support for this feature.

-- 
Philip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:00 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.