gnu-arch-users
[Top][All Lists]
Advanced

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

Re: [Gnu-arch-users] Re: File naming conventions


From: Zenaan Harkness
Subject: Re: [Gnu-arch-users] Re: File naming conventions
Date: Tue, 26 Oct 2004 17:07:14 +1000

On Tue, 2004-10-26 at 16:49, Miles Bader wrote:
> On Tue, Oct 26, 2004 at 04:17:18PM +1000, Zenaan Harkness wrote:
> > > This is perhaps harder than it should be because tla's output escaping
> > > format seems very complicated -- e.g., unicode encoding etc -- and it
> > 
> > Unicode encoding is actually a good thing. It would indeed be nice to
> > have a tla-encoding filter/munger to convert to "xargs" format. Keeps
> > everything nice and orthogonal etc...
> 
> Not really.  Tla _already has to do it_ -- it has to interact with the
> file-system (and support the "--unescaped" option) already, so it can't
> avoid having coding conversion of some sort (to the extent that tla needs
> it) built-in.

ok

> An external tool could certainly duplicate everything in tla, but what on
> earth is the point?

Well, the point is certainly not to "duplicate everything in tla".

The point is orthogonality.

The point is having more applications than just tla, than can talk
unicode.

The point is in fact _minimizing_ duplication of code. At least AIUI.

> The output escaping used by tla currently addressed two problems:
> 
>   (1) It avoids conflicts between filenames (and other user strings) and the
>       output formats used by tla (white-space separated fields etc).
> 
>   (2) It addresses the non-ascii character issue.
> 
> (1) is a limited problem, and reasonably easy to work around and support.
> Escapes added to solve this problem are easy to decode, and I can deal with
> them.

Except 'I can work around them' is thinking a too small yes? At least
the picture I'm getting is something grander, and I really do recommend
reading Hans Reiser's namespace paper(s) (namesys.org?).

>   (2) is much more difficult problem, and I certainly don't want (or
> need) to deal with it if tla _already has the code to do it_.

But as soon as tla does handle it nicely, then we as scripters want tla
to interact with various other tools, utilities, etc. And I think this
is the point Tom is getting at. A wholistic approach. > just tla.

> Now, if there were an `xxargs' that decoded tla's escaping, presumably _it_
> could convert from the current "fully-escaped" format to "half-escaped"
> format, and I could use that.  But would simply be a re-implementation of
> functionality already present in tla.

Or perhaps pc, the PikaConvert utility, which can convert between pika
escaping, plain ascii (with limitiations, etc), xargs -0 format, your
suggestion of a cut-down pika escaping, etc, etc.

Then, we don't need xxargs (or it would just be a wrapper for
"pc|xargs"), _and_ we get the bonus of arbitrary support with
_random_unix_tool_. Scripting heaven yes?

> If such an external tool _did_ exist, as a scriptwriter, can I rely on this
> tool being present if tla is?  Does it become an extra dependency?

Distro/ packaging issues are totally orthogonal to the tools discussion.
Sure just a mere packaging issue?

cheers
zen




reply via email to

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