Subject: Re: CVS commit: src/bin/ls
To: None <source-changes@NetBSD.org>
From: Alan Barrett <apb@cequrux.com>
List: source-changes
Date: 04/09/2006 11:22:19
On Sun, 09 Apr 2006, Perry E. Metzger wrote:
> Jan Schaumann <jschauma@netbsd.org> writes:
> > 'ls -b' now yields foo\sbar (whitespace) foo\tbar (tab) foo\rbar (CR).
> > 'ls -B' now yields foo\040bar foo\011bar foo\015bar.
> 
> Hrm. \s isn't read by the shell. "\ " is.
> 
> Having -b do things like "\ " means you can feed the output of ls -b
> into the shell and actually get the right file even if it has spaces
> etc. in it.

Yes, for the special case of "\ ". Not for arbitrary non-graphic
characters.

> I think that's a valuable application. Even C doesn't
> parse \s so far as I know...

With the current scheme, you'll have to use something like

    mv "$(printf '%s' 'name escaped via ls -[bB]' | unvis)" newname

but that was already true before the recent changes.
(Hmm, it would be nice if vis and unvis took "-s string" flags.)

I see ls -[bB] as mainly for human consumption, where what I want is
something that's unambiguous, easy to understand, and difficult to
misinterpret.  "\ " works for that, but it's not one of the encodings
produced by strvis.

--apb (Alan Barrett)