Re: problems with file names containing \n

[Andreas Metzler]

On 2004-05-07 Werner LEMBERG <address@hidden> wrote:
> [strash 0.9
>  find 4.1.7]

> I've managed somehow on my GNU/Linux box to have a file name which
> contains a newline character.  `find -ls' reports this:

>   478966    4 -rw-r--r--   1 sx0005   users         209 Apr 27 00:17 \
>     ./SYSTEM_ROOT/usr/local/home/sx0005/KS09.wmv?MSWMExt=.asf\n

> Doing e.g. `find . -printf "%p\n"' I get

>   ./SYSTEM_ROOT/usr/local/home/sx0005/KS09.wmv?MSWMExt=.asf

> followed by a *two* real newline characters.

Of course.

> Such a file name makes strash fail with

>   /usr/local/bin/strash: [: -lt: unary operator expected

> since it doesn't expect real newlines.

> While it isn't a bug per se that find's `%p' converts the file name's
> newline character into a real one,

Find does not "convert" anything. You asked to print "filename
followed by a additional newline" and find followed your advise to the
point.

> it is a missing feature IMHO that
> there is no possibility to suppress this behaviour.  I thus suggest a
> modifier to %p and friends which makes the output similar to -ls,
> e.g. `%lp' (`l' as the mnemonic for `ls').

What is strash? Could it really handle this, i.e.
strash 'foo\nbar'
will try to access
'foo
bar'
and not the file named "foo backslash n bar"? (That is how any sane
program would behave?) How would you access a files name 'foo\nbar'
with strash?

The usual GNU-way for this issue is to modify the program in question
(strash) to accept a NUL delimited list like sort -0 does.
           cui andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"