On Thu, 2011-06-16 at 15:13 -0400, Rich Felker wrote: > On Thu, Jun 16, 2011 at 03:16:38PM -0400, Paul Smith wrote: > > PS. Interestingly, there's a move afoot to remove newline from the set > > of acceptable characters in a POSIX-compliant filename... > > Do you have details on this? It's interesting because aside from the > '/' (which is granted special meaning) POSIX only specifies which > characters are portable and guaranteed to be supported in filenames, > but does not forbid any characters. Would this mean interfaces that > create files "shall" fail if given a name contain a newline? It would > be a welcome change, but I can see many folks resisting...
I believe anonymous access to the Austin Group bugtracker is available. The proposal is here: http://austingroupbugs.net/view.php?id=251 In addition there've been a number of long threads on this in the mailing list which aren't completely reflected in the bug, including how real implementations might handle migration to the new standard when there could be existing filenames which are suddenly illegal. The original proposal was that ALL characters with ASCII codes 0 through 31 would be forbidden. The fallback position, should that prove too unpalatable, is just to restrict newline and possible a couple of other bad actors like TAB and ESC. The proposal suggests a new errno code (ENAME) be returned by filename handling functions when an invalid filename is received. The wording suggested is: Vol. 1, Page 60, line 1782-1784: Change: "The characters composing the name may be selected from the set of all character values excluding the <slash> character and the null byte." to: "The characters composing the name may be selected from the set of all character values excluding the <slash> character, the null byte, and character values 1 through 31 inclusive. Attempts to create filenames containing bytes 1 though 31 must be rejected, and conforming implementations must not return such filenames to applications or users." Vol. 1, Page 77, append after 2199: The set of character values 1 through 31, inclusive, are expressly forbidden. Attempts to create such filenames must be rejected, and conforming implementations must not return such filenames to applications or users. Vol. 2, page 480, [ENAME] The path name is not a permitted name, e.g., it contains bytes 1 through 31 (inclusive). Note this is still under review and active discussion so who knows if it will go anywhere. When I first read it my knee-jerk reaction was "no way! This is UNIX!" but now that I've lived with it for a while I actually like it. I see zero benefit to the current behavior, other than some abstract, arbitrary concept of "purity" and even though I've been hacking shell scripts, etc. for an embarrassing number of years, I still run into these issues (or, more likely, just document that the script doesn't work with ill-formed filenames). _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
