Re: find -print output escaping not documented?

[Bob Proulx]

James Youngman wrote:
> Bob Proulx wrote:
> > 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:(

I have those experiences more and more lately myself.  :-(

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

If this were in the manual it would have saved me some time.  Here is
the story.  I wanted to use find on a directory tree of backup files.
I worried that there would be arbitrary file names in the tree.  I
tested find on a problematic case.  I picked a short list so of course
I simply wrote it to the terminal.  Due to the character protection
there were no problematic files in the output.

I had become convinced that the backup software had mapped the names.
But of course I was fooled by find because it wasn't mapped in the
backup software it was mapped by find.  But I had tested specifically
for that case!  It's not fair.  Waah!  Read through the docs
carefully.  Go back and test carefully.  Spent an hour at least trying
to figure out what was happening.  Was this intention or
unintentional?  I decide to ask about it.

> 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 did read that section.  But the character mapping that I saw didn't
use C-like backslashes and so that section didn't describe what I was
seeing.  And also because I mistakenly didn't equate newlines with
non-printable characters.  My bad.  (But space is printable.  Hmm...)

I would simply say:

       9. The file's name.  `-ls' quotes non-printable characters in the
          file names using C-like backslash escapes.  If output is a
          tty then all of the print routines map non-printable
          characters for terminal safety.  Details of this may change
          in the future, 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

My comment concerning the standards docs were only because I was
looking for anything that would tell me what was happening or what
should be happening.  I am not actually concerned about this
particular point.  This is a fairly minor edge case.

Although I am not sure there is a need to escape these characters.
Because find isn't quite the same as ls.  With ls you expect some
protection of emitting random stuff to the screen.  But I haven't ever
expected that from find before.  I had rather expected find's output
to be verbatim.  I was surprised when it was not.

> I think this functionality should be reworked a bit to make it saner.

Put it into the it-would-be-nice category.  It is a minor edge case.
If I had found it in the docs then I would have known it was
intentional and not have even mentioned it.  I wouldn't give it much
priority.

> Unfortunately I am unlikely to get to this in the near future.

That is fine.  I understand what is happening now.  That is good
enough for me for this.  I am in the same situation.  There isn't
enough time for everything.  Have to prioritize.

Thanks!
Bob