Linux Terminal Goods | Hacker News Reader

Linux Terminal Goods

diego-pacheco.blogspot.com

106 pointsdiegopacheco63 comments

Regular vim has tabs and you can bind any key you want to switching them (I use F2/F3). The default is :next and :prev or gt/gT. I’ve been using the feature for years now.

You can also open a list of files in separate tabs with the -p argument. So “vim -p CppFile.*” will open the .h and .cpp in separate tabs for example. You can then Y/p between the two buffers.

It’s so useful that I always “alias vi=vim -p” in my .profile.

Is the '-p' necessary?

I like to open files in windows with e.g. "vim -O file1 file2", and I've noticed that if I accidentally omit the '-o' or '-O', it opens each file in a tab. Or at least, it opens each file in individual pages that you navigate between with ':next' / ':prev'.

The -p gives you a tab for every file opened. If you don't provide it, it still opens them and you get a buffer for each one, but it doesn't open any tabs. If you still get tabs even if you don't provide it, maybe you have a vim plugin that's doing that.

I've just skimmed around it as someone who repeatedly need that kind of book to achieve little things in bash.

I understand bash is the basis of so many things, that its importance is just enormous.

But at the same time, I'm appalled by its syntax, idioms, etc. It's barely readable for the casual reader that I am. I wonder why nobody tries to provide a meaningful alternative. I've seen some (in python for example) but I'm kind of surprised nobody puts more money in such an effort.

For example, the "trim string" function described at the beginning of the book is horrible (although probably very clever). Why not simply provide a built in function ? That would make code so much cleaner...

I ask the question honestly, it's not a rant :-)

Shells are made for people to interact with, not for programming. They happen to also be useful for programming, so many things have been added on over time to support that.

Shell scripting is also the least painful way to call many external programs and glue them together into something useful. Calling external programs from “real” programming languages is far more painful.

If you need a real programming language, as you mentioned, use something designed for that.

Generally if you're trying to do something that feels like a "program" in shell script, rather than loosely gluing existing tools together, the threshold for moving it into Perl or Python should be low. Even things like trying to get the quoting right for lists of files some of which may have spaces in their names is fiddly enough to drive people to writing a "proper" program.

(or was this comment intended for https://news.ycombinator.com/item?id=21013150 )

The moment I have to use arrays in bash, I open up a python interpreter. Syntax makes far more sense than in bash.

I used to drop into python for ad-hoc work as soon as I needed even for/if or any arithmetic. Now that I actually manage to remember how to use for-loops when I need them and I picked up awk,I haven't needed to since.

For a maintainable script pythons great of course.

Its simplicity is an important part of the offering. Bash is perfect when you need predictable executions.

When you use Bash, you benefit from an entire ecosystem that also uses it. That same ecosystem is not motivated to drastically change the shell, and therefore it remains stable and predictable.

Bash typically isn't like Python or JavaScript, where certain features are introduced at a particular version and you have to constantly check for them, or not use them outright, or maintain which binary you have installed at all times. One Bash binary typically contains the same feature set as another binary.

Bash isn't the friendliest thing to work with syntactically, but it's friendlier than the alternatives in maintability and reliability.

Despite all this, on the flip side, there still are a lot of people invested in alternatives, and some have gained plenty of traction. zsh is a great example.

I don't disagree with your points but I think your following comment is a little misleading:

> Bash typically isn't like Python or JavaScript, where certain features are introduced at a particular version and you have to constantly check for them, or not use them outright, or maintain which binary you have installed at all times. One Bash binary typically contains the same feature set as another binary.

While you're right about shell builtins (a lot of which are defined by POSIX anyway), to do anything useful in POSIX shells requires forking out to sed, awk, grep, as well as many other coreutils and CLI tools. Thus you then need to not only confirm whether those tools are also installed but sometimes also which version or even implementation they are (eg GNU extends on POSIX in quite a number of ways from supported features through to how you order and group flags. Sometimes it can be a little jarring jumping from Linux to OSX if you're used to GNU).

That said, I do working in shells. For "getting shit done" very little even comes close to shells in terms of productivity. However shells are generally optimised to the "write many read once" end of development rather than "write once read many".

As an aside, I suspect GP meant to post this comment on https://news.ycombinator.com/item?id=21013150 (Pure Bash Bible - also on the front page) rather than here?

> As an aside

You mention it as an aside, but I think it speaks to your point about external utilities. In that thread (I also think GP intended to comment on that topic), there was confusion to what "Pure" meant. The first sentence is, "The goal of this book is to document commonly-known and lesser-known methods of doing various tasks using only built-in bash features."

That's an oversight on my part, excellent point. Thanks for pointing it out.

I guess it's like anything programming related. Things don't make sense until they make sense.

Bash's syntax is a bit rough at times and I often find myself having to Google things even though I know what I want to do at a conceptual level.

But the real magic isn't just Bash alone. It's combining it with Unix tools to pipe together programs to solve problems.

I guess at the end of the day no one has tried to fix it because they don't see it as a problem. Despite the syntax weirdness at times it's a pretty concise language which meshes well with writing ad-hoc things on the command line.

IMO Bash is often the best tool to use for a ton of different problems. Sometimes it's good for a final result and sometimes it's good to flesh out a prototype because you can hack something together so fast.

The real advantage it has is simply that it’s there, always. It enjoyed a network effect a long time ago and is now so entrenched that challengers have a mountain to climb - entire generations of professionals know how to get stuff done with it and expect it to be there from the start, so any system that goes with an alternative is at an immediate disadvantage. A few OSes are trying to push what are effectively incremental updates (like ksh on OpenBSD), but it’s a daring proposition. I like OpenBSD but still the first thing I do is switch back to bash, because there are so many other things on the todo list that dealing with an unfamiliar shell is both incredibly low priority and the first thing I’m forced to do - a perfect “demotivational” combo.

I fear it would take a massive coordinated switch, systemd-like, where an entire ecosystem moves to an alternative, to actually see any change in this area.

> The real advantage it has is simply that it’s there, always.

Yes, this is a huge deal in a good way. It's also why standalone zero dependency Python scripts are so successful since most systems have Python installed by default.

Although after reading your first sentence, I got excited. I thought you were going to write about how it's always there in the sense that if you're working in the terminal, Bash and friends are always right there at your finger tips. There's no context switch to get something done, which is super empowering for hacking together things to solve a problem. It just feels like the whole terminal environment in general was made to let tinkerers create the best possible system / workflows for them personally.

Strangely no one's pointed this out yet but you appear to have posted this comment in the wrong thread.

This seems to be the post you're replying to.

https://news.ycombinator.com/item?id=21013150

It's not syntax. It's programs. [ Is a program. Bash blew my mind when I found that out. What a clever idea.

I know what you mean though. I always had to look up things every time. Lately I just committed a bunch of it to memory as it's useful enough and I'm pretty fond of it.

Bash is similar to vim. Pretty weird at first glance, but once you get the idea, stuff just makes sense and the limited knowledge you acquire can be used in different contexts. I think bash is magical in the things it allows you to do with minimal effort.

I would highly suggest checking out Powershell. It works great on windows and linux, its object oriented, and it has all sorts of "networked" capabilities built into it to. For example, say you want to get the disk space on your own computer: Get-WmiObject Win32_LogicalDisk

If you want to do that on a remote machine you just add this to the end of the command -ComputerName remotecomputer: Get-WmiObject Win32_LogicalDisk -ComputerName remotecomputer

And then you can just use the returned object to iterate over it: $disk = Get-WmiObject Win32_LogicalDisk -ComputerName remotecomputer -Filter "DeviceID='C:'" | Foreach-Object {$_.Size,$_.FreeSpace}

I spend loads of time in a shell. One day I'll push my full dotfiles publicly, but until then here's a few snippets I've found super handy. I'd advise against using them verbatim but there's a few things in there that took some time to figure out. Beware they can be somewhat buggy / break things though.

Highlights include:

- Bind C-c/C-v to Copy/Paste, bind C-g to sigterm (Note: Breaks docker interactive unless you mount bashrc into /etc/bashrc or similar!)

- Autorun tmux on SSH session

- Syntax/colour highlighting in zsh interactive, I think there's some diff/less/man magic in there too!

- Log all shell activity to .shell_logs (Be _super_ careful with this one, breaking it could prevent you opening an interactive shell

- Useful grep defaults, particularly relevant when using .shell_logs

Bashrc: https://gist.github.com/YoloClin/f4c82a6e693000a2da20e8029a4...

Zshrc: https://gist.github.com/YoloClin/ffd82f441d292ccc5f25c62a80c...

One thing I've lost love for is Powerline9k - Right-aligned data breaks copy/paste functionality, and patching fonts to get UI-arrows is fiddly for little functional value. If I ever need to fiddle with that stuff again, I'll configure a regular theme to do similar and go without the UI-arrow breaks.

I was considering hiding history-relevant log data (such as current system time) to behind a carriage return, something like PS1="$(date)\r$PS1".

I'm interested in hearing others' cool, non-standard hacks!

Inspired by a colleague, I wrote this (for bash):

https://gist.github.com/archi/2a2331401842c0548fa8de0f69796f...

> up 4

go up 4 folders (=> "cd .." 4 times).

> up

goes up one folder, and you can repeat pressing ENTER to go up one more. Press anything else to drop back to the shell.

Could probably be "better" (e.g. no subshells), but works well for me.

Thats cool! I'm not sure where it comes from, but I get similar behavior in zsh with 'cd ....' - similar doesn't happen in bash though.

I mapped 'cd' to 'c' in my bashrc, but while doing it I also mapped 'c' to execute 'ls' as the latter was basically muscle memory whenever I was using cd. The .bashrc function looks like this:

c() { builtin cd "$@" && ls; }

Hey guys, I have the same thing, but I called the command ".." (no it doesn't conflict with the directory). ".." by itself is the same as ".. 3"

    .. () {
      local arg=${1:-1};
      while [ $arg -gt 0 ]; do
        builtin cd .. &> /dev/null;
        arg=$(($arg - 1));
      done;
    }

Mine is similar, but only does one cd command - to allow better use of `cd -`

    up() {
        local ups="."
        for((i=0;i<${1:-1};i++)); do
            ups="${ups}/.."
        done
        builtin cd "$ups"
    }

Ooo, good idea!

"cd -" is equal to "cd $OLDPWD", so that still works with my function ;)

Though yours looks much nicer ^^"

I've written aliases like cd2='cd ../..'. similarly cd3='cd ../../..' . Similarly cd4 and cd5. next time I'll think of this!

I agree with powerlevel9k. i still have marginal enjoyment from the fiddly things thought and i've switched to powerlevel10k [1]. Its noticeably faster and the default settings are minimalist enough for me. does not fix the fact that you need to install fonts which I can't get working on some terminals (urxvt).

[1] https://github.com/romkatv/powerlevel10k

I had issues with urxvt and ended up moving to Kitty (https://github.com/kovidgoyal/kitty). I'm not impressed with its' autoupdate feature, but it can be disabled. Apart from that a few visual bugs which are probably to do with nvidia the terminal is great. The best feature? Emojis render flawlessly.

I had a proof of concept, but hackernews doesn't support emojis :'(

You can use powerlevel10k with the default system font. It works fine with urxvt without any twiddling.

What saved my ass more times than I can count is that I make sure that whenever I'm on a production machine my prompt has obnoxious color that makes me want to close that window as soon as possible.

Production root is made even more visually offensive.

Maybe I'm completely missing the point of `bat` but I usually just use `view` (vim/neovim in readonly mode) if I want to read files with syntax highlighting, GitGutter, line numbers, etc.

Bat works the same way as ls when it's being piped. But it has better default features than cat, the syntax, numbers and the pager. if the file doesn't fit the screen, it becomes paged, so you don't have to do the whole: `cat file.txt` (too big), `view file.txt`

Not sure if view lets you do this but bat will switch off highlighting if you are piping output `bat file.txt | grep ...`. This makes it easy to make an alias cat=bat and have everything work. Also you can make bat display output with `less` and then line numbers can be toggled, not sure about gitgutter.

(author of bat here)

Exactly. Drop-in compatibility with 'cat' is one of the goals of bat (see https://github.com/sharkdp/bat#project-goals-and-alternative... and a list of alternatives here: https://github.com/sharkdp/bat/blob/master/doc/alternatives....).

Another thing that I use frequently is previewing a whole set of files in a single (pager) output. Something like

    bat src/*.cpp

This also allows you to easily search across a whole set of open files.

Awesome work. I've been a happy user of bat for a few months now, I've almost totally trained my brain away from typing cat.

It's a similar idea to that, but it's more lightweight and much more of a "drop-in replacement" for both cat and less. For instance, when using it as a replacement for "less", it will use terminal colors correctly (i.e. "ls --color | bat" works like you'd want), it will have the same keybindings as less (i.e. b/f for page back/forward, / for search, q for quit, ...), it wont have a cursor, etc. Essentially "less and cat but way better".

Vim can certainly do all these things (or mostly, I don't know about the terminal colors), but for viewing read-only text streams, it's a bit more domain-specific and convenient. It's also blazing fast to open, which vim isn't always.

Part 2 https://news.ycombinator.com/item?id=21119949

Other stuff with asteroids:

* RipGrep: Replace Grep and it is blazing fast

* exa: Replace ls with many more options

Diego I think you're using the word asteroids where you mean the word steroids.

Would be cool though, if somebody would use vim on asteroids.

We still don't know much about asteroids, so we can't sure nobody does

Yeah, but on Mars they use Emacs, so then it's just The Expanse all over again.

Looks like a pun.

"On asteroids" is definitely my new favorite phrase.

i really wish spacemacs didn't have that pretty lame loading screen, as a spacevim devotee i found alot of things that spacemacs does that specifically address some issues i have with spacevim.

i know the correct path forward here is, of course, diving into the guts of spacevim and tinkering until it works for me, but i will post one quirk as it will probably be some time before i will be able to write my own comprehensive plugin:

the hugofy/markdown plugins seem to all do this awful thing in which they render the markdown on the fly. it's kinda neat for basic text formatting, but my god it is an utter nightmare if you have any sort of URL's or images, because the second you key in that second bracket, it suddenly dissapears and you're left having to basically guess your way through the process of typing the url and closing out the shortcode.

if someone knows of a markdown editor that plays nice, i'd love to see it. hope im not overlooking something painfully obvious here

anyways, i picked a hell of a time to dive into the commandline, a year ago i came across scoop/chocolatey and quickly discovered WSL, and thanks to a phenomenal amount of work by some great folks (even you, Person Reading This), my desktop is not much more than the lobby i pass through before going to where the magic happens: https://imgur.com/a/iCpWZAC

What about the loading screen do you dislike? I believe you can change the default after it loads up(and you generally want to be using a daemon in the background with Emacs so it’s a first time run thing mainly anyway)

Just one link: https://terminalsare.sexy

I prefer my terminals dumb and without much color, as the UNIX gods intended them to be.

This being said, I'm in love with `fzf`, my workflow improved markedly after scripting (on mac)

`ggvi() { git grep "$@" | fzf | sed \"s/:/ +/\" | cut -d \":\" -f 1 | gxargs -r -o vim }`

You can also combine it with ripgrep. Much faster than git grep.

I actually time-tested git grep vs ripgrep, and I'm not seeing meaningful differences on my repos. ripgrep smokes regular grep but for some reason git grep is just as fast as ripgrep

git grep is parallel, too.

Because benchmarking these tools is difficult to do correctly, and is heavily workflow dependent. If your search space is small, them it doesn't really matter what tool you use for example, they are all probably going to be pretty quick.

I wrote more about this here: https://lobste.rs/s/0kaozs/don_t_underestimate_grep_based_co...

have to agree that colours often disctract more than are of use. they stop you critically reading imo. but i guess that's also a matter of taste or something like that.

This post is relevant: https://news.ycombinator.com/item?id=17874718

fzf + bat seems pretty nice!

export FZF_DEFAULT_OPTS="--ansi --preview-window 'right:60%' --preview 'bat --color=always --style=header,grid --line-range :300 {}'"

some vim enthousiast here scalded me for sending him spacevim linkand told me to use neovim. i don't use vim so i wouldn't know, and vim people seem easily offended :D. anyhow, just thought i'd not his input.

“Hey you like Jehova, right? I’ve been told this Jesus guy is pretty cool, I wouldn’t know myself to be honest but maybe you’d like him?”

Spacevim actually has some original features (kind of ripped off from emacs) that I really like, and can't find a way to get without using Spacevim. There's nothing wrong with using it, but most vim users like to start from scratch and build their own experience to meet their specific needs. Starting with something like Spacevim is 100% ok if you've never used vim before, but most people end up moving onto the more 'custom' experience eventually anyway.

I immediately thought "yea I'm gonna keep using neovim" when I read about spacevim.

Why are dark themes considered cool? Am I missing something?

Easier on the eyes, at least for me.

this is super awesome! love it, thanks for sharing spacevim is exactly what I have been looking for

Reply on news.ycombinator.com