On Thu, Feb 09, 2012 at 11:05:25PM -0800, Russ Allbery wrote: > Wouter Verhelst <wou...@debian.org> writes: > > On Thu, Feb 09, 2012 at 11:01:00AM +0100, Goswin von Brederlow wrote: > > >> Not a solution on its own. > > > Actually, I think it's a perfectly workable solution. > > >> What about a file named foo" bar' baz? > >> > >> For a worst case what about files with newlines? > > > Unless these are part of a test suite on filenames, slap upstream and > > tell them to use sane filenames? > > We're basically retracing the previous discussion, and rediscovering why > we left the spec alone. > > Formal correctness says that any possible file name should be > representable, at which point filenames with newlines or embedded quote > characters are a theoretical possibility and we would want some sort of > robust solution for all those cases.
Right. > If we *aren't* going to try to represent absolutely any possible legal > filename exactly, then we're debating over how much of a technical > correctness hole we want to leave, not over whether we're going to have one. > At that point, I think it's reasonable to ask if we care about going to the > work of expanding the spec to handle filenames with spaces in them without > wildcards, as even that is not a horribly common case. (I realize it's more > common for upstreams who develop on Windows or Mac OS.) Indeed, so the question is "how far will we go in this". I think having filenames with spaces in them is common enough that it warrants extending the spec for. I do not think that having filenames with weird characters in that have special meaning to a shell are common enough to warrant extending the spec for. On a personal note, one of my upstreams (beid) has a fairly complex licensing situation and has files in the tarball with spaces in the names... I suppose it would be to my benefit that this were allowed, but I guess it's also fair to say I may be biased. [...] -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120210110722.gm20...@grep.be