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. 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.) That's how ended up where we are now. Note that another case that I don't think has been discussed, but which is probably more common than embedded quote marks, is a filename that's invalid UTF-8 (straight ISO 8859-1, for example). That's also not representable in our typical debian/copyright file, and is likely to cause significant practical problems (such as having the encoding format change every time the maintainer edits the file, since some editors will try to "fix" such problems). -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- 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/87pqdn183u....@windlord.stanford.edu