Skip to main content
Unix & Linux

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

Required fields*

7
  • I can't test/write it all up right now, but what about piping the files through 'od -c' or xxd, from which you could then grep the corresponding codes? Commented Feb 7, 2016 at 1:28
  • Sounds like a good idea, but I should see some sample line first instead of blind fiddling. Plus, it would be great to keep using strings, because with big files it will already have filtered so much garbage before grep even gets its first attempt to process the content. Commented Feb 7, 2016 at 1:31
  • 1
    Would omitting strings and using something like grep -waoP 'XYZ\x00' work? Commented Feb 7, 2016 at 11:05
  • @MarkPlotnick Indeed it would, however there appears to be a general problem with \xAA hex codes in the grep regex. Spotted lots of similar questions here on SE. Users occasionally had to work around it by greping for 'XYZ'$'\x00', i. e. using the built-in trickery of some (not all!) shells. Maybe hex codes in grep will only work reliably in GNU grep? Besides: -a is discouraged, as it might wreak havoc on a terminal due to the shell interpreting some of the control codes as actual ones. So these might clear your screen, deface output strings, insult your mother...;-) Commented Feb 7, 2016 at 18:08
  • Yes, some of these options are only supported by GNU grep. -a isn't a problem here, since we give grep the -o option; -a would only cause control codes to be displayed if your grep regexps matched control codes, which they won't. The -P option allows NUL to be specified as \x00 in the regexp, as 4 ordinary characters, no shell magic required. Commented Feb 7, 2016 at 19:30