Date: Tue, 26 Oct 2004 02:49:56 -0400
To: Zenaan Harkness <zen@cashpoolcomps.com>
Subject: Re: [Gnu-arch-users] Re: File naming conventions
Message-ID: <20041026064956.GA27041@fencepost>
References: <20041019060152.GC18852@wisq.net>
	<1098311382.11967.35.camel@nemesis.xlii.org>
	<1098313564.5336.29.camel@whiskas.cashpoolcomps.com>
	<vpqmzyhhrhi.fsf@ecrins.imag.fr>
	<1098319598.5336.46.camel@whiskas.cashpoolcomps.com>
	<20041021123218.GA30989@fencepost>
	<1098398014.5336.118.camel@whiskas.cashpoolcomps.com>
	<200410252009.i9PK9pP3066424@xl2.seyza.com>
	<buovfcy8eyf.fsf@mctpc71.ucom.lsi.nec.co.jp>
	<1098771438.3124.23.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1098771438.3124.23.camel@localhost.localdomain>
User-Agent: Mutt/1.3.28i
Blat: Foop
From: Miles Bader <miles@gnu.org>
Cc: arch <gnu-arch-users@gnu.org>
Precedence: list
Sender: gnu-arch-users-bounces+migo=homemail.com@gnu.org
Errors-To: gnu-arch-users-bounces+migo=homemail.com@gnu.org
Status: RO
Content-Length: 2040
Lines: 49
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.

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

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.  (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_.

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.

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?

-Miles
-- 
o The existentialist, not having a pillow, goes everywhere with the book by
  Sullivan, _I am going to spit on your graves_.


_______________________________________________
Gnu-arch-users mailing list
Gnu-arch-users@gnu.org
http://lists.gnu.org/mailman/listinfo/gnu-arch-users

GNU arch home page:
http://savannah.gnu.org/projects/gnu-arch/