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

Escaping single quotes in file names [was: --xml on all svn commands]

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2005-10-07 00:04:25 CEST

kfogel@collab.net wrote:
> "Max Bowsher" <maxb@ukf.net> writes:
>>>2) filenames can have single quotes in them so trying to parse by single
>>>quotes won't work either.
>>Hmm, I wonder if we should be escaping these.
> Yes, we should.

I don't think so.

The places where file names are delimited by single quotes are:

error messages such as "Can't open 'file'"
warnings such as "Skipped 'file'"
notifications such as "Reverted 'file'"
                    and "'file' locked by user 'user'"
                    and "Property 'p' set on 'file'"

(Note that a property name cannot contain a single quote character.)

I don't think there are any other places in the output produced by "svn".

AFAICT, our error messages were never meant to be machine-parsable. If they
were, the quoting of file names must be the least of the difficulties.
Certainly, at present, there is no programmatic way to tell whether and where a
file name is present except by knowing the exact expected message. Therefore
there is almost no point in trying to escape single quotes in them. It would
only make them uglier for human readers.

The same goes for warnings except that there is more reason for a script to
want to parse them (in a basic way) because they can be part of the expected
output. If the specific expected warning message is known, the file name can
be extracted without any internal quote marks having been escaped. So still no

The same goes for notifications as for warnings.

Therefore I don't think this is worth doing at all.

- Julian

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 7 00:05:02 2005

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.