On Wed, Jun 10, 2009 at 09:51:12AM +, Philipp Kern wrote:
> On 2009-06-08, Giacomo A. Catenazzi wrote:
> > The is locale dependent. Thus a file created in an other locales
> > could contain the character that in current locale is interpreted as
> >.
> > BTW with pathname resolution rules, the
Philipp Kern wrote:
On 2009-06-08, Giacomo A. Catenazzi wrote:
The is locale dependent. Thus a file created in an other locales
could contain the character that in current locale is interpreted as
.
BTW with pathname resolution rules, the file could not be acceded, but
AFAIK the non pathname r
On 2009-06-08, Giacomo A. Catenazzi wrote:
> The is locale dependent. Thus a file created in an other locales
> could contain the character that in current locale is interpreted as
>.
> BTW with pathname resolution rules, the file could not be acceded, but
> AFAIK the non pathname resolution syst
ti, 2009-06-09 kello 08:16 -0500, Manoj Srivastava kirjoitti:
> No newlines, eh? Seems like the one glob per line wins.
It's still ugly and requires special-casing "Files:" in the parser
(which I'm happy to do, if it's the consensus that it's the best way for
people writing/reading it, spe
On Tue, Jun 09, 2009 at 04:13:13PM +0200, Giacomo A. Catenazzi wrote:
> Manoj Srivastava wrote:
> >On Tue, Jun 09 2009, Lars Wirzenius wrote:
> >
> >
> >>Some highlights:
> >>
> >>* two carriage return chars (\r)
> >>* one escape char
> >>* 5431 spaces
> >>* 1 double quotes (")
> >>* 98 single quot
On Tue, Jun 09, 2009 at 10:12:48AM -0400, Jonathan Yu wrote:
> In my defense, you don't mention how many filenames have newlines (my
> estimate is zero.)
Because my position was that the frequency of each of these characters is
negligible, so the escaping mechanism we choose has no practical impac
On Wed, Jun 10, 2009 at 12:08:22AM +0900, Charles Plessy wrote:
> * List of space-separated pathnames indicating files that have the same
> licence and share copyright holders. Question marks indicate any character
> and asterisks indicate any string of characters.
+1
--
Noah Slater, http://
Le Mon, Jun 08, 2009 at 10:15:26AM -0400, Jonathan Yu a écrit :
> You know, this is probably a stupid question, but what's wrong with
> separating file patterns with newlines, as continuations?
Hi Jonathan,
first of all, do not worry that your proposition was ignored, but it is
sometimes more int
Manoj Srivastava wrote:
On Tue, Jun 09 2009, Lars Wirzenius wrote:
Some highlights:
* two carriage return chars (\r)
* one escape char
* 5431 spaces
* 1 double quotes (")
* 98 single quotes (')
* 64 asterisks (*)
* 524 commas
* 3 backslashes
* 51601 percent chars (%)
No newlines, eh
In my defense, you don't mention how many filenames have newlines (my
estimate is zero.)
But IANADD so do what you want :-)
On Tue, Jun 9, 2009 at 3:47 AM, Steve Langasek wrote:
> On Mon, Jun 08, 2009 at 09:11:09PM -0700, Steve Langasek wrote:
>> vor...@gluck> cd /srv/lintian.debian.org/laborator
On Tue, Jun 09 2009, Lars Wirzenius wrote:
> Some highlights:
>
> * two carriage return chars (\r)
> * one escape char
> * 5431 spaces
> * 1 double quotes (")
> * 98 single quotes (')
> * 64 asterisks (*)
> * 524 commas
> * 3 backslashes
> * 51601 percent chars (%)
No newlines, eh? Seems
ti, 2009-06-09 kello 00:47 -0700, Steve Langasek kirjoitti:
> Sorry, this is an incorrect test; on closer examination, the upstream
> tarballs aren't unpacked in the lintian lab. The actual count (from a
> recursive tar ztvf) is
>
> commas: 1032
> spaces: 7305
> total files:
Peter Samuelson wrote:
First, as I've said elsewhere, this thread is just about the most
impressive bikeshedding session I've ever seen.
In my defence (I started this sub-bikeshedding): it was a sentence
in a postscriptum.
Technically: on handling external data: for every rules there will
be ex
On Mon, Jun 08, 2009 at 09:11:09PM -0700, Steve Langasek wrote:
> vor...@gluck> cd /srv/lintian.debian.org/laboratory/source
> vor...@gluck> find . -name '*,*' | wc -l
> 9
> vor...@gluck> find . -name '* *' | wc -l
> 23
> vor...@gluck>
Sorry, this is an incorrect test; on closer examination, the u
On Mon, Jun 08, 2009 at 11:18:41PM -0400, Jonathan Yu wrote:
> Another thing is that it just looks more readable. And the (standard)
> diff utility output is nicer (and more helpful). Sure, more helpful
> GUI diff programs will show you the exact subsequence which has
> changed... But for something
[Peter Samuelson]
> I propose something very simple: ? to escape any single byte that seems
^Wreplace
> problematic in any way. Spaces, tabs, newlines, the ISO-8859-1
> registered trademark symbol, etc., etc. I mean, we don't need this
> transform t
First, as I've said elsewhere, this thread is just about the most
impressive bikeshedding session I've ever seen. So I'll try and stick
to a single post, and I'm only posting because I don't think I've seen
mention of the following problem:
[Gunnar Wolf]
> Yup - But the newline is also a valid (
Rob:
As I mentioned, it's not that simple escaping is *hard* -- just that
it can be relatively easy to a) make mistakes; b) not be totally sure
of what the statement really means (short of doing `ls' on those
filenames of course).
Another thing is that it just looks more readable. And the (standa
On Mon, 2009-06-08 at 10:15 -0400, Jonathan Yu wrote:
>
> You know, this is probably a stupid question, but what's wrong with
> separating file patterns with newlines, as continuations?
>
> Files: a b
> c
> d e f
> g.*
>
> To me it looks more readable, no escaping or quotes are necessary
We
I'd suggest for readability/maintainability (especially for those with
editors that might mask characters like these) to have some of the
characters as part of filenames escaped in the usual form--
TAB becomes \t
CR becomes \r
LF becomes \n
etc.
I think perhaps too many escapes (backslashes) wou
Jonathan Yu dijo [Mon, Jun 08, 2009 at 07:35:56PM -0400]:
> Since nobody seems to have noticed, I'd like to re-propose my idea for
> consideration:
>
> Files: a b
> c d
> e
> f
>
> (ie, using continuation lines to specify lists of files, rather than
> commas or anything else. No escaping neces
On 18:28 Mon 08 Jun , Bernd Eckenfels wrote:
> In article <20090608030732.gc15...@dario.dodds.net> you wrote:
> > space-separated
> > Files: a\ b c d\ e\ f g.*
> >
> > comma-separated
> > Files: a\,b, c, d\,e\,f, g.*
> >
> > For my part I'm actually inclined to say that the latter is more
Since nobody seems to have noticed, I'd like to re-propose my idea for
consideration:
Files: a b
c d
e
f
(ie, using continuation lines to specify lists of files, rather than
commas or anything else. No escaping necessary.)
On Mon, Jun 8, 2009 at 7:04 PM, Gunnar Wolf wrote:
> Giacomo A. Catena
Giacomo A. Catenazzi dijo [Mon, Jun 08, 2009 at 05:09:02PM +0200]:
> >>PS: on POSIX you can expect all characters but NULL in filename
> >>('/' is a very special beast: you cannot create a file containing the
> >>'/' in current locale, but if it was created in other locales there
> >>are not (theor
Charles Plessy dijo [Sun, Jun 07, 2009 at 11:07:15PM +0900]:
> The current advantage of space-delimited listing is that is matches the
> command-line experience. For intance we do not write ‘ls src, debian’, but ‘ls
> src debian’.
>
> So, from a parser point of view, what would be preferable, esca
In article <20090608030732.gc15...@dario.dodds.net> you wrote:
> space-separated
> Files: a\ b c d\ e\ f g.*
>
> comma-separated
> Files: a\,b, c, d\,e\,f, g.*
>
> For my part I'm actually inclined to say that the latter is more readable,
> but let's get the rationale right. :)
Given the fac
Philipp Kern wrote:
On 2009-06-08, Giacomo A. Catenazzi wrote:
PS: on POSIX you can expect all characters but NULL in filename
('/' is a very special beast: you cannot create a file containing the
'/' in current locale, but if it was created in other locales there
are not (theoretically) proble
On Mon, Jun 08, 2009 at 04:41:40PM +0200, Giacomo A. Catenazzi wrote:
> So IMHO we must prefer understandable rules, like shell quotes, instead
> of new rules.
+1
--
Noah Slater, http://tumbolia.org/nslater
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "u
On 2009-06-08, Giacomo A. Catenazzi wrote:
> PS: on POSIX you can expect all characters but NULL in filename
> ('/' is a very special beast: you cannot create a file containing the
> '/' in current locale, but if it was created in other locales there
> are not (theoretically) problems.
Wrong: The
Charles Plessy wrote:
I also think that to get the best human-readability, it is important to avoid
escape and quoting characters.
I don't agree, we use wild cards (or glob as written in PEP5), which are
not so human readable (if developer use non standard globs).
Additionally rules are complex
On Mon, Jun 08, 2009 at 11:14:04PM +0900, Charles Plessy wrote:
> space-and-commas: a, list of, files,that, contain, commas??or, spaces.
What if I have "commas, or" and "commas,,or" as two separate files?
--
Noah Slater, http://tumbolia.org/nslater
--
To UNSUBSCRIBE, email to debian-devel-req
You know, this is probably a stupid question, but what's wrong with
separating file patterns with newlines, as continuations?
Files: a b
c
d e f
g.*
To me it looks more readable, no escaping or quotes are necessary, at
the expense of being a bit more difficult to type than quoting (though
defi
Hi all,
I also think that to get the best human-readability, it is important to avoid
escape and quoting characters. Using one comma plus one space as a separator,
this goal is acheived in a very large number of cases. Moreover, this is the
way things are delimited in most debian/control fields. I
su, 2009-06-07 kello 20:07 -0700, Steve Langasek kirjoitti:
> In other words, the real question is: which of these is easier for your
> hypothetical user to read?:
>
> space-separated
>Files: a\ b c d\ e\ f g.*
>
> comma-separated
>Files: a\,b, c, d\,e\,f, g.*
url-encoded:
Fil
Andres Mejia writes:
> Oh. I didn't know of such a goal and the DEP draft doesn't mention
> this. I've always thought the copyright file was meant to be most
> readable by people.
Yes, and that's certainly a goal that should not be lost. As I
understand it, the goal is to make it *also* easily p
On Mon, Jun 08, 2009 at 12:03:00AM -0400, Andres Mejia wrote:
> On Sunday 07 June 2009 22:51:10 Noah Slater wrote:
> > On Sun, Jun 07, 2009 at 10:44:41PM -0400, Andres Mejia wrote:
> > > Which implementation could we reasonably expect most people to understand
> > > (to include people not knowledge
On Sunday 07 June 2009 22:51:10 Noah Slater wrote:
> On Sun, Jun 07, 2009 at 10:44:41PM -0400, Andres Mejia wrote:
> > Which implementation could we reasonably expect most people to understand
> > (to include people not knowledgeable with shell escaping)? For example,
> > consider what the two fiel
On Sun, Jun 07, 2009 at 10:44:41PM -0400, Andres Mejia wrote:
> 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 expec
On Sun, 2009-06-07 at 22:44 -0400, Andres Mejia wrote:
> 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.
I think the style I proposed i
On Sun, Jun 07, 2009 at 10:44:41PM -0400, Andres Mejia wrote:
> 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.
To a Windows user?
Heh, I
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 w
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 for
Le Sun, Jun 07, 2009 at 12:44:23AM -0400, Andres Mejia a écrit :
> The current proposal for DEP 5 has this snippet for the 'Files' field.
>
> "List of space-separated globbing pathnames (see man 7 glob for more details)
> indicating files that have the same licence and share copyright holders."
Stephen Gran writes:
> This one time, at band camp, Ben Finney said:
> > I'm not sure how to resolve this without making the specification
> > more hairy. Is there prior art we can refer to?
>
> Why not just use standard csv rules for this sort of thing, ie add
> quotes where necessary?
I can s
On Sun, 07 Jun 2009, Andres Mejia wrote:
> "List of space-separated globbing pathnames (see man 7 glob for more details)
> indicating files that have the same licence and share copyright holders."
>
> This doesn't take into account files or directories that may be named with
> spaces.
Principle
This one time, at band camp, Ben Finney said:
> I'm not sure how to resolve this without making the specification more
> hairy. Is there prior art we can refer to?
Why not just use standard csv rules for this sort of thing, ie add
quotes where necessary?
--
--
su, 2009-06-07 kello 00:44 -0400, Andres Mejia kirjoitti:
> The current proposal for DEP 5 has this snippet for the 'Files' field.
>
> "List of space-separated globbing pathnames (see man 7 glob for more details)
> indicating files that have the same licence and share copyright holders."
>
> Thi
Andres Mejia wrote:
> On Sunday 07 June 2009 02:16:41 you wrote:
>> On Sun, 2009-06-07 at 00:44 -0400, Andres Mejia wrote:
>> > The current proposal for DEP 5 has this snippet for the 'Files' field.
>> >
>> > "List of space-separated globbing pathnames (see man 7 glob for more
>> > details) indica
On Sunday 07 June 2009 03:02:32 Ben Finney wrote:
> Andres Mejia writes:
> > On Sunday 07 June 2009 01:47:04 Ben Finney wrote:
> > > Thanks for raising this problem with the current draft. I agree that
> > > it needs to be changed to allow spaces in the patterns.
>
> […]
>
> > > I would prefer to
On Sunday 07 June 2009 02:16:41 you wrote:
> On Sun, 2009-06-07 at 00:44 -0400, Andres Mejia wrote:
> > The current proposal for DEP 5 has this snippet for the 'Files' field.
> >
> > "List of space-separated globbing pathnames (see man 7 glob for more
> > details) indicating files that have the sam
Robert Collins writes:
> On Sun, 2009-06-07 at 00:44 -0400, Andres Mejia wrote:
> > I suggest that the Files field use a comma-separated list of
> > globbing pathnames instead, else something ugly like 'path/with some
> > spaces/'* would have to be used.
>
> That just trades ' ' for ',' as the p
Andres Mejia writes:
> On Sunday 07 June 2009 01:47:04 Ben Finney wrote:
> > Thanks for raising this problem with the current draft. I agree that
> > it needs to be changed to allow spaces in the patterns.
[…]
> > I would prefer to have a specification that allows the above field
> > to be parse
On Sun, 2009-06-07 at 00:44 -0400, Andres Mejia wrote:
> The current proposal for DEP 5 has this snippet for the 'Files' field.
>
> "List of space-separated globbing pathnames (see man 7 glob for more details)
> indicating files that have the same licence and share copyright holders."
>
> This d
On Sunday 07 June 2009 01:47:04 Ben Finney wrote:
> Andres Mejia writes:
> > I suggest that the Files field use a comma-separated list of globbing
> > pathnames instead, else something ugly like 'path/with some spaces/'*
> > would have to be used.
>
> Thanks for raising this problem with the curre
Andres Mejia writes:
> I suggest that the Files field use a comma-separated list of globbing
> pathnames instead, else something ugly like 'path/with some spaces/'*
> would have to be used.
Thanks for raising this problem with the current draft. I agree that it
needs to be changed to allow space
The current proposal for DEP 5 has this snippet for the 'Files' field.
"List of space-separated globbing pathnames (see man 7 glob for more details)
indicating files that have the same licence and share copyright holders."
This doesn't take into account files or directories that may be named wit
56 matches
Mail list logo
