Hacker News Reader

Comment by FranOntanaya | Hacker News Reader

I'm afraid they'll manage to launch vim and will never be able to get out.

They should read the book "Popular Unix text editors and how to exit them"

Thank you both for inciting a fascinating combination of uncontrollable laughter and existential dread

  quit
  ?
  exit
  ?
  end
  ?
  done
  ?
  bye
  ?
  quit!
  ?
  ^X  
  ?
  ^C
  ?
  ^C
  ?
  help
  ?
  ?
  ?
  ^Z
  $ killall ed
  $ vi

:q!

https://www.youtube.com/watch?v=AiM5zEEI_Jo

You mean that isn't how to exit 'ed'?

Technically, the official method of exiting ed, if you're running as root, is:

    $ed a_file
    ... (normal usage)
    r /etc/motd
    w /boot/vmlinuz-3.19.0-16-generic (replace with specific kernel)
    !reboot

The alternative of "w /dev/sda1" is also acceptable.

Note to those objecting to '$': I have PS1 set to '$' on every account. It just saves confusion.

Don't you think it is prettier with the space?

Nah, just adds clutter.

[Fixed in the great-grandparent.]

^D^D should do it

    eat flaming death
    ?

http://www.gnu.org/fun/jokes/ed-msg.txt

Ctrl-z works universally, doesn't it?

Not really. Some programs disable it including vim (at least on some setups).

Every vim I've ever played on has respected `ctrl-z`. In fact, I use `ctrl-z` to jump out of my vim (to restart a server, ls the local dir, etc).

My vimrc has

    source $VIMRUNTIME/mswin.vim
    behave mswin

which maps Ctrl-z to undo.

You monster.

Well I'll be damned. Never thought of trying it. Thank you.

it doesn't, ctrl-z only suspends process and switches to backgroud - the thing is still alive try ctrl-z and then type bg command - you will see a list, you can resume with fg [number]

Well, it might still run but it lets you out of the editor, which is the goal here. You can just kill -9 it afterwards.

If you have good reflexes, you can type "^Z" right after "kill -9", before the syscall to send the signal is executed.

Legend has it that, if you do, you bring on the Singularity immediately.

There is no reason for -9 here - all the major unix editors happily exit on SIGTERM.

Ctrl-z by itself doesn't actually switch the process to run in the background, it stops the process. Running 'bg' is what starts the process back up running in the background, 'fg', like you said, resumes the process in the foreground and 'jobs' is the command you can run to see a list of processes that are running.

With bg, it is likely to suspend itself again by attempting to read from the terminal (which a text editor is likely to do basically all the time).

Since the question was "Ctrl-z works universally", I feel obliged to point out that ctrl-z sends SIGTSTP, which can be blocked--not to be confused with SIGSTOP, which cannot be blocked. I don't know of any program that does intercept SIGTSTP (except a test program I wrote that tries to print the name of any signal it receives), and I suspect that "polite" interception would be to release a few resources and then accept being paused--but, in theory, a program could ignore it.

Many curses programs (for example vim) intercept ^Z to set the terminal back into a more normal mode and then pause.

This is probably a stupid question, didn't know about bg and fg before. But after playing around with it, it feels pretty amazing, why even use screen/tmux when you have these?

Screen has aaugh easier interface for multitasking, including things like stderr not bleeding out from whatever background tasks you're running. Not to mention that switching back and forth between screens is what it's designed for and thus a lot easier than switching between job numbers. Also the ability to detach your screen and its running processes from being coupled to a specific login session, which is probably the main reason I started using screen instead of multiple terminals in the first place.

this has got to be trolling. right? right?! i'm so confused.

Back when I first started my CompSci degree, a friend of mine always "quit" emacs with ctrl-z. Or, at least he did until he managed to fill his entire home directory quota with emacs backup files that were never cleaned up...

Ha, I still do that!

    $ jobs
    [4]   Stopped                 emacsclient -a '' -nw [redacted]  (wd: [redacted])
    [5]   Stopped                 emacsclient -a '' -nw [redacted]  (wd: [redacted])
    [6]   Stopped                 emacsclient -a '' -nw [redacted]  (wd: [redacted])
    [7]   Stopped                 emacsclient -a '' -nw [redacted]  (wd: [redacted])
    [8]   Stopped                 emacsclient -a '' -nw [redacted]  (wd: [redacted])
    [9]   Stopped                 emacsclient -a '' -nw [redacted]  (wd: [redacted])
    [10]   Stopped                 emacsclient -a '' -nw [redacted]  (wd: [redacted])
    [11]   Stopped                 emacsclient -a '' -nw [redacted]  (wd: [redacted])
    [12]-  Stopped                 emacsclient -a '' -nw [redacted]  (wd: [redacted])
    [13]+  Stopped                 emacsclient -a '' -nw [redacted]

But since they're all emacsclients it doesn't really matter.

`fg` is your friend

Don't you frequently deal with:

  /private/tmp/foo.txt locked by jnpatel@mac... (pid 14836): (s, q, p, ?)?

because of the lock files?

Nope, because emacsclient ends up opening them all in the same process (that's the beauty/entire point): Fork off an emacs in the background:

  emacs --daemon

Then run emacsclient to connect to it (open a new buffer in the daemon and switch to it):

  emacsclient -nw some_file

When you "quit" (with C-x C-c), it really just quits that client, but the main emacs is left running.

This has a number of benefits: 1) no locks like you mention, 2) access to all open buffers (even unsaved) from every emacsclient that's currently running (since they're really all just opening buffers in a single instance), 3) blazing startup speed (emacs is already running, you're just connecting to it and splatting a new buffer to the terminal).

I still remember how happy I was when I found out about that. On all servers I use (at home and at work), starting an emacs daemon is usually among the first things I do after rebooting.

Do you know about the "--no-wait" option for emacsclient?

Yes. But it doesn't play well with "-nw".

Ah yes, good point. In that case, the solution is `C-x #` to finish an emacsclient session without causing the server to quit.

Luckily C-x C-c also does that now.

I was much too easily convinced that this could be a real book.

We can make it one! Who'll launch the kickstarter?

Top contributor decides which editor we write it in.

Can it be proprietary?

... can it cost more than my contribution?

Accompanied by coffe table book 'Greatest screenshots of ruby in Sublime with dark themes'

Not to be confused with the book "Popular Unix text editors and how to nest them".

Which is a book inside a smaller book which is inside a smaller book ...

... published as a Jupyter notebook of a LaTeX document of a markdown file containing Perl POD comments. ;)

My "favorite" thing is when you hit Ctrl-C, and Vim says "Type :quit<Enter> to exit Vim". Vim isn't dumb. It knows what Ctrl-C means, it knows what you wanted to happen. But it's gonna make you do it its way anyway, because fuck you.

Much like Python

    Python 2.7.9 (default, Mar  1 2015, 12:57:24) 
    [GCC 4.9.2] on linux2
    Type "help", "copyright", "credits" or "license" for  more information.
    >>> quit
    Use quit() or Ctrl-D (i.e. EOF) to exit
    >>>

thats because you don't want to be using a variable quit and have it suddenly exit.

I would think that it's because ViM wants you to learn something about how the it works.

If it just exited with Ctrl-C, you'd never get to know about the : magic.

Not to mention Ctrl-C is ambiguous. What to do: Exit and save? Exit without saving? What if it's a new file? And probably others I'm not thinking about right now.

Actually, that's a feature... Ctrl-C exits insert mode. If it quit vim when in Normal mode, you'd accidentally quit Vim all the time. Less annoying to just show a helpful message in case you actually meant quit, than dump everyone who knows what Ctrl-C does back to a shell.

I think more important than exiting insert mode is (as I described in a peer comment, hopefully clearly) killing foreground processes you've spawned out of vim. 1) With exiting insert mode there's the option of using escape instead (or capslock or jk or whatever people bind it to), and 2), I think most importantly, with killing processes there's an actual race condition: if the command finishes after I decide to kill it and before vim registers my Ctrl-c, exiting is totally the wrong thing to do.

Definitely a feature not a bug.

    :'a,'b!longrunningcommand

oh, wait, that was not the right thing...

    C-<longrunningcommand finishes>c

Or emacs.

Or vim inside emacs' terminal emulator.

Orders of magnitude more likely that vi will get launched than emacs :-)

Unfortunately, Vi is on the Arch install disc, but Emacs isn't (unless it's changed very recently). Though they of course could install it.

The arch install disk also has vim. The base install of arch doesn't include vim, but does include vi.

> Or vim inside emacs' terminal emulator.

I've been there, by accident, two or three times.

The first time was really scary, since I did not know vi, yet, and did not know how to exit it or what in the world was going on...

Pretty sure it will be "rm -rf /"'d by trolls before that.

It's been awhile since a fresh install but is it ViM. is Vi still around? I just seem to recall some things not working right. Such as not being able to ZZ or ZQ out of a file.

vi is built-in in arch installation. so...

Vi is everywhere. Its part of the POSIX standard and comes out of the box (in one flavor or another) with every Linux Distro, OSX, HP-UX, AIX, Solaris, Darwin, FreeBSD, OpenBSD, and DragonFlyBSD.

ViM is just Vi iMproved. They share most their keybinds but VIM has the whole plugin architecture thing.

This is a big sticking point for a lot of VIM users [1]. If you ever end up on a Unix box that doesn't have VIM, you can always fall back on Vi.

[1]: /users/religious fanatics/

At least on Ubuntu, vi is really VIM:

    zck@zck-desktop:~$ vi --version
    VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Jan  2 2014 19:39:32)

Eh, yeah, but it usually links to the "basic" version (which, I assume, is compatibility mode for old school vi).

    root@dicks:~# which vi
    /usr/bin/vi
    root@dicks:~# file /usr/bin/vi
    /usr/bin/vi: symbolic link to `/etc/alternatives/vi'
    root@dicks:~# file /etc/alternatives/vi
    /etc/alternatives/vi: symbolic link to    `/usr/bin/vim.basic'
    root@dicks:~# file /usr/bin/vim.basic
    /usr/bin/vim.basic: ELF 64-bit LSB  executable, x86-64, (snip)
    root@dicks:~# vi --version
    VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Jan  2 2014 19:39:32)

On Arch, vi is the original Bill Joy vi.

    $ vi --version
    vi: illegal option -- -
    Usage: vi [- | -s] [-l] [-L] [-R] [-r [file]] [-t tag]
           [-v] [-V] [-w size] [+cmd | -c cmd] file...
    $ pacman -Qi vi
    Name           : vi
    Version        : 1:070224-2
    Description    : The original ex/vi text editor
    Architecture   : x86_64
    URL            : http://ex-vi.sourceforge.net/
    Licenses       : custom:ex
    Groups         : base
    Provides       : None
    Depends On     : ncurses
    Optional Deps  : s-nail: used by the preserve command for notification [installed]
    Required By    : None
    Optional For   : None
    Conflicts With : None
    Replaces       : None
    Installed Size : 290.00 KiB
    Packager       : Evangelos Foutras <evangelos@foutrelis.com>
    Build Date     : Sun 06 Sep 2015 03:34:15 PM EDT
    Install Date   : Fri 18 Sep 2015 10:33:33 PM EDT
    Install Reason : Explicitly installed
    Install Script : No
    Validated By   : Signature

(ok, I'm not actually on Arch, but I'm downstream of Arch, and that package is directly from Arch)

You are correct:

https://www.archlinux.org/packages/core/x86_64/vi/

ZZ and ZQ work, at least on every instance of vim I've ever used

vim defaults to 100% backwards compatible with vi. It has an option "nocompat" that enables some non-backwards compatible improvements.

ZZ definitely still works regardless of nocompat though.

Reply on news.ycombinator.com