Ubuntu QA:
BlogBrainstormPackage status
Log in
Ubuntu QA
The Ubuntu community has contributed 13963 ideas, 66846 comments, 1291785 votes

Idea #4972: Prevent console from getting garbled



up
5
down
Written by Eldmannen the 18 Mar 08 at 00:50. Category: Others.
Related to: Nothing/Others. Status: New
Description
Sometimes when you use the console or terminal todo stuff, like for example 'cat' a (binary) file, then the characters in the terminal might get garbled.

Make some thing that prevents it from getting garbled.
Tags: console

Attachments
No attachments.


Duplicates


Comments
XSP wrote on the 18 Mar 08 at 00:59
Okay. I think you are screwing with people's heads now. lol

cat streams and joins files. For instance:

cat file1 file2 >file1and2

By not specifying an output, it will output to the screen.

Eldmannen wrote on the 18 Mar 08 at 01:03
If I type example "cat file.bin" then my console may get garbled.

XSP wrote on the 18 Mar 08 at 01:08
Maybe the better solution would be for Ubuntu to point users to the manpages.

man cat

CAT(1) User Commands CAT(1)

NAME
cat - concatenate files and print on the standard output

SYNOPSIS
cat [OPTION] [FILE]...

DESCRIPTION
Concatenate FILE(s), or standard input, to standard output.

-A, --show-all
equivalent to -vET

-b, --number-nonblank
number nonblank output lines

-e equivalent to -vE

-E, --show-ends
display $ at end of each line

-n, --number
number all output lines

-s, --squeeze-blank
never more than one single blank line

-t equivalent to -vT

-T, --show-tabs
display TAB characters as ^I

-u (ignored)

-v, --show-nonprinting
use ^ and M- notation, except for LFD and TAB

--help display this help and exit

--version
output version information and exit

With no FILE, or when FILE is -, read standard input.

Auzy wrote on the 18 Mar 08 at 01:59
Huh XSP..

Eldma is 100% right. If you cat some binary files for instance, it corrupts the shell and you need to reset it.

Its a known issue and has been a known issue for ages.


Sometimes people accidentally do it when coding for instance, you accidentally cat your binary instead of your output (this generally happens at the same time you start littering your code with printf's with swear words trying to work out wtf is going on). I think also at some time, someone proved this could be exploited somehow (but I never read how).

In fact, if Microsoft had done this, I'd have to put up with listening to a bunch of morons parading that Microsoft made a mistake. The odd thing is, this was a long standing issue.


So +1, not sure if it had been fixed (Last I got into that situation was 2 years ago). But either way, it should not happen. This bug should not be overlooked.

XSP wrote on the 18 Mar 08 at 02:49
When you are using a binary file with cat, you pass:
cat | od -c

This will output in hex. cat has no way of knowing the input file's mime type. It simply takes any data and outputs it either to the screen or a file.

Eldmannen wrote on the 18 Mar 08 at 02:58
I am not saying that it is a flaw in cat.
cat probably does exactly what it should.

But maybe the shell could run some "fix" routine thing or something after commands or when it detects things get garbled.

glibik wrote on the 18 Mar 08 at 03:00

If you are simply trying to view the contents of
a text file on the console, then the appropriate
tool is either "more" or "less".

When attempting to view a binary file, "less" will
warn of such and ask if you want to continue.

As has been commented, "cat" is for conCATenating files.

Auzy wrote on the 18 Mar 08 at 03:26
Look, the point isn't how to view binary files (theres little reason why people would want to in an open source environment). And it isn't to warn people not to do it that way.

Its to fix it properly, so if you accidentally do display a binary file, there are no issues. Otherwise, even whilst coding, you might accidently fopen the wrong file, display it, and corrupt the terminal. Warnings and using other programs don't fix the problem fully.

I didn't know linux was in the business of fixing symptoms of an issue rather then fix the underlying issue. I cant believe people are suggesting stuff that can only be compared as "patching a png exploit in firefox, by telling people not to go to pages with a png file in it".

This is turning into a poor joke now. Cat isn't just for concatination (I personally do not give a s#*^ what the man file says). There are lots of shell scripts out there which use it for viewing, and there is no reason why users cannot.


And you can still corrupt the terminal without using cat.

ay wrote on the 18 Mar 08 at 06:49
um... just type "reset" and hit enter. Almost always, you'll have your shell back.

I can't believe that this is considered an issue... the shell and tools are doing exactly what you're telling them to do!

Auzy wrote on the 18 Mar 08 at 07:46
Why isn't it?

They aren't doing what you want them to.. Cat binary data, terminal goes corrupt. Reset is just a way of cleaning up after the issue has occurred. I find it hard to believe this is within specs. How is being unable to read bash prompt anymore within specs?


XSP wrote on the 18 Mar 08 at 20:29
Okay. I'll try to explain a bit better. catting binaries to the terminal shouldn't be done. It's not cat however that is the culprit here. It's your terminal.

When the terminal was expanded to handle IBM extended characters, the screen corruption was a nasty side effect. cat was designed around the vt terminal which didn't have extended characters and it would return normally.

What's happening here is that a few bytes in that binary are sending a ^n which switches the terminal into extended mode causing the corruption. ^o returns it to normal mode.

cat is doing exactly what it was designed to do. Stream the output of one or more files, to either the terminal window or a new file.

Eldmannen wrote on the 19 Mar 08 at 02:17
I don't blame cat.

But the terminal should detect if its garbled, and fix itself.

fwolfste wrote on the 31 Mar 08 at 07:53
I guess nowadays the ubuntu user does not want to switch the terminal modes. I do not know where to put a switch, but i would suggest, that standard behaviour shouldnt send (or if its the terminal, shouldnt accept) terminal mode switches and maybe other control sequences until switched on.
summary: if this were to be implemented in cat and not in the shell, "cat binarayfile" doesnt corrupt the shell but "cat -ancientmode binaryfile" does.


Post your comment