While typing a nice long command though SSH (ie. rsync copy), the line doesn't shift to a new line and just overlaps the current line when i hit the right edge of the screen. Any suggestion on why this is happening and how to fix?
The setup is below (and an example command).
Debian6 64bit - Its a DOMU VM (XEN)
/test/test-srv release]$ rsync -avzh --dry-run /test/long/source/path/blah/blah/blah/ /test/long/target/path/etc/etc/etc/etc/etc/etc/test
The bit in bold is the overlapping part which should just push the cmd prompt up a line.
Image Example:
This is because of your colored prompt. You neglected to mark ANSI escape codes as invisible.
Bash doesn't know what your terminal does, so it relies on you to tell it which parts of the prompt are non-printing and which are not. You do this by adding \[ \] around them.
# Example bad prompt which wraps lines incorrectly like you describe
PS1='\033[01;34m\w \$ \033[00m'
Here, \033[01;34m and \033[00m don't show up on the terminal (that is, they don't move the cursor), they just change the color of the following text. To show this, we wrap them in \[ \]:
# Prompt from above that wraps correctly
PS1='\[\033[01;34m\]\w \$ \[\033[00m\]'
Related
So I was installing node and somehow I ended up in the /user/local/bin folder checking what was there.
I wanted to so a ls | grep node but did a ls | cat node. The node directory then started to show itself in all its glory. I chuckled, laughed, then stopped the cat but that left my terminal looking something like this:
It is easily fixable by exiting the window.
I don't recommend you try it but i've managed to recreate it reliably. Just cat the node directory leave it for a few seconds then cancel it.
My question is what on earth is going on here? AFAIK using cat shouldn't be able to make this stuff happen.
Terminals interpret certain combinations of bytes as commands. This is how command line programs can output colors, or change the cursor position. What you're seeing is the output after one of these commands activated a box drawing character set by accident. You can activate it yourself with echo or printf:
my cool prompt$ printf '\033(0'
└≤ ␌⎺⎺┌ ⎻⎼⎺└⎻├$
To get out of this mess, type reset and press Enter - it will clear the screen and set all settings back to default.
└≤ ␌⎺⎺┌ ⎻⎼⎺└⎻├$ ⎼␊⎽␊├
(..screen clears..)
my cool prompt$
You managed to output the contents of the node executable to the terminal. What happens when you output random octets to the terminal depends on what those characters are and on the terminal. It often leaves the terminal in a state that the user did not really expect.
I'm using MacVim and I would like to have ! commands printed in color. For example:
In bash, the following echo statement prints Hello World in green (as expected):
$ echo -e "\033[32m Hello World"
Hello World
However, in VIM the output is not color, and the escape codes are printed:
:!echo -e "\033[32m Hello World"
[32m Hello World
How can one have VIM (and MacVim build 57 in particular) print the output of ! commands and honour ANSI color escapes.
You can't. But you can suspend the editor and drop to a shell relatively quickly;
Or you can use Ansi Filter to remove the escape sequences so you will at least not see a mess.
this one:
:!echo $(tput setaf 1)Hello world$(tput sgr0)
will print Hello world in color.
Don't use escape sequences, but named tput entries. (all times, not only in this example). read:
man teminfo; man infocmp; man tput - for more information.
based on comments I found this question very interesting.
Still searching for the better solution, but for now find this one - http://code.google.com/p/conque/ .
Allow run colored commands inside MacVim's buffer.
Don't know if this would help, but running my RSpec tests inside vim gives me colored output using the --color option. I use the following command to run the current spec file inline:
:map ,t :w\|:!rspec --color %<cr>
If you run macvim in console mode (vim, not mvim) all :! commands are redirected to the shell and executed there. They take the whole window instead of 1/3 of it, and they use whatever theme your console happens to have.
But you get ansicolors.
Your question (and its pop up done by #avocade) addressed the issue I have with some printing in my aurum plugin thus I’ve wrote (started to write, but the most significant piece of functionality is already here) the ansi_esc_echo plugin. To use it in your one you must install it, install frawor and do
execute frawor#Setup('0.0', {'autoload/ansi_esc_echo': '0.0'})
call s:_r.ansi_esc.echo("\e[33mabc")
. Currently it deals only (speaking exclusively about special characters or sequences) with carriage return, backspace (untested), tab, newline, and CSI colors.
Lets say I have a script, "myscript.sh", with contents being simply echo $PWD. I'd like to bind somehow this script to a key combo in bash (gnome-terminal) - so that when I press this key combination, the output of "myscript.sh" is inserted ("pasted") at the cursor position in the terminal.
Apparently, bash history and line manipulation is handled by readline - and the references I got for bash keyboard shortcuts, do reference readline:
bash keyboard shortcuts
Bash Reference Manual: Bindable Readline Commands
I've also seen in Bash Reference Manual: Readline Init File Syntax that the key bindings for bash can be listed by using bind -p (see help bind [not 'man bind'] for more). So maybe this question would better be titled as "_binding macros to custom keyboard shortcuts in readline" :) But in any case, is what I want possible to do?
I guess an alternative would be to have the script be something like "pwd | xsel -b", and then I call it on terminal - and I can paste afterwards; but I'd still like a single keyboard shortcut instead, say like Ctrl-Alt-H (which seems to be not used for anything), which will immediately insert/paste script output when pressed.
Thanks in advance,
Cheers!
EDIT: Just to clarify - here is my use case where I'd like this facility. I'm usually cd'd in a project folder, usually named something like myproject-folder-0012a, which is under revision control by svn. And there is a bunch of these folders. So quite often, I do commits where the first word of the message is the directory name, as in:
svn ci -m "myproject-folder-0012a: here a commit message"
But that is what I don't like - first I type 11 characters, which go rather fast:
svn ci -m "
And then, I cannot use autocompletion to get the name (i'm inside the folder) - which means I either have to fully type it (no way :)), or I copy paste it from the prompt (which requires selection - press mouse, drag, release mouse; then Ctrl+Shift+C, and then Ctrl+Shift+V, plus any left/right keys if I miss allignment - plus deletions and such if I make the copy wrong).
Meaning - so much work, just to get the bloody folder name for a bloody commit message :( I'd MUCH rather press something like (say) Ctrl-Alt-H, and have the folder name automatically inserted at cursor position, and be done with it :)
My suggestion for xsel is only because I could put it into a "global" script - say symlink it as /usr/bin/myscript (and obviously, the contents of the script are echo $(basename $PWD) rather than just pwd for my needs), and then I could do:
$ myscript # this puts directory name in clipboard
$ svn ci -m "[CTRL+SHIFT+V TO PASTE HERE]myproject-folder-0012a[NOW TYPE]: here a commit message"
... which sort of makes the workload less, but still - then I have to remember what the script name is, and call it, before I type the svn command (and I don't always remember that)... And still - I have to call a command, and then press a key combo; why shouldn't I just press a key combo once, and be done with it ??! :)
Well, hope this clarifies my problem a bit better ....
EDIT2: However, another reason why a bash keyboard shortcut would be useful, is that then I could also "paste/insert current directory name" not only in shell commands - but also in terminal programs, say like nano (where it would, arguably, be more difficult to use bash script or function expansion directly).
Simple version:
This command at a shell prompt:
bind '"\ee": "${PWD##*/}\e\C-e"'
or this line added to your ~/.inputrc:
"\ee": "${PWD##*/}\e\C-e"
will cause Alt-e to insert the basename of the current directory on the command line. It requires that the default binding of the readline function shell-expand-line which is \e\C-e be present (this could be adapted if it's different). I'm also making the assumption that you're using Bash's emacs mode.
Unfortunately, it causes things that have already been typed to be expanded as well. One of the affects of this is that after having typed:
svn ci -m "
and pressing Alt-e, the quotation mark will have disappeared. There are a couple of ways to deal with this.
One, assume that all you'll lose is the quote and either manually add it back or have the readline macro add it for you:
bind '"\ee": "${PWD##*/}\e\C-e\eb\"\C-e"'
which just isn't very satisfactory.
Advanced version:
Or, two, kill the line, do the insertion, then yank the line back:
bind '"\ee": " \C-u \C-a\C-k${PWD##*/}\e\C-e\C-y\C-a\C-y\ey\b"'
or
bind '"\ee": " \C-u \C-a\C-k${PWD##*/}\e\C-e\C-y\C-a\C-y\ey\b\ef\C-f"'
This leaves the rest of the line intact (nothing else is expanded or deleted), but it uses the kill ring, so it may leave it in a state that's different than you expect (if you're using it). It also inserts a space after the inserted directory name (the spaces in the macro are used to ensure that older kill-ring contents are not regurgitated if the macro is executed at the beginning or end of the line). The macro should work regardless of the position of the cursor in the line. The insertion will be made at the cursor's position, leaving the cursor in the same position [in the first version].
Edit: The second version leaves the cursor after the dirname and space that are inserted.
Edit 2:
The readline function shell-forward-word (unbound) does a better job than forward-word (\ef) for this. You can make use of that like this:
bind '"\ew":shell-forward-word'
bind '"\ee": " \C-u \C-a\C-k${PWD##*/}\e\C-e\C-y\C-a\C-y\ey\b\ew\C-f"'
By the way, you should know that Bash keyboard shortcuts are not active in other programs such as nano.
Ok, not really an answer, but I'd just like to summarize the comments I got so far, which are useful for my problem. However, the question as it stands - in respect to bash keyboard shortcuts running arbitrary scripts - is still not answered (I'd still prefer doing all this with a single key combo :))
First, I can use a 'global' script like:
$ sudo bash -c 'cat > /usr/bin/bpwd <<EOF
#!/bin/bash
basepwd=\$(basename \$(pwd))
echo -n \$basepwd # suppress line ending
# exec 1>/dev/null # debug: redir stdout to null
echo -n \$basepwd | xsel -i -b # suppress LF, and make xsel read from stdin
# exec 1>/dev/tty # debug: restore stdout
EOF
chmod +x /usr/bin/bpwd'
Or, I can add bash functions to my .bashrc (note: make sure you reload bash after you add these lines to .bashrc - for example, simply by typing bash in your current terminal):
$ echo '
bpwd2() { basepwd=${PWD##*/} ; echo -n $basepwd | xsel -i -b ; echo -n $basepwd ; }
svnci-test() { echo -n "$(bpwd2): $*" ; }
svnci-m() { svn ci -m "$(bpwd2): $*" ; }' >> ~/.bashrc
Basically, I misunderstood Reese Moore's suggestion originally - you can indeed use backticks - consider this command session (after the above commands have been ran):
$ bpwd
Desktop\
$ bpwd2
Desktop\
$ echo `bpwd`
Desktop
$ echo "`bpwd2` 2"
Desktop 2
This is what I needed to understand Moore's "the output from the backticked commands will be used as input on the executed command" (however, one also needs to take care to clean the line endings from the output); or, in my case, I can call
svn ci -m "`bpwd`: my message here"
# svn ci -m "${PWD##*/}: my message here" # alternatively
... or, I could follow camh's suggestion, and use svnci-m as a function (in my case, I almost never use additional arguments to svn ci, and so my version is slightly different). And to test whether arguments are passed correctly, I can use the svnci-test function:
$ svnci-test "my message"
Desktop: my message\
Thanks for the comments so far,
Cheers!
One way to do what you want with a single key press is to take advantage of programmable completion in bash. You possibly have some programmable completion set up with the bash_completion tool/package. If not, look into that to see the specifics of how it is done.
The idea is to have the programmable completion recognise when you have hit at the start of a svn commit message and then have it return a single completion which is the text you want to insert (the basename of the current directory).
I've only dabbled with programmable completion so I can't give you the details, but the above-mentioned bash_completion package or the subversion completion script may be a good start.
Sometimes I have to run a command many times in succession, for example to see if a service has started, and it becomes tedious to move my hands away from my normal typing position to press the Up Arrow and Enter keys repeatedly. Is there a way to run the previous command without the Up Arrow and Enter keys, perhaps with an elaborate shell script?
I've tried the following, but it is unsatisfactory because it cannot execute aliases, and it is a little slow.
history | tail -2 | head -1 | cut -d' ' -f4- | cat > prev_command.txt
sleep .01
chmod 777 prev_command.txt
eval prev_command.txt
rm prev_command.txt
Ideally I'd have an alias to this script so I can type in something like "prev" in the command line and hit Enter to run the previous command again.
In bash, you can press ctrlp to go to the previous command -- that's a lot better than having to move to the arrow keys.
See also: https://github.com/fliptheweb/bash-shortcuts-cheat-sheet/
Use
!!
to run your previous command.
sudo !!
also works , for the record.
Instead of running the same command many times in succession, why not watch it instead? watch will run a specified command repeatedly and display the output in stdout so you can see it change over time.
watchcommand
I often use the "history expansion" feature in bash (usually activated with cntlR) -- it interactively searches through your history for the previous closest match.
See the bash manual section Searching for Commands in the History, and also Using History Interactively.
Are you an emacs or vi user? You can use
set -o vi
set -o emacs
to set emacs or vi keybindings. You can then use the emacs or vi key bindings in bash. I don't know if this should work for other shells. I believe the vi mode starts in insert mode, so you need to hit esc to enter command mode. In emacs mode (the default), you can use ctrl+p and then ctrl+j to move to the previous line and do a carriage return.
Otherwise, you can use !! as someone else suggested.
In bash:
$ help fc
fc: fc [-e ename] [-lnr] [first] [last] or fc -s [pat=rep] [command]
Display or execute commands from the history list.
fc is used to list or edit and re-execute commands from the history list.
FIRST and LAST can be numbers specifying the range, or FIRST can be a
string, which means the most recent command beginning with that
string.
Options:
-e ENAME select which editor to use. Default is FCEDIT, then EDITOR,
then vi
-l list lines instead of editing
-n omit line numbers when listing
-r reverse the order of the lines (newest listed first)
With the `fc -s [pat=rep ...] [command]' format, COMMAND is
re-executed after the substitution OLD=NEW is performed.
A useful alias to use with this is r='fc -s', so that typing `r cc'
runs the last command beginning with `cc' and typing `r' re-executes
the last command.
Exit Status:
Returns success or status of executed command; non-zero if an error occurs.
Note the suggestion for alias r; I use this frequently.
Depending on what terminal you're using, I know a lot used to have F3 as an option for repeating, but that's still outside the normal range for typing as well unless you have a special keyboard with more accessible function keys.
My keyboard makes the function keys easily accessible, but I don't do much command line work in unix any more, so I wouldn't be able to tell you for sure whether or not this is still possible.
When working an interactive bash session, one aspect from the Windows shell I miss is the F8 key where you start typing a command, hit F8 and the shell finds the most recent command entered in history that matches what you have typed so far. e.g.
me#Ubntu07:~>cd /home/jb<F8 Key Here>
brings up my prior command:
me#Ubntu07:~>cd /home/jboss/server/default/log
Is there any way to do this in bash ?
Hit Ctrl-R before you start typing.
(There may well be another version which finds commands based on what's already been typed - I wouldn't know, as Ctrl-R has always been good enough for me :)
Pressing Ctrl-R again shows the next match etc.
My Gentoo is configured in a way that I can press PgUp and PgDn to scroll through those commands in the command history that start with what’s currently in my command line.
# cd<PgUp>
results in:
# cd hydrogen
That’s pretty much the same function. It is defined in my /etc/inputrc with the following lines:
# mappings for "page up" and "page down" to step to the beginning/end
# of the history
"\e[5~": history-search-backward
"\e[6~": history-search-forward
I have these lines in my .inputrc file:
"\e[A": history-search-backward
"\e[B": history-search-forward
This binds history search to the up and down arrow keys. So you can start typing a command, kextload say, and then each tap of the up arrow will complete the line with the previous command that started with kextload.
All of my config files are public on github.
http://github.com/jonshea/config-files/tree/master
In your case !jb would print and then run that command.
e.g.,
$ nano logconfig.properties
$ !n
nano logconfig.properties
$
Of course if you want to be on the safe side, use ctrl-r first to bring up the interactive command history.
Ctrl + R does a history search. It's a bit different in that first you hit Ctrl + R and then type what you're looking for.
If you're just talking about a command, you can use the !<cmd> to do the last one. For example, say you entered python runscript.py a while ago; you can type:
!py
or something along those lines to run that command again.
To repeat an argument to a command, you could do something like this:
echo !py:1
which would echo runscript.py back to the terminal, in this example. The number after the colon refers to the argument you'd like to use from the given command.
There's a lot of other great information about the bash history here.
If you use vi input mode (set -o vi in bash or via set editing-mode vi in .inputrc), you can use normal vi commands to search the history (/). This gives you full regular expressions, too, which can be helpful for finding a complex command.