Compare the following two commands:

mysqldump database_name --hex-blob -uuser_name -p | tee database_name_tee.sql
mysqldump database_name --hex-blob -uuser_name -p > database_name_out.sql

If I run the first, on completion I see the following on my terminal:

$ 62;c62;c62;c62;c

Where does this come from? Does it suggest that something has gone wrong somewhere in the process? Are these control characters which are being output for some reason?

U+0C62 is Telugu Vowel Sign Vocalic L, which I’m pretty sure is not part of my data, so I don’t think this is Unicode. Anyway, the sequence seems to be not c62 but 62;c. This could be a control character of some kind. And whatever is causing it is included in the output file. If I later cat either database_name_tee.sql or database_name_out.sql, I again see this sequence once the cat is complete.

tail database.sql -n200 does not produce this output; -n300 produces just $ 62;c62;c; and -n400 produces $ 62;c62;c62;c62;c. So whatever is causing this is distributed throughout the file.

Mucking around with head and tail, I found one of the culprits: a single line which, when saved to a separate file and printed with cat, produces $ 62;c62;c. My problem is that this single line is 1043108 bytes.

(The generated SQL file is perfectly fine, and runs without errors. I don’t think that this has anything to do with MySQL per se.)

I’m running the initial mysqldump on a CentOS server, and am seeing the same effects from cat on both the server itself and my Ubuntu desktop, so this seems to be a general Bash thing.

od -c problem_line produces 65174 lines of output, so I cut it down to a smaller section which demonstrates the same output (also available as a plain hexdump).

  • Could you post (or at least check, if it's too long) the output of od -c on the specific line you found? Just save the line in a text file and run od -c file. That should help us understand what those characters are. – terdon Mar 30 '16 at 11:29
  • @terdon. Thanks for the suggestion. Have added. – TRiG Mar 30 '16 at 11:34
  • Ugh. Could try narrowing it down a bit? One issue is that you have carriage returns (\r) in the file and those can cause characters to appear strangely (since they eat the characters that were printed before them, try printf 'foo\rbar'). You also have some weird numbers that probably shouldn't be there. Have a look at what is after S h a w n on line 0002260 of the od -c output. Can you extract the surrounding text and see if that reproduces the error? – terdon Mar 30 '16 at 11:45
  • Here's a much smaller section after playing around with head -cXX and tail -cXX. – TRiG Mar 30 '16 at 11:58
  • Yes, you have all sorts of weird characters just after </a>practice experiences. Some look like ANSI color escapes. In the output of od -c, any column that has more than one character (and isn't things like \n of \t etc.) is indicative of a problem, or an invisible character of some sort. I can't really tell you more unless you can provide the original file (or, at least, a small part of it that reproduces the error). – terdon Mar 30 '16 at 12:02

There are no escape characters in the octal dump (those would be 033).

There are a few 8-bit control codes (generally not implemented by most terminals other than xterm). The octal 232 is hex 0x9a, and (referring to XTerm Control Sequences):

     Return Terminal ID (DECID is 0x9a).  Obsolete form of CSI c  (DA).

CSI Ps c  Send Device Attributes (Primary DA).
            Ps = 0  or omitted -> request attributes from terminal.  The
          response depends on the decTerminalID resource setting.
            -> CSI ? 6 c  ("VT102")

The characters come from a response by the terminal to the DECID control character. The details of the response depend on the terminal emulator (which was not mentioned in the question).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.