41

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.

  • 2
    Possible duplicate of How to change the prompt in Linux? – Kevdog777 Aug 10 '16 at 15:08
  • 1
    (I took the liberty of editing the title a bit to bring up what caused the problem. Edit or revert as you like.) – ilkkachu Aug 10 '16 at 15:30
  • 8
    The prompt, file etc. still contain the character code for #, \x23; it's just that the terminal now interprets \x23 as £. – deltab Aug 11 '16 at 13:32
  • 4
    The interesting part is that "pound" is another name for the hash symbol in American (and possibly other nationalities?) English... =) – jpmc26 Aug 11 '16 at 22:15
  • 1
    What terminal program was this done in? – SnoringFrog Aug 12 '16 at 13:53
101

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

  • 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
  • 2
    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.. Aug 13 '16 at 15:39
77

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'
  • 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
  • 18
    It's easy to remember these escape sequences: "A" stands for British, "B" stands for "American" :D – egmont Aug 10 '16 at 19:26
  • 7
    @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. itscj.ipsj.or.jp/itscj_english/index.html for a list of all of them. – Random832 Aug 10 '16 at 20:54
32

Close the terminal and open a new one.

  • 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. – Tomasz 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. – Tomasz Aug 10 '16 at 12:55
  • 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 6:02
16

Just execute reset in your session.

9

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

7

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'
  • 1
    Do you have an explanation for this miracle? – Tomasz 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". – FarazX 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. – FarazX Aug 11 '16 at 13:30
  • 1
    @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. – FarazX Aug 11 '16 at 13:44

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.