bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug#339136: Changes in stat package output break apt-move


From: ThMO
Subject: Re: Bug#339136: Changes in stat package output break apt-move
Date: Tue, 22 Nov 2005 20:16:36 +0100

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]