51

This is how my bash prompt used to look like.

old bash prompt

Then I did something which was probably not so smart, I did cat /bin/bash. And now my bash prompt looks like this, with a pound symbol (£) instead of a hash symbol (#). It even affects hash symbols within files, see here:

pound symbols in files

Any Idea how to revert this?

Edit: This question does not ask "How to change my bash prompt?", but "my bash prompt changed by itself, how can I restore it?"

Complete .bashrc for those who are interested.

lhermann
  • 643

6 Answers6

110

The terminal accepts and executes a bunch of different character sequences as control commands. For example, all cursor movement is done using those. Some of the codes make permanent changes, like setting colors, or telling the terminal to use an alternate character set. Executables and other binary files can well contain bytes that represent those commands, so dumping binary files to the terminal can have annoying side effects. See e.g. here for some of the control codes.

The historical background to this is that originally, terminals were rather dumb devices with a screen and a keyboard, and they connected to the actual computer via a serial port. Before that, they were printers with keyboards. There wasn't much of a protocol to separate data bytes from command bytes, so commands were given to the terminal "inline". (Or rather, the escape codes and control characters were the protocol.) One might assume that if the system was devised today, there would be clearer separation between data and commands.

Instead of just closing the terminal window or killing the emulator, you can use the reset command, which sends a similar command (or several) to reset the terminal back to sane defaults.

I don't know what exactly would cause the hash to pound change. (But @Random832 does, see their answer.) I'm more familiar with the "alternate character set", which can change all characters into line-drawing glyphs. Even if that happens, input from the keyboard usually goes through unchanged, so writing resetEnter still works even if the characters display as garbage or not at all. (Compared to your prompt being turned into a bunch of lines, you only got a minor effect.)

Community
  • 1
ilkkachu
  • 138,973
  • 1
    Thank you for the detailed explanation. I will up vote as soon as I have the reputation necessary. – lhermann Aug 10 '16 at 13:01
  • 2
    When I first tried cat /dev/urandom in the Debian installation console (screen resolutions that bring bricked hardware to mind), I thought I'd triggered an overflow, and quickly navigated my way to the "abandon all changes, restart machine" button. Now I know it's an "intended feature". – wizzwizz4 Aug 10 '16 at 17:52
  • 3
    It's a historically intended feature that's undesirable now. Some (all good) terminal emulators should disable the legacy character-set-switch escapes when running in a UTF-8 environment, but whether they do so, and how you activate the option to do so if it's not default, is poorly documented and varies. – R.. GitHub STOP HELPING ICE Aug 13 '16 at 15:39
86

For the record, to answer why this happened and how it could have been fixed without closing the terminal (and if reset failed):

Many terminals support, as a feature of the VT220 terminals they are emulating, a number of national replacement character sets based on ISO 646 and ISO 2022. In particular, it is very common for some reason, even if the others aren't supported, for them to support the British character set, which has the pound currency symbol in the same position where ASCII has the number sign.

So, when you printed a binary file to the terminal, it by some coincidence output the sequence ESC ( A [or perhaps ESC ) A and ^N] to the terminal. This can be undone manually by printing the sequence that sets it to the normal status:

printf '\e(B\e)0\x0f'
Random832
  • 10,666
  • I guessed something like this, without knowing the particulars. Thank you for the explanation. How great to have people like you around! – lhermann Aug 10 '16 at 14:57
  • 1
    Oh dear, the seagulls in place of Ä and Ö... And Terminal on OS X even supports that replacement, in 2016. If I only had another upvote to give. – ilkkachu Aug 10 '16 at 15:40
  • @ilkkachu some terminals that otherwise support them (I know Putty, and I think also the Linux console) reject them when UTF-8 is in use, because ISO 2022 says that other sequences (other than ESC % @) shall not be supported while in the state that is used to support UTF-8. So they might fade away eventually as more applications are forced to use UTF-8 for line drawing [which is the most widely used actual use of this feature, the other character sets mostly being included because it's "free" when you have the mechanism implemented]. – Random832 Aug 10 '16 at 15:47
  • @Random832 Yes this would be the "proper" behavior, but alas, as you can see in PuTTY, it often breaks line drawing characters in apps. It's a legacy that terminals will probably carry for another while. – egmont Aug 10 '16 at 19:26
  • 21
    It's easy to remember these escape sequences: "A" stands for British, "B" stands for "American" :D – egmont Aug 10 '16 at 19:26
  • 8
    @egmont I dug into this, as it turns out, they're assigned sequentially in the order they were registered with the ISO. The first is the old international reference version [with ¤ for $] is @, and then the british version happened to get in before the american one. https://www.itscj.ipsj.or.jp/itscj_english/index.html for a list of all of them. – Random832 Aug 10 '16 at 20:54
  • 1
    This is a much better answer than the accepted one. Thanks, I always wondered about things like this. – Wildcard Aug 14 '16 at 20:07
  • This is not going to be of any help to me: not only does the # become a pound symbol, but \ becomes a # ... and a few other replacements. The reset command doesn't work, and neither does stty sane. – Mei Aug 30 '18 at 19:34
  • @Mei Are you sure you didn't change your keyboard layout? This is different from the terminal character set, and can't be caused by cat of a binary file. What desktop environment are you in? – Random832 Aug 31 '18 at 16:38
29

Close the terminal and open a new one.

  • That's it! Now I feel a little stupid. If every problem were solved so easily ... – lhermann Aug 10 '16 at 12:43
  • 19
    You shouldn't. The question is valid. Maybe someone will explain why this happened in detail. This must be a hole in Bash. £ sits under the same key as # only it's called with Alt. Somehow the Alt stayed in Bash. Anyhow, you can wait for a proper explanation, or if you are satisfied with my answer, click the check to accept it. –  Aug 10 '16 at 12:50
  • 1
    Or rather not in Bash, but in the terminal program. I tried the same on a command line outside the GUI and it loops forever. –  Aug 10 '16 at 12:55
  • .bashrc is a text file. Simply listing the contents should not affect your shell. Both @antix and tomas have further issues in their systems. – Jeter-work Aug 10 '16 at 14:34
  • 5
    @Xalorous, the question states that the problem appeared when he cated /bin/bash to the terminal. – ilkkachu Aug 10 '16 at 14:37
  • 2
    Random832 gave a good explanation of what actually happened – lhermann Aug 10 '16 at 14:59
  • 16
    This is overkill - what if you have some state in your session that you want to keep? What if it's a console rather than an X terminal? reset is the right tool for the job. – pericynthion Aug 11 '16 at 06:02
  • reset may fail. As it did when I tried it. –  Aug 11 '16 at 06:07
  • @tomas this is not a "hole in bash" or the terminal program; both are doing what they're supposed to - responding to what codes they're given. reset is the command to, well, reset things, so it should be your first port of call. £ and # aren't the same keys on everyone's keyboard, either. – moopet Aug 12 '16 at 13:58
  • I know that now from the other answers. –  Aug 12 '16 at 14:06
  • @moopet Anyhow, when my console cats /bin/bash, it loops forever. So there may be some malfunction involved. –  Aug 12 '16 at 15:32
17

Just execute reset in your session.

user1700494
  • 2,202
11

stty sane seemed to fix the problem as well as reset did.

cat
  • 3,468
  • 4
  • 23
  • 51
8

There is no need of closing and re-openning or reseting your terminal! Although reseting will work this is not the proper way!

You just need to clear/erase your terminal scrollback buffer. To do so, just use the command below:

$ echo -ne '\0033\0143'
  • This one seems more logical to me, Thanks. – Parsa Samet Aug 11 '16 at 12:33
  • 1
    Do you have an explanation for this miracle? –  Aug 11 '16 at 13:00
  • 1
    @tomas Yes mate for sure. when -e is in effect, it will recognize some sequences you can read about by running man echo, one of them is \0NNN which stands for byte with octal value NNN. In fact, you do not need to RESET your terminal session, you just need to CLEAR your scrollback buffer. And the command I said will do the required job. For instance, if you're using MacOS X, there is a Edit in menu bar while using terminal, and there is an option as "Clear Scrollback or ⌥⌘K". –  Aug 11 '16 at 13:19
  • 5
    The sequence \033\143 is ESC c, Reset to Initial State: "Reset the VT100 to its initial state, i.e., the state it has after it is powered on. This also causes the execution of the power-up self-test and signal INIT H to be asserted briefly." – deltab Aug 11 '16 at 13:27
  • 1
    @deltab I forgot to mention about ESC, thanks a million mate. –  Aug 11 '16 at 13:30
  • This I can understand. But what catting /bin/bash causes at my terminal is that when I press Shift+3 I get the £. Without pressing the Alt, which I normally need. I this is not just once. I can produce whole series of £. So what's going on there? And your trick cancels this misbehavior. Well, why? –  Aug 11 '16 at 13:35
  • Ok, now it's clearer. –  Aug 11 '16 at 13:39
  • 2
    @tomas Whenever you try to display a file which is not supposed to be displayed - for instance binary files - terminal will act odd and awkward. Many Linux users do the reset, but that's not the best option since there is no need of reseting terminal session, and clearing scrollback buffer is all needed. –  Aug 11 '16 at 13:44
  • @tomas I'm glad. –  Aug 11 '16 at 13:45
  • Just wondering how scrollback affects the characters I produce from my keyboard. Can it start turning them into Chinese ideograms as well? –  Aug 11 '16 at 13:46
  • I'm not that expert about what happens in kernel, so I cannot explain it, but opening binary files by tools like less, more, cat, tac etc., and treat them as a common file will crash the screen. It's good that yours was only pound sign, sometimes it will be more odd! –  Aug 11 '16 at 13:51
  • 1
    The echo -ne '\0033\0143' will reset your terminal, not just clear the scrollback buffer. Most GUI terminals have reset feature in the menu, too, so you don't need to remember the code to enter. Also, the -e flag is non-standard for echo so you really should write printf "\033\143" instead if you have POSIX-compatible system. – Mikko Rantalainen Mar 12 '19 at 11:33