Bash's vi command line editing mode

[Ven Tadipatri]

Hi,

   This may sound like a real newbie question, but when I do the "set -o vi" 

in the bash command line shell, if I hit <Esc> and v on the command line,

it goes into vi editing mode. This is kind of cool, as I can exercise

the full editing power of vi, and when I exit the editor it runs the command.

  Unfortunately, sometimes I may have a really powerful/dangerous/unnecessary

command that I've typed, and all I want to do is just cancel, not execute the

command. How do I do this?

  :q! doesn't seem to work, as the command still runs. :wq , well, I don't want

to save anything, I just want to get out of the editor and return to the plain

old bash prompt.

   Is this possible? Of course I can always kill the terminal that I'm running

in to avoid running the command as soon as vi exits. Or I can try to press

ctrl+C as fast as possible.

   I was hoping for a better alternative.

Please help.

Thanks,

Ven

[Ven Tadipatri]

Well...duh..there's an easy fix for this. Just prefix the command with '#'
Then hit :wq to save it and "run" it. Still...why does it behave this way?

Shouldn't I be able to choose not to run the command when I exit

from Bash's vi editing mode?

   This is on a Centos 5 machine, and the terminal is a Gnome terminal.

Thanks,

Ven

[Taylor Hedberg]

You want the :cq command, which causes vim to exit with non-zero status.
This makes the shell think something went wrong with the editor, so it
won't execute the command.

[Gary Johnson]

One way is to exit vim with the :cq command. See

:help :cq

That will quit vim with an error code telling bash that the editing
was unsuccessful.

Another is to delete the contents of the vim buffer before saving
and quitting as normal, e.g., dd if there is only one line in the
buffer or ggdG to if there is more than one line, followed by ZZ or
:wq to save and quit.

In this case, you _do_ want to save something because that something
is what bash will execute.

I usually use dd:wq because the :w makes me feel more sure that
the empty buffer has actually been written.

Regards,
Gary

[Christian Brabandt]

Hi Ven!

On Fr, 23 M�r 2012, Ven Tadipatri wrote:

> Hi,
> This may sound like a real newbie question, but when I do the "set -o
> vi"
> in the bash command line shell, if I hit <Esc> and v on the command line,
> it goes into vi editing mode. This is kind of cool, as I can exercise
> the full editing power of vi, and when I exit the editor it runs the
> command.
> Unfortunately, sometimes I may have a really
> powerful/dangerous/unnecessary
> command that I've typed, and all I want to do is just cancel, not execute
> the
> command. How do I do this?
> :q! doesn't seem to work, as the command still runs. :wq , well, I don't
> want
> to save anything, I just want to get out of the editor and return to the

Actually, :q! should work and always did for me.
I would guess, that bash only executes the file, if it's timestamp has
been changed. May be some plugin that sets an WriteCmd autocmd or
something?

Mit freundlichen Gr��en
Christian
--
Wie man sein Kind nicht nennen sollte:
Don Erstag

[AK]

I always ddZZ and I think it's the best approach because this is
not something you might use often and remembering a special :cq
for it makes no sense because everybody knows dd and it works
perfectly well for this use case.

I like it better than :q! because it's easier to type, because
I hardly ever use :q! and dd is more visually explicit, i.e.
you can see "this is what will get executed - nothing", with
:q! I think if I take a longer time to edit the command, I
might save it accidentally as I'm working on it, and then
exiting will run the saved version.

I also use the same dd command when I edit the regular command
line and then decide I don't want to run it.

-ak

[John Little]

On Saturday, March 24, 2012 4:05:34 AM UTC+13, vtadipatri wrote:
> ... when I do the "set -o vi" in the bash command line shell, if I hit <Esc> and v on the command line, it goes into vi editing mode. This is kind of cool, as I can exercise the full editing power of vi, and when I exit the editor it runs the command.   Unfortunately, sometimes I may have a really powerful/dangerous/unnecessary command that I've typed, and all I want to do is just cancel, not execute the command.

If it really is dangerous, I empty the buffer with ggVGd, in case something has slipped off the top of the screen.

BTW, you don't need set -o vi to be able to invoke vim on bash's command line. Even with set -o emacs, "fc" starts vim for me, (because my /usr/bin/editor is linked to /etc/alternatives/editor which links to /usr/bin/vim.gtk), as does <ctrl-x><ctrl-e>. Hmm, I think I'll export EDITOR="gvim -f" in my .bashrc to get my vim version and also be able to copy and paste from the terminal window.

Also set -o vi enables a lot of simple vi-like stuff (f.ex., <esc> kkkk gets you to the fourth previous command).

Regards, John

[AK]

On 03/23/2012 08:21 PM, John Little wrote:
> Also set -o vi enables a lot of simple vi-like stuff (f.ex.,<esc> kkkk gets you to the fourth previous command).
>
> Regards, John

Numbered commands like 4k work too, of course. I use 2k very often, but
I don't think I ever use higher numbers than that. -ak

[Ven Tadipatri]

Hi Christian,

   For some reason :q! doesn't work for me. I tried the :cq that Gary & Taylor suggested, and it 

worked perfectly.

   It looks like I can also delete the lines, then save the buffer with :wq and that works too.  

You're right-it looks like bash just executes the file with the timestamp changes, so if I 

save a blank file, then nothing happens.

   There's a lot you can do on the command line with "set -o vi", 

but sometimes it's nice to just be able to go into vim and be able to edit there, using

buffers, etc. 

   For now, I think I'll stick with :cq. Thanks for the advice everybody!

-Ven

    

On Fri, Mar 23, 2012 at 12:16 PM, Christian Brabandt <cbl...@256bit.org> wrote:

Hi Ven!

Mit freundlichen Grüßen

[Charles Campbell]

Ven Tadipatri wrote:
> Well...duh..there's an easy fix for this. Just prefix the command with '#'
> Then hit :wq to save it and "run" it. Still...why does it behave this
> way?
> Shouldn't I be able to choose not to run the command when I exit
> from Bash's vi editing mode?
> This is on a Centos 5 machine, and the terminal is a Gnome terminal.
>

It looks like several of the answers presume you're using vim/gvim
rather than the bash shell's vi-mode (ie. :cq, which doesn't work under
bash shell). Assuming that you actually meant to ask what should you
type while in the shell, not while in vim:

Try 0D

(move cursor to beginning of line, delete contents from cursor to
end-ofline)

Regards,
Chip Campbell

[AK]

I think dd is easier. The OP said, though, that he is talking about
vim launched from command line. -ak

[Charles Campbell]

> I think dd is easier, too. The OP said, though, that he is talking about

> vim launched from command line. -ak

Yes, dd will also work; and I agree that its easier to type.

I'm afraid that I've looked over the OP's first two messages and don't
see where vim was launched, though:

Title: Bash's vi command line editing mode
Excerpt: ...but when I do the "set -o vi" in the bash command line shell,...
Excerpt: ...if I hit <Esc> and v on the command line, it goes into vi
editing mode...
Excerpt: ...when I exit the editor it runs the command... (when one
exits Vim, typically it doesn't cause any commands to run)

Regards,
Chip Campbell

[AK]

When you hit Esc and v in bash (or zsh), it does start the vim
editor, and when you exit it, it puts the buffer in command line,
it doesn't run it immediately but waits for you to press Enter.

-ak

[Charles Campbell]

AK wrote:
>
> When you hit Esc and v in bash (or zsh), it does start the vim
> editor, and when you exit it, it puts the buffer in command line,
> it doesn't run it immediately but waits for you to press Enter.

Ah, I see -- I usually use ksh (pdksh, actually) and it doesn't do that.

Regards,
Chip Campbell

[Gary Johnson]

On 2012-03-27, AK wrote:

> When you hit Esc and v in bash (or zsh), it does start the vim
> editor, and when you exit it, it puts the buffer in command line,
> it doesn't run it immediately but waits for you to press Enter.

It has never waited for me, using either ksh or bash--the shell has
always immediately executed the contents of the vim buffer as soon
as I exit vim. I wonder if there is some shell option that controls
that.

Regards,
Gary

[AK]

I actually use zsh, and that's what it does, I only assumed bash
does the same. -ak

[Ven Tadipatri]

Hi Chip,

   Sorry for not being clear. I typed in a command from the bash shell, then launched vim by doing the <Esc> and v, which resulted in the command being put into vim. This is the part where I got stuck, because

it seemed like no matter what I did (:wq or :q!) it still executed the command when I exited vim.

   The solution was :cq, or alternatively, delete the command in the vim editor, but then rather than doing :q!, run :wq, so the blank command gets executed by Bash. 

   In my post I also tried to answer the questions some people were asking about why I couldn't do this 

directly on the command line, using the "set -o vi", and I was trying to explain how the vim editor (as opposed to the command line) gives you full access to all of vim's features (registers), whereas Bash's vi editing mode only allows for a small subset.  That and the fact that due to my own clumsiness, I accidentally find myself hitting <Esc> v and entering the vim editor sometimes when I don't want to.

Thanks,

Ven

On Tue, Mar 27, 2012 at 12:27 PM, Charles Campbell <Charles.E...@nasa.gov> wrote:

I'm afraid that I've looked over the OP's first two messages and don't see where vim was launched, though:

Title:  Bash's vi command line editing mode
Excerpt: ...but when I do the "set -o vi" in the bash command line shell,...
Excerpt: ...if I hit <Esc> and v on the command line, it goes into vi editing mode...
Excerpt: ...when I exit the editor it runs the command...  (when one exits Vim, typically it doesn't cause any commands to run)

Regards,
Chip Campbell

--

[Gilles Ruppert]

I'm having the opposite problem:

I use vi mode with bash on OSX (10.9). As expected, <esc> v puts the current command into a buffer. However, when I :wq, the command is *not* executed.

Could there be a setting in .vimrc that causes this?

[Christian Brabandt]

Play with the backupcopy setting and possibly also with 'backup'
and 'writebackup' options.

regards,
Christian

[Tony Mechelynck]

I tried ESC v in bash, and to my surprise, the command-line was opened
in Vim as a file in /tmp/ with a name starting with "bash-fc-". My
.vimrc had been run, and in particular my colorscheme was set. After :wq
or even after :q! bash tried to execute the command (and complained,
because it was a nonsense command). However, the command which bash
tried to execute was the *unmodified* command-line, not the result of
any edits.

The following options (q.v.) set by my vimrc may be relevant:
nobackup
writebackup
backupcopy=auto

Indeed, setting 'backupcopy' to "no" on entry into this Vim editor made
edits to the command-line relevant (so that, e.g., after prefixing # to
the line bash treated it as a comment and did not complain).

Another thing that I notice is that on return from this Vim commnd-line
editor, Bash finds itself (apparently) in vim-like "normal mode" so that
letters typed at the keyboard in bash seem to have no effect until one
of them is a or i. Then bash "starts working again".


Best regards,
Tony.
--
"Wouldn't it be terrible if I quoted some reliable
statistics which prove that more people are driven
insane through religious hysteria than by drinking."
[W. C. Fields]

[Gary Johnson]

On 2013-11-08, Tony Mechelynck wrote:
> On 07/11/13 12:58, Gilles Ruppert wrote:
> >I'm having the opposite problem:
> >
> >I use vi mode with bash on OSX (10.9). As expected, <esc> v puts
> >the current command into a buffer. However, when I :wq, the
> >command is *not* executed.
> >
> >Could there be a setting in .vimrc that causes this?
> >
> I tried ESC v in bash, and to my surprise, the command-line was
> opened in Vim as a file in /tmp/ with a name starting with
> "bash-fc-". My .vimrc had been run, and in particular my colorscheme
> was set. After :wq or even after :q! bash tried to execute the
> command (and complained, because it was a nonsense command). However,
> the command which bash tried to execute was the *unmodified*
> command-line, not the result of any edits.

When I do that, bash executes the edited version of the command, as
it should.

> The following options (q.v.) set by my vimrc may be relevant:
> nobackup
> writebackup
> backupcopy=auto

nobackup
writebackup
backupcopy=yes

> Indeed, setting 'backupcopy' to "no" on entry into this Vim editor
> made edits to the command-line relevant (so that, e.g., after
> prefixing # to the line bash treated it as a comment and did not
> complain).
>
> Another thing that I notice is that on return from this Vim
> commnd-line editor, Bash finds itself (apparently) in vim-like
> "normal mode" so that letters typed at the keyboard in bash seem to
> have no effect until one of them is a or i. Then bash "starts working
> again".

Mine does that, too. Very annoying. I don't remember it ever not
doing that, though.

I used to use ksh on HP-UX and it did not have that problem--the
shell worked fine after an Esc-v edit.

Regards,
Gary

[LCD 47]

On 8 November 2013, Tony Mechelynck <antoine.m...@gmail.com>
wrote:
[...]

> I tried ESC v in bash, and to my surprise, the command-line was opened
> in Vim as a file in /tmp/ with a name starting with "bash-fc-".

That's actually a feature of readline, not bash itself (but bash is
usually linked against readline). If you set "editing-mode" to "vi" in
your inputrc you can do line editing like this (the default is "emacs").

[...]

> After :wq or even after :q! bash tried to execute the command (and
> complained, because it was a nonsense command). However, the command
> which bash tried to execute was the *unmodified* command-line, not the
> result of any edits.

Use :cq to abort the command. As you found out, :wq executes the
modified command, and :q! executes the unmodified one.

[...]

> Another thing that I notice is that on return from this Vim
> commnd-line editor, Bash finds itself (apparently) in vim-like "normal
> mode" so that letters typed at the keyboard in bash seem to have no
> effect until one of them is a or i. Then bash "starts working again".

If you don't care about command line being modal, set "editing-mode"
to "emacs". You can still edit the command line with "fc" (a bash
internal command), or with C-x C-e. The program pointed to by $EDITOR
is run for that purpose.

/lcd

[Michael Henry]

On 11/08/2013 07:24 PM, Gary Johnson wrote:
>> After :wq or even after :q! bash tried to execute the
>> command (and complained, because it was a nonsense command).

Bash executes the command if the editor returns with success; to
avoid execution, you can use Vim's :cq command, which is like
:qall! except that the exit status will be non-zero.

Michael Henry

[Tim Chase]

On 2013-11-09 14:12, LCD 47 wrote:
> If you don't care about command line being modal, set
> "editing-mode" to "emacs". You can still edit the command line
> with "fc" (a bash internal command), or with C-x C-e. The program
> pointed to by $EDITOR is run for that purpose.

Even as a pretty die-hard vi/vim user, I still use "emacs" mode on
the command line and then use fc or ^X^E (as LCD47 suggests) if I
actually need to perform complex edits. I find this mirrors my
vi/vim usage, where I want emacs-like commands when actually
adding/entering things (Insert mode and command-line mode), but if
I'm editing by making complex changes, I want the full power of
vi/vim to do that. I can even use

:r ~/.bash_history

to read in the history of commands if I want to find/select/edit a
past command.

-tim

[LCD 47]

On 9 November 2013, Tim Chase <v...@tim.thechases.com> wrote:
> On 2013-11-09 14:12, LCD 47 wrote:
> > If you don't care about command line being modal, set
> > "editing-mode" to "emacs". You can still edit the command line
> > with "fc" (a bash internal command), or with C-x C-e. The program
> > pointed to by $EDITOR is run for that purpose.
>
> Even as a pretty die-hard vi/vim user, I still use "emacs" mode on the
> command line and then use fc or ^X^E (as LCD47 suggests) if I actually
> need to perform complex edits.

[...]

One more thing: if you dislike the ^X^E sequence you can override it
by binding "edit-and-execute-command" in your inputrc. Example:

"\ev": edit-and-execute-command

/lcd

[Gilles Ruppert]

I played with the backupcopy and backup settings:

originally, they were set to:
nobackup
nowritebackup
backupcopy=no

I tried enabling some/all of them, but still no luck.

I then just removed my .vimrc, which made the command execute. Then I went with a good old trial and error: comment out my entire .vimrc and enable section after section. Luckily, it was already the 2nd paragraph that broke the execution: it is my pathogen settings:

filetype off
silent! call pathogen#runtime_append_all_bundles()
silent! call pathogen#helptags()
filetype plugin indent on

I tried commenting in/out just individual lines, but they all broke it. After some more fiddling around, I came up with this workaround, which looks nasty (and I'm not happy about it) but it works:

if expand('%:t') =~?'bash-fc-\d\+'
setfiletype sh
else
filetype off
silent! call pathogen#runtime_append_all_bundles()
silent! call pathogen#helptags()
filetype plugin indent on
endif

Basically: when I'm editing commands, I prevent pathogen from running (which means none of my plugins get loaded). If somebody has a better way or knows what I need to do to pathogen to make it work, please let me know!

In the meantime, I hope this helps other people in my position.

[LCD 47]

On 11 November 2013, Gilles Ruppert <gil...@madeofbytes.com> wrote:
> I played with the backupcopy and backup settings:
>
> originally, they were set to:
> nobackup
> nowritebackup
> backupcopy=no
>
> I tried enabling some/all of them, but still no luck.
>
> I then just removed my .vimrc, which made the command execute. Then
> I went with a good old trial and error: comment out my entire .vimrc
> and enable section after section. Luckily, it was already the 2nd
> paragraph that broke the execution: it is my pathogen settings:
>
> filetype off
> silent! call pathogen#runtime_append_all_bundles()
> silent! call pathogen#helptags()
> filetype plugin indent on

[...]

I believe the preferred way to run pathogen these days is to replace
all that with a single line:

execute pathogen#infect()

and run :Helptags only when installing new plugins. This way it doesn't
interfere with command line editing.

/lcd

[Gilles Ruppert]

On Monday, 11 November 2013 11:50:28 UTC+1, LCD 47 wrote:
> I believe the preferred way to run pathogen these days is to replace
>
> all that with a single line:
>
>
>
> execute pathogen#infect()
>
>
>
> and run :Helptags only when installing new plugins. This way it doesn't
>
> interfere with command line editing.

I tried this, but unfortunately it didn't work either.

Thanks for the tip though. I updated my version of pathogen and changed my vimrc to use the new function.

[LCD 47]

On 11 November 2013, Gilles Ruppert <gil...@madeofbytes.com> wrote:

> On Monday, 11 November 2013 11:50:28 UTC+1, LCD 47 wrote:
> > I believe the preferred way to run pathogen these days is to
> > replace all that with a single line:
> >
> > execute pathogen#infect()
> >
> > and run :Helptags only when installing new plugins. This way it
> > doesn't interfere with command line editing.
>
> I tried this, but unfortunately it didn't work either.

[...]

Then there is something else going on, since it works fine here...

/lcd

[Gilles Ruppert]

On Monday, 11 November 2013 12:41:35 UTC+1, LCD 47 wrote:
> Then there is something else going on, since it works fine here...

Maybe it's a combination of things on my system. The workaround is fine for now. Once I have more time, I will have another look at this. If I find the culprit (probably an incompatible bundle?!?), I will post here.

Gilles

[LuKreme]

On Nov 11, 2013, at 3:50, LCD 47 <lcd...@gmail.com> wrote:
> I believe the preferred way to run pathogen these days is to replace
> all that with a single line:
>
> execute pathogen#infect()

<giggle>

--
Sign sign, everywhere a sign