> Thanks for catching all these problems. > > > > Oops - we aren't handling NUL. Before I provide a patch, we need to > > decide if we WANT to support NUL (in which case, we translate NUL into 0 > > after unquoted \, into @ after unquoted ^, and into \0 otherwise. > > The GNU coding standards say we should support NUL.
OK, I'll put together a patch for this issue (and the others, besides your quickie ' quoting patch). A related problem - right now, ls parses an infinite number of digits in octal and hex escapes. It would probably be wiser if we changed it to parse only up to what will fit in MAX_CHAR, then end the escape. The upshot of this is that with 8-bit char, ls parses "\477" as '\47' '7', rather than overflowing an 8-bit char. Then on the dircolors side, we would have to turn NUL into \000 instead of just \0 to ensure that we don't misparse the dircolors input 'NUL' '5' into the ls character '\05'. -- Eric Blake _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
