See Screenshot.
After the first line hits end of the terminal and the cursor/text goes into the second line the first line goes invisible and the second takes it's place.
The first line will still be executed and I am still able to go back and edit the now invisible text.
I found the answer, turning off "Set locale variables automatically" was the reason.
It can be set in the Preferences > Profiles > Terminal Tab > Environment.
Related
In vs code's terminal the line which shows the directory(the line which takes input when opened fresh) is being displayed on the last line of output. Normally the directory should be displayed on the next line after the output. In my vs code the last output line itself shows the directory line and waits for input.. Is there any way to change this weird terminal behavior? Thanks in advance.. I am new to command line and lack proper terminologies.. sorry.. please ask if something feels unclear..
Note: I am running Mac OS X Sierra but this problem occurs on Ubuntu also.
I have customised the terminal prompt as such:
export PS1="\n\[\033[1;31m\]\u 🖖 \[\033[1;32m\]# \[\033[1;32m\]\h \[\033[0;35m\]in \[\033[0;36m\]\w\n\[\033[0;34m\]> \[\033[1;37m\] \e[0m"
Note that I have put a newline at the end, so I start typing commands on a new line after the >. I have done this on a number of machines, and I've noticed that whenever I add the newline, the terminal behaves weirdly.
By weirdly, the exact behaviour I refer to is this (this includes the steps to replicate the error if you use the PS1 value I have mentioned):
Access older commands by pressing the up arrow key.
When I encounter a command in the history which consists of more than 1 word, and the first word is is more than 4 characters long, then the first 4 characters of the word 'stick' to the initial part of the prompt.
This 'sticky part' cannot be deleted by me, and does not even go when I press the up arrow key several more times.
For instance, if the last 4 commands I entered were (from least recent to most recent): clear, man man, this that and help.
Then, when I look at previous commands by pressing the up key incrementally:
help is visible properly.
this that is visible properly.
Note how this is appended at the start. I cannot delete it if I try.
Continues to stay as I press the up key.
How can I resolve this issue?
Each of the escape-sequences in your prompt has to be bracketed with \[ and \] to tell bash that those characters should be ignored for the purpose of counting columns. The last one in your example is not bracketed:
export PS1="\n\[\033[1;31m\]\u 🖖 \[\033[1;32m\]# \[\033[1;32m\]\h \[\033[0;35m\]in \[\033[0;36m\]\w\n\[\033[0;34m\]> \[\033[1;37m\] \e[0m"
i.e., \e[0m
If you fix the error, bash is likely to give better results. This shows the suggested correction;
export PS1="\n\[\033[1;31m\]\u 🖖 \[\033[1;32m\]# \[\033[1;32m\]\h \[\033[0;35m\]in \[\033[0;36m\]\w\n\[\033[0;34m\]> \[\033[1;37m\] \[\e[0m\]"
While navigating in BASH using VI mode, I can jump back to a specific character (e.g. '-') of the current command line via the following command:
F-
How can I jump back to a specific string (e.g. '--path') in the current command line of BASH? I know navigating in VI but I did not understand how to perform regex search in current command line of BASH.
According to here, what you want doesn't seem possible. The ?word and /word bindings search in command history rather than in the current command line.
But in vi mode, you can press ESC v to open the current command line in an editor. Then you can edit & save the command and it will be executed (source).
Of course, as pointed out in nur-sh's answer, you can simply keep pressing B to get to the word.
You could use the find command which searches backwards from where you are
?word
or you could keep pressing B to get to the word
(this command goes back one Word at a time).
I have cygwin installed on my Windows 7 box and I have been running into a problem where when I type a command it will occasionally be wrapped back onto the same line, deleting the bash prompt. Here is an example:
The command in question is command "201" (4 lines from the bottom). I included the others for context.
The text of the command I was typing was
git commit -m "Forced LF line endings."
(Note: I am posting this with mostly git commands, but the problem occurs with any command. I have not noticed a pattern yet.)
It jumped to the start of the line and started to overwrite my prompt.
When I push the up arrow (to view the history) the result is even weirder:
(Note the cursor is many characters past the end of the command.)
When I try to backspace the cursor from that position, I can only go back this far:
Then when I go up into the history from that backspaced line, I get this:
The command starts from the end of the text that is displayed. (This is consistent for the entire history) But when I go up in the history to the faulty git commit ... it displays as it did before with the overwritten text but when I go past it, it deletes a line of the prompt and displays the previous entry in the history the same way it was doing it before (a la image 2).
When I was creating my PS1 variable I has odd output like this, but I have since closed my brackets and things and don't think that is causing the issue. However if you would like to see my .bash_profile (that sets the PS1) feel free to see it on GitHub. It is really short.
I have tried searching for the issue and can only find a few cygwin email archives about the line wrapping in xterm, but no solutions.
PS: As I was pushing the latest .bash_profile, in order to link it, I ran into the problem again when I typed git add .bash_profile and hit enter, it ran the command but returned the cursor to the start of the same command instead of printing a new prompt.
Then when I as writing another commit line, it did the same as the first image, but it blacked out the rest of the line (It wrapped the line, but overwrote the entire line and not just the first few chars.)
See http://manpages.ubuntu.com/manpages/lucid/man1/bash.1.html#contenttoc26:
\[
begin a sequence of non-printing characters, which could be used to embed a terminal control sequence into the prompt
\]
end a sequence of non-printing characters
If you don't enclose non-printing characters (e.g. color sequences) in your prompt with these their length is counted as part of the prompt's length, eventually resulting in the symptoms that you describe.
It doesn't occur frequently to me. When it does, I just type in 'kill -WINCH $$' into the cygwin terminal and it fixes the problem. link to source
When I open cmd, the default value is::
C:>Users\otariki>
When I press ENTER on keyboard, one new line is written
C:>Users\otariki>
In new line, I do not need the C:>Users\otariki> string. I need an empty line. Please tell me how to do this?
This is the "PROMPT" variable, you cant set it to nothing when its nothing it defaults to the one you had.. nearest you can have is a space.. but.. prompts are useful, indicates the command finished and isnt just waiting, as well as normally tells you where you are.
You can use PROMPT $H to get the appearance of what you want.
Each line will be empty, starting in the 1st position.
But in reality each line will start with <backspace><space><backspace>
You can type
echo off
into the CMD window, so it will not prompt you at all but you can still type in commands.