3

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
// PHP code shown by text tools on the command line

__halt_compiler();

// 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.

5
  • Just use the "considered harmful" cat -v. It's not clear what you mean by "spoofing" eof -- you could just sed /ugly/q file.
    – user313992
    Sep 7, 2019 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. Sep 7, 2019 at 23:52
  • @mosvy However, many thanks. That's a good suggestion for my own daily work on the command line. Sep 7, 2019 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. Sep 8, 2019 at 0:04
  • perhaps you need to use a terminal that does not "understand" control codes
    – jsotola
    Sep 8, 2019 at 0:44

1 Answer 1

5

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:

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

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.

8
  • 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? Sep 8, 2019 at 0:59
  • And do you know which terminal standard does define this? VT52, VT100? Sep 8, 2019 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, 2019 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, 2019 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. Sep 8, 2019 at 1:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .