Re: find -print output escaping not documented?

[James Youngman]

On Fri, Jan 10, 2014 at 8:20 PM, Bob Proulx <address@hidden> wrote:
>
> Undocumented behavior.  Here is the test case:
>
> mkdir /tmp/testdir
> mkdir /tmp/testdir/"newline
> newline"
>
> find /tmp/testdir -print
> /tmp/testdir
> /tmp/testdir/newline?newline
>
> Note the '?' in the above.  No '?' in the below that is redirected.
>
> find /tmp/testdir -print | head
> /tmp/testdir
> /tmp/testdir/newline
> newline
>
> If stdout is a tty then the newline is mapped to '?'.  But it isn't
> mapped if the output is redirected to a pipe or a file.  This applies
> to the printf %p format too.


 Yes.  This is deliberate in the sense that the code does this
deliberately.   I didn't remember perpetrating this inconsistency, but
the git log clearly shows that it was me in change
296989f629a52e1122af688b9d4ddb90f14914b8:(


> This behavior appears to be undocumented.  At least I couldn't find a
> reference to behavior differences based upon the output being a tty or
> not.

The fact that this is undocumented is also somewhat deliberate.
Different parts of GNU find do this in slightly different ways.  For
example -ls does something similar, but not in quite the same way.
This is confusing and frustrating.   It would be good to harmonise and
formalise this better.   This is the reason I have not documented the
existing, suboptimal, situation.

This problem is mentioned obliquely in the Texinfo documentation:

3.2 Print File Information
==========================
[...]
       9. The file's name.  `-ls' quotes non-printable characters in the
          file names using C-like backslash escapes.  This may change
          soon, as the treatment of unprintable characters is
          harmonised for `-ls', `-fls', `-print', `-fprint', `-printf'
          and `-fprintf'.


> I looked over  
> http://pubs.opengroup.org/onlinepubs/009695399/utilities/find.html
> and couldn't find anything allowing this behavior either.
>
> Did that character mapping sneak in unintentionally?

No.  I implemented it myself, I would now say in an unwise way, for
https://savannah.gnu.org/bugs/?13303

I think this functionality should be reworked a bit to make it saner.
Unfortunately I am unlikely to get to this in the near future.

James.