Re: DEP 5 and directory/file names with spaces
On Sunday 07 June 2009 10:20:59 Noah Slater wrote:
> On Sun, Jun 07, 2009 at 11:07:15PM +0900, Charles Plessy wrote:
> > I think that how to specifiy a list of files is in the end in the hands
> > of the people writing parsers.
>
> I think that this optimises for the wrong thing. The parsing code will be
> wrote once, or only a few times at most. The file format will be authored
> hundreds, if not thousands of time. All other things being equal, it makes
> more sense for us to make it easy for packagers.
>
> > So, from a parser point of view, what would be preferable
>
> If I was implementing this in Python, it would be easier for me to parse
> comma separated values because the "csv" module already handles this.
> Unfortunately, if I specified " " as the separator, I would have to quote
> filenames instead of escaping any spaces with a reverse solidus.
Some other things to consider.
There is Policy 7.1 that defines how to write proper relationship fields. We know
that relationship fields are comma-separated, so there are parsers already in
programs such as sbuild that read these comma-separated values, and it shouldn't
be too hard to modify these parsers to read a 'Files' field (if it were
comma-separated).
Also, the copyright file should be something that is as simple as possible to
read, by a machine but most importantly, by any person. That includes people
that are not familiar with shell escaping.
I am more inclined to use a comma-separated list as spaces in files and
directories are frequently used, as opposed to commas in files and directories,
which are quite rare.
Consider two examples of a Files field, one space-separated, and one
comma-separated.
space-separated
Files: a\ b c d\ e\ f g.*
comma-separated
Files: a b, c, d e f, g.*
Which implementation could we reasonably expect most people to understand (to
include people not knowledgeable with shell escaping)? For example, consider
what the two fields may mean to a Windows user.
--
Regards,
Andres
Reply to: