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,
On 2009-06-08, Giacomo A. Catenazzi c...@cateee.net wrote:
The slash is locale dependent. Thus a file created in an other locales
could contain the character that in current locale is interpreted as
slash.
BTW with pathname resolution rules, the file could not be acceded, but
AFAIK the non
Philipp Kern wrote:
On 2009-06-08, Giacomo A. Catenazzi c...@cateee.net wrote:
The slash is locale dependent. Thus a file created in an other locales
could contain the character that in current locale is interpreted as
slash.
BTW with pathname resolution rules, the file could not be acceded,
On Wed, Jun 10, 2009 at 09:51:12AM +, Philipp Kern wrote:
On 2009-06-08, Giacomo A. Catenazzi c...@cateee.net wrote:
The slash is locale dependent. Thus a file created in an other locales
could contain the character that in current locale is interpreted as
slash.
BTW with pathname
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 upstream
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
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:
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 like the
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 Langasekvor...@debian.org wrote:
On Mon, Jun 08, 2009 at 09:11:09PM -0700, Steve Langasek wrote:
vor...@gluck cd
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,
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
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,
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
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 quotes (')
* 64 asterisks (*)
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:
Files:
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.
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
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
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
On 2009-06-08, Giacomo A. Catenazzi c...@debian.org 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.
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
Philipp Kern wrote:
On 2009-06-08, Giacomo A. Catenazzi c...@debian.org 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
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 fact that
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, escaping
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 (theoretically)
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 Wolfgw...@gwolf.org wrote:
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 readable,
but
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 necessary.)
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)
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
Well, this
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
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
[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 to
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 so
On Sunday 07 June 2009 01:47:04 Ben Finney wrote:
Andres Mejia mcita...@gmail.com 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
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 doesn't
Andres Mejia mcita...@gmail.com 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
Robert Collins robe...@robertcollins.net 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 ' '
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 same licence
On Sunday 07 June 2009 03:02:32 Ben Finney wrote:
Andres Mejia mcita...@gmail.com 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
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) indicating files that
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.
This
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?
--
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 of
Stephen Gran sg...@debian.org 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?
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.
Hi
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
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
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 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 is
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 expect most
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 fields may
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 knowledgeable
Andres Mejia mcita...@gmail.com 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
Andres Mejia mcita...@gmail.com 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
55 matches
Mail list logo
