bugfindutils - Bugs: bug #50606, Garbage printed with "no such...


bug #50606: Garbage printed with "no such file or directory"

Submitted by:  Jim Carter <jimc>
Submitted on:  Tue 21 Mar 2017 10:01:29 PM UTC  
Category:  find Severity:  3 - Normal
Item Group:  Wrong result Status:  Invalid
Privacy:  Public Assigned to:  None
Originator Name:  jimc@savannah.gnu.org Open/Closed:  Closed
Release:  4.5.12 Fixed Release:  None

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


Mon 03 Apr 2017 09:36:04 PM UTC, comment #5: 

You could also try coping and pasting the characters into a service like https://r12a.github.io/uniview/

James Youngman <jay>
Project Administrator
Mon 03 Apr 2017 06:33:06 PM UTC, comment #4: 

As an aside, when garbage characters show up where text is expected, and especially if ordinary ASCII characters seem to be coming through OK, it's often worth checking whether you're seeing non-ASCII characters encoded with UTF-8.  I wind up doing this once or twice a year.

Of course, you can't memorize the Unicode table, but you can remember the way to translate:  First, figure out what the actual bytes are.  (The OP did an admirable job of this, showing which bytes had the high bit set.)  Decode them into their bits.  Now interpret those bits using the UTF-8 encoding (https://en.wikipedia.org/wiki/UTF-8) to find out what the character numbers ("code points") are.  Then look them up in the Unicode roadmap (http://www.unicode.org/roadmaps/bmp/).

Dale Worley <worley>
Tue 28 Mar 2017 06:29:17 PM UTC, comment #3: 

Thanks for the explanation; I would not have figured that out
since I don't have the Unicode table memorized.  The output of
"find" is mailed to the admin host and ends up as part of a
web page, so MIME cleanliness is potentially possible but
screwups are likely.  I'll have to go through the chain of
programs that handle the report and try to spot what repudiates
UTF-8.  It looks like another workaround is to set LC_ALL=C
where "find" gets run. 

In any case I'm marking the bug as resolved (assuming I figure
out which field to alter). 

Jim Carter <jimc>
Wed 22 Mar 2017 02:08:19 PM UTC, comment #2: 

To be more exact, the two garbage sequences result from 'find' printing the Unicode characters "LEFT SINGLE QUOTATION MARK" (hex 2018) and "LEFT SINGLE QUOTATION MARK" (hex 2019) (see http://www.unicode.org/charts/PDF/U2000.pdf) by outputting the bytes that represent them in the UTF-8 encoding, E2 80 98 and E2 80 99. Your terminal interprets those sequences of bytes as being encoded in a one-byte ASCII code.

Dale Worley <worley>
Tue 21 Mar 2017 10:48:30 PM UTC, comment #1: 

Most likely, that is not garbage, but a mismatch in your terminal and your locale.  find is trying to use UTF-8 quote characters around the file name that is missing, but your terminal doesn't understand how to display those characters.  If 'LC_ALL=C find /nonexistent -print' doesn't have the same problems, then the bug is that you are using a locale that pretends to have UTF-8 support when your setup does not really honor that locale due to your inferior terminal, and not a bug in find itself.

Eric Blake <ericb>
Project Administrator
Tue 21 Mar 2017 10:01:29 PM UTC, original submission:  

This is for findutils-4.5.12 from OpenSuSE "Leap" 42.1.  When I do:
find /etc/acpi /nonexistent -print > /tmp/find.out 2>&1
cat -v /tmp/find.out
It prints the filenames in the existing directory, plus on
stderr it prints
find: M-bM-^@M-^X/nonexistentM-bM-^@M-^Y: No such file or directory
When output is sent direct to the terminal we do not see
^@ ^X or ^Y but very likely they are being written.  "cat -v"
is needed to show the incorrect output consistently.  Any
existing directory can be used to demonstrate the bug. 

Jim Carter <jimc>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by jay (Posted a comment)
  • -email is unavailable- added by worley (Posted a comment)
  • -email is unavailable- added by ericb (Posted a comment)
  • -email is unavailable- added by jimc (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-09-01 jay StatusNone => Invalid
        Open/ClosedOpen => Closed

    Back to the top

    Powered by Savane 3.5