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.

Improve this question
8
  • 2
    Possible duplicate of How to change the prompt in Linux?
    – Kevdog777
    Commented Aug 10, 2016 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
    Commented Aug 10, 2016 at 15:30
  • 9
    The prompt, file etc. still contain the character code for #, \x23; it's just that the terminal now interprets \x23 as £.
    – deltab
    Commented Aug 11, 2016 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
    Commented Aug 11, 2016 at 22:15
  • 1
    What terminal program was this done in?
    – SnoringFrog
    Commented Aug 12, 2016 at 13:53

6 Answers 6

Reset to default
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.)

Improve this answer
3
  • 1
    Thank you for the detailed explanation. I will up vote as soon as I have the reputation necessary.
    – lhermann
    Commented Aug 10, 2016 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
    Commented Aug 10, 2016 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
    Commented Aug 13, 2016 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'
Improve this answer
9
  • I guessed something like this, without knowing the particulars. Thank you for the explanation. How great to have people like you around!
    – lhermann
    Commented Aug 10, 2016 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
    Commented Aug 10, 2016 at 15:40
  • 21
    It's easy to remember these escape sequences: "A" stands for British, "B" stands for "American" :D
    – egmont
    Commented Aug 10, 2016 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. itscj.ipsj.or.jp/itscj_english/index.html for a list of all of them.
    – Random832
    Commented Aug 10, 2016 at 20:54
  • 1
    This is a much better answer than the accepted one. Thanks, I always wondered about things like this.
    – Wildcard
    Commented Aug 14, 2016 at 20:07
29

Close the terminal and open a new one.

Improve this answer
11
  • 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.
    – user147505
    Commented Aug 10, 2016 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.
    – user147505
    Commented Aug 10, 2016 at 12:55
  • 5
    @Xalorous, the question states that the problem appeared when he cated /bin/bash to the terminal.
    – ilkkachu
    Commented Aug 10, 2016 at 14:37
  • 2
    Random832 gave a good explanation of what actually happened
    – lhermann
    Commented Aug 10, 2016 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
    Commented Aug 11, 2016 at 6:02
17

Just execute reset in your session.

Improve this answer
11

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

Improve this answer
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'
Improve this answer
12
  • 1
    Do you have an explanation for this miracle?
    – user147505
    Commented Aug 11, 2016 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".
    – user172564
    Commented Aug 11, 2016 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
    Commented Aug 11, 2016 at 13:27
  • 1
    @deltab I forgot to mention about ESC, thanks a million mate.
    – user172564
    Commented Aug 11, 2016 at 13:30
  • 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.
    – user172564
    Commented Aug 11, 2016 at 13:44

You must log in to answer this question.

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