Error in man page, re: -printf \ escape

Bug #68852 reported by Ben Blout on 2006-10-28
10
Affects Status Importance Assigned to Milestone
findutils (Ubuntu)
Low
Unassigned

Bug Description

Binary package hint: findutils

Hi,

In the findutils package 4.2.22-2, installed on a 'Breezy' machine, the man page states, under the section for '-printf':
              \v Vertical tab.
              \ ASCII NUL.
              \\ A literal backslash (`\').
I believe the '\ ASCII NUL.' entry is wrong. Despite repeated attempts to use this feature, I failed. I eventually found that the information obtained by the command 'info find' differs on the available escapes for the -printf option. The same documentation for the -printf command, taken from the 'info find' command on the same Breezy system reads:
      3.2.1 Escapes
      -------------
      <snip>
      `\v' Vertical tab.
      `\\' A literal backslash (`\').

As you can see, the '\' option is not listed.

Indeed, in my testing, this works:
find . -iname "a*" -print0 | xargs -0 du -h
This works, using octal 000 to get a null character:
find . -iname "a*" -printf '%f\000' | xargs -0 du -h
but this does not work:
find . -iname "a*" -printf '%f\' | xargs -0 du -h

Thanks!

Ben

Related branches

Ben Blout (bdb-new) wrote :

Still present in Dapper!

man find gives the (apparently) wrong information.
info find give the correct information

Daniel Hahler (blueyed) wrote :

This looks like a conversation error when creating the man page..

It should read:
\0 ASCII NUL

In fact, using '\0' seems to be a shortcut for '\000'.

In find.1.gz it says "\e\0", which gets displayed just as "\" (and ASCII NUL probably), while using "\e0" would result in "\0" when using "man".

It looks like a bug in the conversation from find.texi into the man page (texutils?).

Changed in findutils:
status: New → Confirmed
Ben Blout (bdb-new) wrote :

Still present in Hardy

Daniel Hahler (blueyed) on 2008-01-22
Changed in findutils:
importance: Undecided → Low
status: Confirmed → Triaged
Bobby R. Ward (bobbyrward) wrote :
Daniel Holbach (dholbach) wrote :

Evan: can you please take a look at it?

Siegfried Gevatter (rainct) wrote :

Hey,

Looks quite good, just a little suggestion about the changelog entry: replace "* find/find.1:" with "* patches/01_nullescape.dpatch, patches/00list:", as those are the files that you modified directly (and reference find/find.1 in the line below this one); otherwise reading just the changelog entry it seems like you modified the file directly, without using a patch, and if someone wants to know when the 01_nullescape patch was added he would have to read through all the changes to find it.

Also, consider adding the fix for bug #202431 to your patch so that both are solved with the same upload.

Ah, and don't worry that nobody said anything about your debdiff before, main is slow... ;).

Ben Blout (bdb-new) wrote :

Is there a reason that this is being patched, rather than reported to upstream? Or am I confused, and the debdiff will somehow magically head upstream?

Siegfried Gevatter (rainct) wrote :

Ben: The patch will be (manually) forwarded to upstream so that it can be dropped from Ubuntu once it's there.

Bobby R. Ward (bobbyrward) wrote :
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package findutils - 4.4.0-2ubuntu3

---------------
findutils (4.4.0-2ubuntu3) intrepid; urgency=low

  * fixes for find/find.1:
    - fix escape of null character for the \0 option in find/find.1
      (LP: #68852)[debian/patches/11_nullescape.dpatch]
    - fix "seach" typo in find/find.1
      (LP: #202431)[debian/patches/12_seachtypo.dpatch]

 -- <email address hidden> (Bobby R. Ward) Wed, 02 Jul 2008 23:26:41 -0500

Changed in findutils:
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers