When I type in a command in MobaXterm, the first character of my prompt shows up at the end of the next line, and the rest of the prompt is on the line after. It doesn't seem to affect anything performance-wise, but I can't seem to find anyone else with this issue. If anyone has any ideas as to what might be causing this, some help would be much appreciated.
screenshot of my terminal
On a MobaXterm window, Click on Settings->Configuration and then in the Terminal tab un-select Display separation line.
Click here for a picture
This is not due to a setting in MobaXterm, but rather it is due to the default prompt set in the version of bash cygwin installed by MobaXterm, which adds a newline.
You can change the prompt by setting PS1 in ~/.bash_profile (or if you set it up ~/.bashrc). For example I add this line and now there is no newline at the prompt:
PS1="\h [\e[33m]\w[\e[0m]> "
Related
I normally use the up arrow key to scroll through previous commands in my terminal. I've noticed that over the past few months, when I do this, I do not get previous commands but instead a 'buggy behavior'. For example, when I press the up arrows key, it might enter gibberish and apparently random spaces and a small part of my command. Does anybody have any ideas as to what might be causing this? Sometimes it works, sometimes it doesn't work. It's starting to get very annoying. (fyi, I'm using yosemite and osx if that has any relevance)
I know this is an old question, but I recently had the same issue. The problem is likely your PS1 prompt. You may not be fully enclosing your non-printing characters with \[ ... \]
To solve:
in your terminal echo $PS1 - this will show you your current PS1 setting.
Make sure that any options (such as color options) are enclosed by \[ and \] and set it. e.g. PS1='\[\e[95m\]\u \[\e[93m\]\w:\[\e[92m\]\$'
Save your new PS1 permanently in your .bash_profile or wherever you keep your bash settings.
Example:
My faulty PS1 was \[\e[95m\]\u \[\e[93m\]\w: \e[92m\]\$
I was missing the opening encloser, \[ after the \w:
My corrected PS1 is \[\e[95m\]\u \[\e[93m\]\w:\[\e[92m\]\$
In my case, the up-arrow stopped working properly for me in OSX shortly after I changed my .bashrc to use "HISTSIZE=-1". My unconfirmed guess is that the bash version is too old to handle the -1 option, so bash stopped recording a history entirely. My up-arrow key was being interpreted correctly, but there was no history to retrieve. Once I changed my HISTSIZE, the up-arrow (and the history command) in new terminals started working again.
To be clear, I can't say if your problem is from the same cause. I don't recall getting gibberish in the history, though I did see some odd behavior such as an errant "." somehow appearing in ls commands. Still, if someone is having problems with using the up-arrow to retrieve previous bash commands, it seems worth a shot. Try checking your HISTSIZE setting, and/or invoke the history command directly, to make sure that you have a history for the up-arrow to retrieve.
I've had this problem for a while myself on my work computer I was able to resolve it when changed from ksh shell to the bash shell.
I'd recommend this Lynda course it explains most of what you need but simply type bash to change shell.
https://www.lynda.com/Mac-OS-tutorials/Unix-Mac-OS-X-Users/78546-2.html
#!/bin/sh
echo "Hello from sh"
When I run this program (hello.sh) I get a command not found error. I'm using cygwin on Windows and I looked at cy's FAQ. It said to change the permissions to 755. I already did that and still no luck. I get the same error with these other two programs.
#!/usr/bin/env python
print "Hello from python"
#!/usr/local/bin/perl
print "Hello from perl\n";
Any answers are appreciated. Thanks.
As has already been said, you need to add the Cygwin binaries to your path. To do so, right click on "My Computer", click "Properties", then "Advanced", then "Environment Variables".
Create a new environment variable with name CYGWIN_HOME and value C:\cygwin (or wherever you installed cygwin. The default location is C:\cygwin\ so this should probably work for you).
Then edit the environment variable named "PATH", and tack on the following to the end:
;%CYGWIN_HOME%\bin;%CYGWIN_HOME%\sbin;%CYGWIN_HOME%\usr\bin;%CYGWIN_HOME%\usr\sbin;%CYGWIN_HOME%\usr\local\bin;%CYGWIN_HOME%\usr\local\sbin
Close your command prompt, then reopen it. The cygwin binaries should now be available. You can double-check this by typing "which bash". It should report the location of your bash executable
I was getting the "command not found" error on a Perl script. That script has the shebang line: "#!/usr/bin/env perl" as the first line and my user is the owner who has execute permissions. I was trying to run the script using the command line "ppminstall.pl ?" (the script is set up to display documentation for using the script if passed the '?' argument). I was cd'd to the directory containing the script. The solution turned out to be to run it using "./ppminstall.pl ?", i.e. explicitly specify the current directory. I think that you might be able to add "." to the current path and get the original command line to work, but it does seem safer to me to use "./" to run it since it's pretty explicit about where the script that you want to run is located. It may be possible for someone to manipulate your Path variable and cause you to be running a version of the script that you didn't intend. The '.' and '/' characters are easy to type without taking your eyes off the screen, so it seems like a useful habit to get into. Of course, I don't know if that is your problem, but it was mine.
Maybe caused by the wrong line break?
Open this shell in Notepad++, and then check if the line break is UNIX(LF) in the lower right corner.
If not, click the text Windows (CR LF) and then click Convert to UNIX(LF).
This works for me.
I'm on OS X Mountain Lion, running the included ZSH shell (4.3.11) with Oh-My-ZSH installed over the top.
When using tab completion with commands such as homebrew, when ZSH lists the available commands, it is also duplicating the command. For example:
$ brew {tab}
will result in:
$ brew brew
[list of homebrew commands]
I'm unsure what is causing this error, as when I resize the terminal window, the first instance of the command name disappears.
If I hit backspace when the duplicates are displayed, I can only delete the second instance of the command, zsh won't let me backspace any further. Also, if I do remove the duplicate with backspace, zsh then acts as if there is no command typed at all.
My .zshrc along with all my other .configuration files can be found at https://github.com/daviesjamie/dotfiles
UPDATE: I found this post about someone having the same problem on Ubuntu. However, I don't understand the given solution, and I'm not even sure if it applies to my set up?
This effect also could be reproduced if you use any of fancy UTF-8 characters like arrow, "git branch" character and so on.
Just remove this chars from prompt and duplication will not occur.
Also adding
export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8
to ~/.profile can help
The problem is likely to arise from misplaced %{ %} brackets that tell zsh that text inside has zero width. The only things that should be enclosed in them are escape sequences that change color or boldness of the text. If you are using new zsh (>=4.3.{unknown version}) I would even suggest to use %F{color}...%f, %K{color}...%k, %B...%b instead of %{${fg[green]}%} or what you have there.
The problem with them is that there is no way to query the terminal with a question like “Hey, I outputted some text. Where is the cursor now?” and zsh has to compute the length of its prompt by itself. When you type some text and ask zsh to complete zsh will say terminal to move cursor to specific location and type completed cmdline there. With misplaced %{%} brackets this specific location is wrong.
If you use iTerm on Mac, be sure to check "Set locale variables automatically" in your profile preferences. I had it unchecked for an SSH connection and it resulted in the same bug and I fixed it by leaving that option checked.
It's an old thread but I faced similar issue in my zsh setup with oh-my-zsh configuration.
Setting export LC_ALL=en_US.UTF-8 fixed the issue.
A lot of answers in a lot of places suggest the export LC_ALL=en_US.UTF-8 solution. This, however did not work for me. I continued to have this issue using oh-my-zsh on both Arch linux and PopOS.
The only solution that worked for me was this suggestion by romkatv on an issue on the oh-my-zsh github repository.
It turns out, at least in my case, that the autocomplete duplication issue would only show up if there was a non-ASCII character somewhere on the line (like an emoji). And ZSH would incorrectly assume that this non-ASCII character needs to take up 2 character spaces instead of 1.
So the solution that worked was to open up the .zsh-theme file of whatever theme you're using, find all non-ASCII characters and use %{%G%} to tell ZSH to only use one character width for that character
For example, the default oh-my-zsh theme robbyrussel contains 2 non-ASCII characters. The '➜' character in the prompt
PROMPT="%(?:%{$fg_bold[green]%}➜ :%{$fg_bold[red]%}➜ )"
and the '✗' character in the prompt for git directories
ZSH_THEME_GIT_PROMPT_DIRTY="%{$fg[blue]%}) %{$fg[yellow]%}✗"
Using %{%G<character>%} around the 2 non-ASCII characters like this
PROMPT="%(?:%{$fg_bold[green]%}%{%G➜%} :%{$fg_bold[red]%}%{%G➜%} )"
and this
ZSH_THEME_GIT_PROMPT_DIRTY="%{$fg[blue]%}) %{$fg[yellow]%}%{%G✗%}"
is what finally fixed the issue for me.
So all you need to do is make a copy of the theme file you want to use and edit all the non-ASCII characters as shown above and you should hopefully never see the duplication issue again.
My solution to make both local and ssh work is something like a combination of #Marc's and #neotohin's answers:
Set export LANG=en_US.UTF-8 (simply uncomment that part in the template .zshrc; exporting LC_ALL, as in #neotohin's answer, instead of LANG may also work, I didn't try)
Uncheck "Set locale environment variables on startup" in the Terminal profile's "Advanced" section (reason: that setting sets LC_CTYPE=UTF-8 instead of en_US.UTF-8, which brakes the locale for me in ssh)
My terminal previously showed subalcharla$ at the command line.
The terminial is now showing subalcharla#subal-charlas-macbook ~ $.
How do I go back to the original setting?
What is the difference between the two?
How did this get changed without my doing so?
At the end of ~/.profile add the line
export PS1='\u$ '
to get your old prompt back.
To do this you can type
nano ~/.profile
which will bring up a text editor. Press down until you get to the bottom of the file. Hit Enter to create a new line, and paste in
export PS1='\u$ '
Press Control+X to exit the editor and say "yes" when asked if you want to save. Now restart your terminal and your prompt should be restored.
The first prompt you gave shows your username, the second shows your username and hostname. There is no error and the functionality of your bash shell is not changed by changing the prompt.
Something must have changed your PS1 environment variable, maybe a system update or the installation of software. It's probably benign though.
I don't know how it got changed, but it's controlled by some symbol definitions. Use "man bash" in the terminal and search for the section called "PROMPTING". There are symbols named PS1-to-4 that it uses to construct the prompt.
I found an awesome tip here. You can "[r]apidly invoke an editor to write a long, complex, or tricky command". However, when I press the key combination above, I get Emacs open. I would like to switch it to Vim. How can I invoke Vim with C-X e?
[1. Problem SOLVED by Brian Cambell]
export EDITOR=vim
Add to your .bashrc or appropriate shell rc file
[2. Problem SOLVED thanks to Pax]
I was unable to get the tricky command back to Bash. The errors were:
> Error detected while processing BufRead Auto commands for "*":
> E117: Unknown function: JumpToLastPosition
Quotes in .vimrc solved the second problem. I am still unsure about the part in my .vimrc:
" augroup misc
" autocmd!
" autocmd BufReadPost * call JumpToLastPosition()
" autocmd FileChangedShell * call WarningMsg("File changed outside of vim")
" augroup end
[3. Problem]
What do the above part in .vimrc do?
On most Linux installs (all the ones I tested), bash recognizes both the Emacs and Vi command history keys (or you can use "set -o vi" to force it).
So, you can just use the vi-mode "<ESC>v" to to enter visual mode, this will start editing in a Vim session.
To run the command, you just save and exit from Vim ("ZZ" or ":wq"). To cancel the command, you need to delete the contents, save and exit ("1GdGZZ").
In addition to running it by exiting, you can also save it while in the editor to another location (":w /tmp/myscript").
Keep in mind that visual mode will work with the currently selected line so you don't have to start with a blank command ("<ESC>v"). You can use the normal vi-mode tools to select a line from the history first and then enter visual mode ("<ESC>kv" for last command, "<ESC>/grep<ENTER>nnv" for third-last grep command and so on).
Using this method has the advantage of not changing the "EDITOR" variable which may be used for other things (unless you want Vim for everything, which is a very sensible position to take IMNSHO).
Update:
Regarding your error, posted after the question:
JumpToLastPosition() is the function called by Vim for all files to put the cursor where it was when you last edited the file. I'm going to assume you're actually getting this error when the editing starts, not when you exit, since this is the auto function following a buffer read.
Can you start a "normal" vim session ("vim xx.txt" and then "vim xx") without this error occurring? You may find you get the same problem (and possibly only on the last one).
If you do have the same problem, you need to look at your startup files. It's possible the autocmd for BufRead is broken somehow. Have a look inside your vimrc and you filetype.vim files to see where that function is called and/or defined (I suspect it's called but not defined and that may be a mismatch between the two files or one of them has been damaged).
export EDITOR=vim
Add to your .bashrc or appropriate shell rc file
The link that you provided contains the answer:
Next time you are using your shell, try typing ctrl-x e (that is holding control key press x and then e). The shell will take what you've written on the command line thus far and paste it into the editor specified by $EDITOR.
You need to set the EDITOR environment variable (like #Brian Campbell)