Rather than temporarily suspend vim to use the terminal you can get vim to suspend and resume itself with the exclamation mark command. This has the benefit of not wreaking havoc on your vim session and allowing you to read data into vim by prefixing with r.
For example
:!ls
will execute ls and show you the result (press enter to return)
:r!ls
will read the result of ls in for you
More usefully
:r!sed -n5,10p that/other/file
will read lines 5-10 from that other file.
However you will most often want to
:!make
:!up build
:!git status
:!git commit -am "Fixed #23"
I didn't know about :r in combination with !. That's neat. I typically use :r for reading a file into the current buffer (instead of cp <file> <new>). Thanks for sharing.
I don't find myself using ! commands when I know there are multiple commands that I need to run (like your last example). That's usually when I'll suspend and then use the command line.
Could you elaborate on "wreak havoc on your vim session?" I wasn't aware that suspending the process and bringing it back into the fg would harm anything.
This is also useful for iterating on a throw-away script - something too long to type on one line in the shell, but not significant enough to be worth saving to a file. Put it together in an unnamed buffer, and ":w !" it to the relevant interpreter (eg ":w !perl") whenever you want to run it.
Though I understand that this is just an example of the power of `!r`, readers should know that VIM in fact can copy to the system clipboards natively.
Only if it's compiled with clipboard support. I don't know about in other places, but in the default Arch package it's not. So this command is a perfect solution for me.
That requires that vim be compiled with the xterm-clipboard feature enabled. On my Fedora 24 desktop, vim doesn't have it enabled, but gvim does (according to the output of the :version command).
One advantage of the method you describe is that it can be limited to just part of a line. Piping output to xclip is limited to complete lines of text due to the nature of :w !.
It's more of a way to be able to commit without having to exit or suspend vim. I typically type the commit message while checking the diff. If I find an error in the diff, I'll switch to the vim window with the file, correct the issue and run :!git add %, delete the original output of the git status -v command I ran earlier and I re-run that command (which I can pull up by using q: to bring up the vim command history window).
My personal favourite trick with ":r!" is, in a new buffer, running
:0r! grep -rn $pattern $path_to_directory
or any other command that outputs lines containing "$path_to_file:$line_no" (eg most linters).
With that output read into a buffer, placing the cursor anywhere in the "path:line" part and hitting ^wF will open that file in a new split window, and jump the cursor straight to the indicated line - or you can do ^wgF to do the same in a new tab page.
It's a very handy way to work through a big list of work items spread across many files. You do need to coax the right format for it out of your tools, but fortunately "path:line" is pretty de-facto standard.
(Incidentally, I do ":0r" so it inserts the read-in lines at the very top of the file - just ":r" in an empty buffer leads to a leading blank line, which I find irrationally annoying.)
I know that vim has the built in :grep command that does what you describe. The results are listed in the preview window and pressing enter will open the corresponding file and place the cursor at the desired line.
Well, yes... okay, maybe that was a poor choice of example, :grep is probably more ergonomic for that particular use case.
The trick I described is more for when you're dealing with some unusual program that wouldn't work with :grep - at least not without fiddling with 'grepprg' to invoke it, and/or 'grepformat' to correctly interpret its output.
one can turn that file/buffer directly into a quickfix list, where simply enter will take one to the relevant position. Messages with column positions are recognized in quickfix lists (:help errorformat).
Yes, good ones. Running ! commands can also be done in command mode, without using last line mode (those who don't know the difference can see https://gumroad.com/products/vi_quick ). I use variations of commands like this a lot, as needed:
1G (to go to top of file if not already there)
!Gsort (to filter all the lines in the file through the sort command, and replace the file contents with the sorted lines)
which says: filter all the lines would be traversed over as a result of running the G command (which goes to the last line in the file) through the sort command, and use the output of the sort to replace all the lines that were filtered;
sort can be replaced with any other command that is a filter, e.g. fmt, grep, sed, many more;
(note: no need of colon in the above command, just have to be in command mode, not input mode, which you get into by pressing Esc).
Very powerful, just that feature, particularly in programming.
I personally still prefer to background the process. Rarely is it ever just 1 command you want to run. For example, you want to git commit, push, oops need to rebase, oops don't have all of my files added... etc etc.
For that reason I just jump out with a ctrl+z and when I'm done I'm back in with a fg!
:.!ls means "filter the current line through ls". Since ls ignores stdin, the effect is that the current line gets replaced by its output. :r!ls just inserts the output, without replacing anything.
Interesting. Your use of `git commit -am` resounded with me. I can't stand doing `git add .` ; `git commit -m "message"`; `git push`. I aliased "commit" to "ci" in git-config, and then do `git ci -am "message" && git push`. I'm sure at some point I will add a hook to have the push done automatically (though sometimes I prefer to do it manually, so I will have to make a decision.)
I am an avid emacs user though. I really should check out vim.
As an Emacs user, why not use magit? Staging, committing and pushing would be just a few key presses ('C-x g S c c <write message and C-c C-c> p P' assuming magit bound to 'C-x g'). You also get to view the status and diffs along the way.
You actually don't have to put ! In front of make. Vim has makefile integration. If all you're doing is typing make, you can do :make. For a custom build command, you can set the variable makeprg, and :make will execute that instead. On my phone so it's hard to type examples, this blog post gives more info:
tmux is a good alternative to the whole paradigm of 'running shell commands within a text editor like vim'. Why run a shell command within vim when one can run the shell command in an actual shell? It seems to me that running a shell command in vim is using vim outside of its intended scope. It might be able to do it but it won't be able to do it well, which is where something like tmux comes in. I might be in the minority with this viewpoint though.
(pedantic note: When you run shell commands in vim, they are running in an actual shell.)
vim can be thought of as a visual and interactive helper for your text-processing utilities. The "intended scope" of vim is text editing, and while you're editing you may want to run commands on the text in your buffer, or just parts of it, and have the results apply immediately without writing and reloading the file, or exiting.
For example, in vim, you may be writing a list somewhere in your document, and you realize you want it sorted alphabetically. You can visually select the range of lines ('<,'>) that comprise the list and then sort them by calling the sort utility [1]:
:'<,'>!sort
And then you can continue adding to the list.
What would your workflow be for the above? Some like this...?
1. write the file you are working on in your EDITOR
2. make a mental note of the absolute line numbers for the list in the document
3. open new terminal
4. call an awk command that uses `sort`, or some other script, passing in your line numbers, and the file name
5. switch back to EDITOR and reload file
----
[1] Of course vim has its own `sort` command, so you can leave out the '!' in that example to do the same.
vi did not have its own `sort`, so people used the external `sort`. vi also didn't have the visual selection, so people could pick lines using ranges:
:.,+10!sort
i.e. sort from the current line to the line 10 lines down, inclusive
It's interesting to read up on the relationship between ed, sed, ex, and vi. In fact, all 4 of those editors have similar ways of addressing line ranges (1 for the first line, $ for the last line, etc).
One interesting feature many people may not know about is that it's possible to address lines using a regular expression.
For instance, if you had the following text in a vim buffer:
one
two
three
four
five
and you wanted to delete the lines between "two" and "four" inclusive, you could run the following command in vim:
For changing directories, you can also use something like z (https://github.com/rupa/z) to jump around:
Tracks your most used directories, based on 'frecency'.
After a short learning phase, z will take you to the most 'frecent'
directory that matches ALL of the regexes given on the command line, in
order.
For example, z foo bar would match /foo/bar but not /bar/foo.
I've been thinking about wanting something akin to this, I just had no idea it existed, so what I've been doing instead is I've defined short aliases for some of my most frequent directories. I use such an alias which I have named "no" which does "cd /var/www/no.nordstroem.www/pub/htdocs" on my Raspberry Pi where I host my website. For most directories on my laptop and desktop rather than using an alias even though I might have defined one is I first try a reverse search for it in the shell history, for example ^Rklon to get to ~/src/github.com/eriknstr/klondike/. However reverse search will fail whenever I haven't worked with a directory for a while or if I've been doing a lot of things in one directory since I have chosen to leave the length of the shell history at its default.
I would have liked to maybe start using the command you linked but unfortunately it is using the WTFPL so I will have to pass on it. But from the short description you quoted maybe I'll implement a similar tool myself some day. Then again maybe I will just keep doing things the way I'm doing them now because usually most of what I do is I go to a specific directory and do a lot of work there without moving much, typically said directory will be the root of the repository I have for what I'm working on. If I'm working in several project root directories at the same time I'll usually have multiple terminals open.
He means “ctrl-w”. But since that only works in bash, not in Emacs or other tools with Emacs key bindings, it makes more sense to use (in his terminology) “alt-backspace”. This does the same thing, and works both in the shell and in Emacs-like environments.
Another advantage to using alt-backspace over ctrl-w is that the former has the same semantics as alt-b. ctrl-w considers a word to be anything surrounded by spaces, whereas alt-b and alt-backspace consider a word to be any consecutive string of word characters.
The article is nice but a small part of it rubs me the wrong way:
> I know there are some cool newcomers out there like zsh and fish, but after trying others out I always found that some of my utilities were missing or ill-replaced.
First of all bash was first released in 1989 and zsh arrived just 1 year later so zsh is in no way a newcomer.
Secondly zsh is almost strictly a bash superset so I don't know what he was missing (or what he found "ill-replaced").
I wasn't so much commenting on the release date when I said "newcomers." Mostly commenting on my personal experience. I've been using bash for a long time and only recently have I seen zsh get so popular. It's entirely possible that only the people I know have only recently taken an interest in it.
I would have to run zsh again to remember the pieces that I didn't like. I might have been able to configure my way around it, but I do remember things not working as I expected them to.
zsh was quite popular when I first went spelunking in *NIX-land (2005). oh-my-zsh, which was a decent boost to zsh popularity, seems to have been around since 2009 (http://ohmyz.sh/).
zsh has always been held back by the "default browser"-syndrome: Linux and Mac OS both come with "good enough" default shells, so few people actually want to go through the effort of switching.
Especially since there is a bit of a learning curve to becoming more productive with zsh than you already are with bash.
The problem with installing zch on my desktop is that I won't have it on the servers I SSH into. I need to know the proper spells and incantations that will work on a wide variety of distros and versions, many of which I don't personally maintain. Therefore, bash.
Indeed. The same argument applies to other exotic tooling, interesting vim plugins with many dependencies, etc.
It's one reason to keep one's environment relatively standard and boring. Otherwise, one comes to be dependent -- psychologically, at least -- on one's meticulously configured custom environment, and either chafes at its absence elsewhere or spends a great deal of time copying it everywhere.
Conversely: I have the Z shell on all of the systems that I SSH into, ranging from OpenBSD to Debian Linux. I even have it on Interix on Windows as well. Many of them also have the Almquist shell and various flavours of the Korn shell available. A few even have the Thompson shell. (-:
This was the argument that persuaded me to switch from zsh to bash decades ago. But after a while I realized that it really didn't matter whether you used zsh on your own machine. When you ssh in to another machine that has bash on it, it's going to be similar enough that you're not going to feel lost.
Bash and zsh only differ in some of their more advanced features, which I rarely use or miss on machines I ssh in to -- unless I spend most of my time on those remote machines, in which case I'll just install zsh there too. The main thing from zsh that I do miss on bash is advanced globbing, which is more convenient than the find command, but when I'm forced to use bash I'll just use find, and it's really no big deal.
So I encourage you not to let the fact that most machines have bash installed on them deter you from switching to zsh, if you're interested in zsh. I know I regret the years lost that I didn't use zsh myself.
Also, when you use a lot of scripts that only work with bash (there are more than you'd expect, despite zsh saying it is bash compatible) then you have the choice of either rewriting these scripts or using bash. Most ppl will choose not to rewrite.
Many scripts are not written to be portable, bash or otherwise. The main reason those scripts rely on bashisms is that bash has long been the default shell in most distro.
IIRC debian provides a checkbashisms to know which scripts will pose problems when ran against /bin/sh
zsh never claimed it was compatible with bash. I'm not sure where you got that impression from. Maybe you're thinking of sh -- the bourne shell -- which zsh is in fact compatible with (as long as you limit your scripts to the bourne shell subset of zsh).
I'm not sure, where I've read it specifically, but it was a feature I was looking fore before switching to zsh about 5 years ago. What I found now is this: https://wiki.archlinux.org/index.php/zsh
Anyways. The core point is that compatibility often means compatible in 90%-99% of the cases. It's really really hard to be 100% compatible, which also requires one to emulate bugs etc.
The web page you link to is mistaken. The zsh command "emulate sh" does not emulate bash. As the name says, it emulates sh, which is the bourne shell -- not bash.
When I started using Unix in the early '90s, zsh was more popular than bash by a long way. And tcsh was more popular still. You had to be a GPL purist or something to want to use bash. Its success is really down to its status as the Linux default. If you try zsh again, you'll find the mailing list and IRC are full of helpful people if some things aren't as you expect.
Any ideas why tcsh was so popular and bash was considered oddball? A lot of the big old vfx houses I would work for came from Unix, so they still default everyone to tcsh. A lot of their tooling is based around it, so you're kind of required to use tcsh.
I like to come up with one-liners when doing stuff as a challenge and not being able to do a for-loop as a single line drove me nuts (keeping it one line is really useful when you're iterating over a command and using history). I also find subshells very handy in bash.
The piece you didn't like about zsh is probably the usual: it comes with no preconception of how you want to use it , i.e. with no default settings.
It requires some work to build zsh settings to one's personal preferences but once done you are at home.
Alternatively you can use one of the many settings you can find around, it is faster and simpler but now you're living in someone else' home.
On the other hand, if you look at the whole widgets section, I'm pretty sure you could hack it yourself since zsh supports used defined widgets (widgets are basically functions used by the zsh command editor).
I never said that it's easy, just that zsh is basically a bash superset. However that does mean that in some occasions this means that you want a Prius and instead get a Ford Mustang kit that you have to assemble yourself :D
On both version 4.3.12 on Interix and version 5.2 on FreeBSD, "f" followed by a character works perfectly fine in "vi" mode and Control-X Control-F followed by a character, as per the zshzle manual, works perfectly fine in "emacs" mode. What were you doing wrong?
all of these are my go-to tools. I also edit inputrc to make pgup and pgdn history search - something I picked up from SuSE version 15 years ago, and stuck.
Anyway, the message is pretty obvious: Apple won’t ship anything that’s licensed under GPL v3 on OS X. Now, why is that?
There are two big changes in GPL v3. The first is that it explicitly prohibits patent lawsuits against people for actually using the GPL-licensed software you ship. The second is that it carefully prevents TiVoization, locking down hardware so that people can’t actually run the software they want.
So, which of those things are they planning for OS X, eh?
I’m also intrigued to see how far they are prepared to go with this. They already annoyed and inconvenienced a lot of people with the Samba and GCC removal. Having wooed so many developers to the Mac in the last decade, are they really prepared to throw away all that goodwill by shipping obsolete tools and making it a pain in the ass to upgrade them?
Or, it could just switch the default shell to Z shell.
First thing I do on a new Mac, is chsh -> zsh.
Ships with an up to date (enough) version of that.
Yep looks like you're right, I could have sworn that zsh was after tcsh then bash from there on out. Went looking in my Mac OS X for unix geeks book and it was right on the transition so bad memory no cookie. I'll punish my brain with beer for its transgressions.
Personally, I found the following to be extremely easy and powerful. A no-brainer that should be a bash default really.
if [ -t 1 ]
then
# search for commands that start off with the same characters already typed
bind '"\e[A":history-search-backward'
bind '"\e[B":history-search-forward'
fi
One of my friends also recommended version-controlling your config files and storing them on gitlab, which I'm only sad I didn't do sooner. It's been such a help in keeping my aliases and configs in sync, as I make changes across numerous different machines.
That these, probably the most useful Readline functions by far, are not bound to any keys by default is crazy. To me it makes more sense to bind them to M-p and M-n though.
A good starting point for versioning dotfiles is https://dotfiles.github.io/. I like to use Dotbot [1] for managing and installing my dotfiles, but there are plenty of other options listed.
I'm curious about the popularity of Bash vis a vis, say, Csh. Is Bash more popular due to superior features, or is simply because it is the default on quite a few *nix distros (and macOS)?
I used to use zsh way back in the day because it was clearly superior to bash, then decades ago switched to bash because it was everywhere by default and my job involved using lots of computers that only had bash on them, then about 4 or 5 years ago I switched back to zsh because I realized that it really didn't matter that I used zsh on my own machine and bash on others, and zsh was still better than bash.
These days bash seems to have a lot closer feature parity to zsh, and I'd be curious to read an up-to-date comparison of both shells to determine if either is clearly better than the other.
shell is a bit like JavaScript: both languages have a lot of warts, but if you interact with UNIX-like systems / browsers at intermediate or above levels, you must be comfortable with them. Unlike browsers, you have a few choices for shells, and IMHO [t]csh lost because a) Linux "won" over *BSDs, b) POSIX basically standardized on sh, c) [t]csh is a worse scripting language.
Back in uni I used to use tcsh interactively, script in [ba]sh, and program in a "real language" like C, Java, etc., but I wasn't doing anything very complicated with any of them. Once I started working and begin using these tools seriously, I simply couldn't learn and retain all of them. Something had to go, and tcsh was it.
I use most of it on both GNU Linux and Mac. I have installed coreutils (GNU bins) and bash v4.4.5 via homebrew on Mac. It's probably safer to say these are more specific to Linux.
Worth it just for finding out about `stty -ixon`. I never would have guessed from the `stty` man page description that this option would give me back C-s and C-q to bind to something actually useful.
It is described perfectly, but it does presume the reader knows the meaning of "XON/XOFF flow control".
Whether the reader knows that meaning immediately is a rather good proxy for just how long they have been working and/or playing with computers. Long ago, in a world of RS-232 connected display terminals and/or analog telephone modems, one became very familiar with "XON/XOFF flow control".
Control-n right: So just type the start and control+n to search for the arguments/commands starting with whatever. And the classical up/down to look up for a complete history line:
I don't understand why the default bash/readline doesn't get something related for substring search or way better autocompletions, it's really not that hard definitely (actually quite easy) and even when that's the reason for a lot of people to choose zsh over bash.
About bindings, it would have been better to redirect to:
LESS=+/"DEFAULT KEY BINDINGS" man readline
assuming it exists on mac.
About suspend, what's the benefit of suspending vim using C-z? Shouldn't you use a terminal multiplexer instead, or even terminal tabs if you don't want to learn how to use tmux or screen (which I find weird if you already spent time to learn how to use vim but alright)?
I only ever suspend a program when I want it to stop, for instance because it slows other programs and I realize I would rather resume it when I'm not in front of my computer. Even in that case, I often just renice the program instead. Stopping a program just because you want to run some bash commands looks like an anti-pattern to me, but maybe there are better motives I'm not aware of.
I use tmux. The benefit of using suspend is not having to move around multiple windows/tabs. I try to keep those to a minimum (usually one or two). With suspend I can stick with the same tmux window for editing and cli within the same context. It's a personal preference over managing multiple windows.
To stay on the same window I would personally use a split-window depending on the size of the display. I didn't think about the context though, good point!
bash (and shells in general) are so hacky (in a bad way) that I wouldn't want to waste my time mastering them. Whenever a shell script grows beyond 10 or 20 lines, I try to rewrite it in a "real" programming language. Fancy shell tricks are a code smell to me, and clarity and simplicity are of far greater importance.
For me, as far as shells go it's usually enough to know the basics and be able to look stuff up when debugging other people's shell scripts.
While I understand this sentiment, I think it's a point that needs a bit more thought; it's not a black and white issue.
On my personal machines, I often find places where I want to either clean up my desktop experience or automate some workflow, where I break some shell out. Most of the time, the overhead to drop into an actual programming language is quite heavy, and even though I try to comment my scripts and write them in a maintainable fashion, I only end up editing them maybe a few times a year.
I feel like discouraging shell scripts is part of what's driving us to seek increasingly heavyweight solutions like systemd in our architecture. Sometimes a lightweight environment where we trust the programmer is needed.
I'm about as anti-systemd as you can get, but I also cringe whenever I look at some of those massive, convoluted shell scripts in SysVinit. There is a middle path, with runit[1], which mostly uses short, simple shell scripts for its process initialization and supervision.
Brevity and simplicity are really the keys when it comes to shell scripts. I really don't have a problem with them if they're short and don't try to be too clever. Whenever I've let my shell scripts get long or complicated, I've always regretted it, and always wound up rewriting them in a "real" programming language anyway, and then realizing that I would have been better off rewriting them much earlier, as soon as they'd outgrown the short, simple stage.
There's no shortage of relatively light-weight "real" programming languages like Perl, Python, Ruby, Lua, and Go -- for even moderately sophisticated tasks, all of them would be better choices than shell scripting.
I also assume you're using bash. I know there are some cool newcomers out there like zsh and fish
While there is much useful in this post, I always find comments like this one odd. bash was released back in 1989, zsh was released one year later, in 1990. One year difference in age almost thirty years ago means that you can't really call zsh a newcomer. Maybe he's talking about adoption, though.
I've had a similar thing recently. Somebody asked me about learning "old
technologies", like Perl and CFEngine. Perl 5.x was published in 1991, four
years after initial version, Python was published in the same year, and Ruby
merely 4 years later. CFEngine 3.x, a complete rewrite that carries over very
little and only very high level ideas from earlier versions, was released in
2008, three years after Puppet, and only one year before Chef.
In the spirit of sharing: one of my favorite lines in my bashrc is the alias of `rm` to `rm -i`. This prompts for a confirmation. You might not need it but I deleted some important, not-yet-checked-in-git files in the past by accident.
If you want to delete everything and don't want to keep typing yes just do `yes | rm bla`.
Rather than trying to remember all those commands for moving around in your command, I recommend turning on vim mode for the command line, and remapping ESC to "jk".
bindkey -v
bindkey -M viins 'jk' vi-cmd-mode
Then you can edit your command line the same way you would edit a line in vim.
The one tool that saved me quite possibly a few months of typing paths over my lifetime is autojump: https://github.com/wting/autojump. I can't imaging a terminal workflow without it.
This should be shouted out regulary to anyone using any type of command line until everybody uses it. I cringe everytime I see someone spelling out cd /mega/long/path/to/a/place/i/visit/multiple/times/every/single/day. Ok some of them already know about tab completion, but it just hurts to see that knowing all that's really needed is j d or z d or so.
When going past something with ctrl+r, use backspace rather than ctrl+s. less has movements similar to vim. In less, hit v to open the file in your editor.
Regarding history, another simple trick is to increase $HISTSIZE and $HISTFILESIZE, for the defaults are woefully tiny for 2017. I set mine to a million. You could have 100 terminals open and they would still consume less RAM than <insert "native" Electron app(s) of your choice>.
184 comments
[ 2.3 ms ] story [ 215 ms ] threadFor example
will execute ls and show you the result (press enter to return) will read the result of ls in for youMore usefully
will read lines 5-10 from that other file.However you will most often want to
For example, when reading xml I use xmllint to clean it up:
I don't find myself using ! commands when I know there are multiple commands that I need to run (like your last example). That's usually when I'll suspend and then use the command line.
Could you elaborate on "wreak havoc on your vim session?" I wasn't aware that suspending the process and bringing it back into the fg would harm anything.
You can even use :w in combination with !. For example
to write the vim buffer contents to the clipboard. You could visually highlight part of the buffer and do the same thing for just the text you want.One advantage of the method you describe is that it can be limited to just part of a line. Piping output to xclip is limited to complete lines of text due to the nature of :w !.
That's when I run !bash, enter my list of commands, then exit.
Try emacs with magit. It's really great.
With that output read into a buffer, placing the cursor anywhere in the "path:line" part and hitting ^wF will open that file in a new split window, and jump the cursor straight to the indicated line - or you can do ^wgF to do the same in a new tab page.
It's a very handy way to work through a big list of work items spread across many files. You do need to coax the right format for it out of your tools, but fortunately "path:line" is pretty de-facto standard.
(Incidentally, I do ":0r" so it inserts the read-in lines at the very top of the file - just ":r" in an empty buffer leads to a leading blank line, which I find irrationally annoying.)
The trick I described is more for when you're dealing with some unusual program that wouldn't work with :grep - at least not without fiddling with 'grepprg' to invoke it, and/or 'grepformat' to correctly interpret its output.
1G (to go to top of file if not already there)
!Gsort (to filter all the lines in the file through the sort command, and replace the file contents with the sorted lines)
which says: filter all the lines would be traversed over as a result of running the G command (which goes to the last line in the file) through the sort command, and use the output of the sort to replace all the lines that were filtered;
sort can be replaced with any other command that is a filter, e.g. fmt, grep, sed, many more;
(note: no need of colon in the above command, just have to be in command mode, not input mode, which you get into by pressing Esc).
Very powerful, just that feature, particularly in programming.
For that reason I just jump out with a ctrl+z and when I'm done I'm back in with a fg!
Is there a difference?
IMO, :make is (usually) better, because it adds errors to the quickfix list, and put your cursor on the first error location.
https://vi.stackexchange.com/questions/6679/terminal-setup-w...
I am an avid emacs user though. I really should check out vim.
https://jbernard.io/2011/09/30/vim-makeprg.html
vim can be thought of as a visual and interactive helper for your text-processing utilities. The "intended scope" of vim is text editing, and while you're editing you may want to run commands on the text in your buffer, or just parts of it, and have the results apply immediately without writing and reloading the file, or exiting.
For example, in vim, you may be writing a list somewhere in your document, and you realize you want it sorted alphabetically. You can visually select the range of lines ('<,'>) that comprise the list and then sort them by calling the sort utility [1]:
And then you can continue adding to the list.What would your workflow be for the above? Some like this...?
1. write the file you are working on in your EDITOR
2. make a mental note of the absolute line numbers for the list in the document
3. open new terminal
4. call an awk command that uses `sort`, or some other script, passing in your line numbers, and the file name
5. switch back to EDITOR and reload file
----
[1] Of course vim has its own `sort` command, so you can leave out the '!' in that example to do the same.
vi did not have its own `sort`, so people used the external `sort`. vi also didn't have the visual selection, so people could pick lines using ranges:
i.e. sort from the current line to the line 10 lines down, inclusiveOne interesting feature many people may not know about is that it's possible to address lines using a regular expression.
For instance, if you had the following text in a vim buffer:
and you wanted to delete the lines between "two" and "four" inclusive, you could run the following command in vim: You could also do the same thing in sedI would have liked to maybe start using the command you linked but unfortunately it is using the WTFPL so I will have to pass on it. But from the short description you quoted maybe I'll implement a similar tool myself some day. Then again maybe I will just keep doing things the way I'm doing them now because usually most of what I do is I go to a specific directory and do a lot of work there without moving much, typically said directory will be the root of the repository I have for what I'm working on. If I'm working in several project root directories at the same time I'll usually have multiple terminals open.
He means “ctrl-w”. But since that only works in bash, not in Emacs or other tools with Emacs key bindings, it makes more sense to use (in his terminology) “alt-backspace”. This does the same thing, and works both in the shell and in Emacs-like environments.
So, for me, it works in both shell and editor.
> I know there are some cool newcomers out there like zsh and fish, but after trying others out I always found that some of my utilities were missing or ill-replaced.
First of all bash was first released in 1989 and zsh arrived just 1 year later so zsh is in no way a newcomer.
Secondly zsh is almost strictly a bash superset so I don't know what he was missing (or what he found "ill-replaced").
I would have to run zsh again to remember the pieces that I didn't like. I might have been able to configure my way around it, but I do remember things not working as I expected them to.
zsh has always been held back by the "default browser"-syndrome: Linux and Mac OS both come with "good enough" default shells, so few people actually want to go through the effort of switching.
Especially since there is a bit of a learning curve to becoming more productive with zsh than you already are with bash.
It's one reason to keep one's environment relatively standard and boring. Otherwise, one comes to be dependent -- psychologically, at least -- on one's meticulously configured custom environment, and either chafes at its absence elsewhere or spends a great deal of time copying it everywhere.
Bash and zsh only differ in some of their more advanced features, which I rarely use or miss on machines I ssh in to -- unless I spend most of my time on those remote machines, in which case I'll just install zsh there too. The main thing from zsh that I do miss on bash is advanced globbing, which is more convenient than the find command, but when I'm forced to use bash I'll just use find, and it's really no big deal.
So I encourage you not to let the fact that most machines have bash installed on them deter you from switching to zsh, if you're interested in zsh. I know I regret the years lost that I didn't use zsh myself.
IIRC debian provides a checkbashisms to know which scripts will pose problems when ran against /bin/sh
Anyways. The core point is that compatibility often means compatible in 90%-99% of the cases. It's really really hard to be 100% compatible, which also requires one to emulate bugs etc.
I like to come up with one-liners when doing stuff as a challenge and not being able to do a for-loop as a single line drove me nuts (keeping it one line is really useful when you're iterating over a command and using history). I also find subshells very handy in bash.
It requires some work to build zsh settings to one's personal preferences but once done you are at home. Alternatively you can use one of the many settings you can find around, it is faster and simpler but now you're living in someone else' home.
http://unix.stackexchange.com/a/203075
On the other hand, if you look at the whole widgets section, I'm pretty sure you could hack it yourself since zsh supports used defined widgets (widgets are basically functions used by the zsh command editor).
I never said that it's easy, just that zsh is basically a bash superset. However that does mean that in some occasions this means that you want a Prius and instead get a Ford Mustang kit that you have to assemble yourself :D
mc allows to explore system efficiently while not standing in my way, because I can always press ctrl-O and get my shell back.
bash-completion saves time on typing of commands.
Other tools I install often are htop (better ps) and strace.
1. Ancient.
2. Will most likely never be updated by Apple
(Most GNU- and Linux-based systems, and also Windows, on the other hand, continue to use the latest versions.)
Nevertheless, I updated the post to add bash 4 to the assumptions.
http://meta.ath0.com/2012/02/05/apples-great-gpl-purge/
[…]
Anyway, the message is pretty obvious: Apple won’t ship anything that’s licensed under GPL v3 on OS X. Now, why is that?
There are two big changes in GPL v3. The first is that it explicitly prohibits patent lawsuits against people for actually using the GPL-licensed software you ship. The second is that it carefully prevents TiVoization, locking down hardware so that people can’t actually run the software they want.
So, which of those things are they planning for OS X, eh?
I’m also intrigued to see how far they are prepared to go with this. They already annoyed and inconvenienced a lot of people with the Samba and GCC removal. Having wooed so many developers to the Mac in the last decade, are they really prepared to throw away all that goodwill by shipping obsolete tools and making it a pain in the ass to upgrade them?
https://www.learnenough.com/command-line-tutorial
Also, the author does not mention hitting tab for autocomplete (or displaying the remaining options that match what has been typed so far).
[1] https://github.com/anishathalye/dotbot/
These days bash seems to have a lot closer feature parity to zsh, and I'd be curious to read an up-to-date comparison of both shells to determine if either is clearly better than the other.
Back in uni I used to use tcsh interactively, script in [ba]sh, and program in a "real language" like C, Java, etc., but I wasn't doing anything very complicated with any of them. Once I started working and begin using these tools seriously, I simply couldn't learn and retain all of them. Something had to go, and tcsh was it.
#> watch -n 1 dmesg & #> fg -- brought it back
Whether the reader knows that meaning immediately is a rather good proxy for just how long they have been working and/or playing with computers. Long ago, in a world of RS-232 connected display terminals and/or analog telephone modems, one became very familiar with "XON/XOFF flow control".
Substring history search, so you can use just a substring to look for a argument,command. Binded to ctr+r/s by default. ;)
https://github.com/liloman/asyncBash#use
Changing directories: Last n directories, transparent popd/pushd.
https://github.com/liloman/dirStack
Movements: vim-surround for your cli, so you can do ysiw" o whatever... ;)
https://github.com/liloman/bash-surround
Control-n right: So just type the start and control+n to search for the arguments/commands starting with whatever. And the classical up/down to look up for a complete history line:
https://github.com/liloman/dotfiles/blob/master/bash/.inputr...
https://github.com/liloman/dotfiles/blob/master/bash/.inputr...
There're a ton of hidden functionality and customization behind the classical bash instalation. :)
I'm gonna steal some ideas from asyncBash
I don't understand why the default bash/readline doesn't get something related for substring search or way better autocompletions, it's really not that hard definitely (actually quite easy) and even when that's the reason for a lot of people to choose zsh over bash.
LESS=+/"DEFAULT KEY BINDINGS" man readline
assuming it exists on mac.
About suspend, what's the benefit of suspending vim using C-z? Shouldn't you use a terminal multiplexer instead, or even terminal tabs if you don't want to learn how to use tmux or screen (which I find weird if you already spent time to learn how to use vim but alright)?
I only ever suspend a program when I want it to stop, for instance because it slows other programs and I realize I would rather resume it when I'm not in front of my computer. Even in that case, I often just renice the program instead. Stopping a program just because you want to run some bash commands looks like an anti-pattern to me, but maybe there are better motives I'm not aware of.
For me, as far as shells go it's usually enough to know the basics and be able to look stuff up when debugging other people's shell scripts.
On my personal machines, I often find places where I want to either clean up my desktop experience or automate some workflow, where I break some shell out. Most of the time, the overhead to drop into an actual programming language is quite heavy, and even though I try to comment my scripts and write them in a maintainable fashion, I only end up editing them maybe a few times a year.
I feel like discouraging shell scripts is part of what's driving us to seek increasingly heavyweight solutions like systemd in our architecture. Sometimes a lightweight environment where we trust the programmer is needed.
Brevity and simplicity are really the keys when it comes to shell scripts. I really don't have a problem with them if they're short and don't try to be too clever. Whenever I've let my shell scripts get long or complicated, I've always regretted it, and always wound up rewriting them in a "real" programming language anyway, and then realizing that I would have been better off rewriting them much earlier, as soon as they'd outgrown the short, simple stage.
There's no shortage of relatively light-weight "real" programming languages like Perl, Python, Ruby, Lua, and Go -- for even moderately sophisticated tasks, all of them would be better choices than shell scripting.
[1] - http://smarden.org/runit/
While there is much useful in this post, I always find comments like this one odd. bash was released back in 1989, zsh was released one year later, in 1990. One year difference in age almost thirty years ago means that you can't really call zsh a newcomer. Maybe he's talking about adoption, though.
Some people just lack the perspective.
If you want to delete everything and don't want to keep typing yes just do `yes | rm bla`.
bindkey -v bindkey -M viins 'jk' vi-cmd-mode
Then you can edit your command line the same way you would edit a line in vim.