Re: CVS commit: src/bin/ls

["Perry E. Metzger" <perry%piermont.com@localhost>]

Alan Barrett <apb%cequrux.com@localhost> writes:
> On Sun, 09 Apr 2006, Perry E. Metzger wrote:
>> Jan Schaumann <jschauma%netbsd.org@localhost> 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.

The strvis man page doesn't indicate that \s is a supported encoding,
either. Where is that coming from?

Perry