Hello Jim and others listening, > > wouldn't it be better to implement the full backslashed sequences inside > > print_esc() than only `\n'? > > Consistency between tools is nice, but do we need support for \t, \v, > \a, \b, \c, \f, etc? What about octal escapes? Hexadecimal and > unicode, too, like printf(1)?
sorry, but unicode has nothing to do with escape sequences, as it denotes a different charset, e.g. an expensive replacement for iso-8859-1. > I like the keep-it-simple approach and am leaning toward > supporting the backslash-escape sequences that are supported > for find's -printf format. `find' v4.1 does support all C backslash-escape sequences with an additional `\c' to be compatible with some `echo' implementations. > In other words, `Yes, depending on what you mean by ``full''.' By `full' I mean: · the usual C character escapes · octal escape · hexadecimal escapes IMHO the question will be, why is *only* `\n' an implementation-worthy escape sequence, while many common UNIX tools do support the C escapes already. Surely, there are again many other ways inside s shell-script, to reproduce the old behaviour, OTOH we all know how lazy we get, depending on a long-standing behaviour... ;-) As far as the `stat' command is concerned, and here specifically the --format option: with all the ability to customize a personal output format, one thing can't be done, without the possibility of specifying a simple `\t' escape: when it comes to ensure, that some information need to be formatted in a spe= cific column, since the tabulator eliminates the need for counting the necessary spaces. OTOH one could simulate the `stat' command with the equivalent `find' command, so it's surely some already done work need to be done again... It's surely not an easy decision, but my personal viewpoint is, if it's for= seeable, that further questions might arrive about extending the cut-down escape sequence(s) implemented, it's surely less work, to do it once fully supporting all escapes, but YMMV. CU Tom. (Thomas M.Ott) Germany _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
