I'ld like to hide ugly data from being shown by command line tools like cat (and maybe simple text editors too) which often get confused by binary data. For example a VT100 terminal sometimes gets misconfigured by binary outputs.

// PHP code shown by text tools on the command line


// here some fake EOF mark for simple text processing tools
// hidden ugly data

Can end of file be spoofed to simple stream-based text viewer tools, especially to the linux command line tools (but maybe also to some windows tools)?

I am looking for a solution from within the mixed text/binary file, so that other people using cat or similar do not get trash on their screen.

  • Just use the "considered harmful" cat -v. It's not clear what you mean by "spoofing" eof -- you could just sed /ugly/q file. – mosvy Sep 7 '19 at 23:51
  • I see, the question hasn't been clear enough yet. I am thinking about a solution from within a mixed text / binary file. – Quasimodo's clone Sep 7 '19 at 23:52
  • @mosvy However, many thanks. That's a good suggestion for my own daily work on the command line. – Quasimodo's clone Sep 7 '19 at 23:59
  • @mosvy By "spoofing eof" I mean some control character or similar indicating end of file/end of text stream to simple text-processing tools without affecting the file system or any binary tool. – Quasimodo's clone Sep 8 '19 at 0:04
  • perhaps you need to use a terminal that does not "understand" control codes – jsotola Sep 8 '19 at 0:44

One 'solution' would be to use the alternative screen buffer which many (but not all) terminals support. Consider the following command:

printf "Hello, \e[?1049h ABCDEFG \e[?1049l World\n"

On a terminal supporting alternative screen buffers, you would see

Hello,  World!

possibly with a very sudden flash of the terminal.

The \e[?1049h sequence will cause the terminal to switch to the alternative screen buffer, where everything printed afterwards will end up. The \e[?1049l sequence switches back to the main screen buffer.

An example with php:

echo "Hello";
// Nothing to see here...^[[?1049h
echo ", World!\n";

where ^[ represends the escape character.

The alternative screen buffer is used by many programs which like to create terminal user interfaces, but want to restore the contents of the terminal after closing. This is how less can display contents using the entire window, but upon exiting, all of the previous commands are still visible. If you have unbuffer installed, you can verify this:

$ unbuffer less -f /dev/null | xxd
00000000: 1b5b 3f31 3034 3968 1b3d 0d0d 1b5b 4b1b  .[?1049h.=...[K.

as you can see, the first thing printed is \x1b[?1049h which causes the terminal to switch screen buffers.

This would not work on any editor (that I'm aware of) since most editors do not attempt to display non-printable characters.

  • Could you also explain what the alternative buffer actually is for? Can there occur any side-effects? I guess one could flush the buffer later onto screen as well with some escape sequence which might be the intended default usage? – Quasimodo's clone Sep 8 '19 at 0:59
  • And do you know which terminal standard does define this? VT52, VT100? – Quasimodo's clone Sep 8 '19 at 1:06
  • 1
    @Quasimodo'sclone I've edited the answer to mention usage. I'm not sure what you mean by side effects. If the terminal was already on the alternative screen buffer then the final ^[[1049l will cause it to return to the main screen buffer – Torin Sep 8 '19 at 1:13
  • 1
    @Quasimodo'sclone I'm not sure about terminal standards, but Wikipedia lists it as a "popular private sequence" – Torin Sep 8 '19 at 1:14
  • 1
    The explanation given is incorrect: when xterm saves/restores the cursor while switching, it (as a side-effect) saves/restores some of the video attributes. – Thomas Dickey Sep 8 '19 at 1:27

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.