
CLI: Improved - Bootvis
https://remysharp.com/2018/08/23/cli-improved
======
nextos
GNU Parallel is the first thing I usually install on top of a standard Unix
userland. It's almost a superset of xargs, with many interesting features. It
depends on perl, though.

htop is also pretty much a great replacement for top. And ripgrep a great
replacement for the find | xargs grep pattern.

Aside from that, I'm pretty content with the Unix userland. It's remarkable
how well tools have aged, thanks to being composable: doing one thing and
communicating via plain text.

I'm less happy with the modern CLI-ncurses userland. Tools like e.g. mutt are
little silos and don't compose that well. I've migrated to emacs, where the
userland is much more composable.

~~~
AnIdiotOnTheNet
I don't feel the plain text portion has aged well at all in regards to
composability. It leads to a lot of headache as the complexity of the task
grows because of the in-band signaling and lack of universal format. I think
it is high time the standard unix tools were replaced with modern equivalents
that had a consistent naming scheme and pipelined typed object data instead of
plain text.

~~~
skissane
If Unix pipes gained support for exchanging some kind of out-of-band
signalling messages, then CLI apps could tag their output as being in a
particular format, or even the two ends of a pipe could negotiate about what
format to use. If sending/receiving out-of-band messages was by some new API,
then it could be done in a backwards compatible way. (e.g. if other end starts
reading/writing/selecting/polling/etc without trying to send/receive a control
message first, then the send/receive control message API returns some error
code "other end doesn't support control messages")

I have suggested this before:
[https://news.ycombinator.com/item?id=14675847](https://news.ycombinator.com/item?id=14675847)

(But I don't really care enough about the idea to try to implement it... it
would need kernel changes plus enhancements to the user space tools to use
it... but, hypothetically, if PTYs got this support as well as pipes, your CLI
tool could mark its output as 'text/html', and then your terminal could embed
a web browser right in the middle of your terminal window to display it.)

~~~
vram22
>your CLI tool could mark its output as 'text/html', and then your terminal
could embed a web browser right in the middle of your terminal window to
display it.

Ha ha, I had dreamed up something like this in one of my wilder imaginings, a
while ago: A command-line shell at which you can type pipelines, involving
some regular CLI commands, but also GUI commands as components, and when the
pipeline is run, those GUIs will pop up in the middle of the pipeline, allow
you to interact with them, and then any data output from them will go to the
next component in the pipeline :) Don't actually know if the idea makes sense
or would be useful.

~~~
jolmg
Sure it makes sense. Just put `gvim /dev/stdin` in the pipeline you desire and
write to stdout when you're done. You can add to your configuration to remap
`ZZ` (which usually saves the file and exits) to `:wq! /dev/stdout` when
stdout is not a terminal. I'm going to do that when I get back to my computer.

~~~
vram22
That sounds like a cool use of the concept. Will try it out. Thanks.

------
barbegal
I feel like these tools very much go against the Unix philosophy of "Write
programs that do one thing and do it well". They try to do the pretty user
interface and the underlying operation in a single tool.

I prefer PowerShell in this respect where the output of each command is not
text streams (as in the Unix world) but objects which can be operated on in a
more object oriented way. You spend less time thinking about text parsing and
more time thinking about the data you're working with.

I think the command line is great as a way of manipulating data streams but it
is incredibly lacking as a user interface. There is very little consistency of
the interface between commands and new commands and options aren't easily
discoverable.

~~~
burntsushi
ripgrep definitely goes against the Unix philosophy. This is intentional. The
Unix philosophy is a means to an end, and not an end unto itself. The key way
that ripgrep violates the Unix philosophy is that it couples the filtering of
what to search with the act of searching. You hit the nail on the head with
styling, because the output of ripgrep is itself the thing that prevents
composability.

However, from my own observations (and my own use), folks seem to appreciate
having some amount of coupling and integration here. I've often seen folks
claim that a legitimate use case (for them) for ripgrep is to "replace crazy
'find ./ ... | xargs' concoctions." The degree to which the aforementioned is
"crazy" or not varies based on the individual, but there's a not insubstantial
number of people who appreciate the succinctness that coupling brings.

As the maintainer, the coupling is annoying, because it means ripgrep needs to
implement more stuff. For example, ripgrep provides a `--sort-files` option,
which is something that standard grep doesn't need because you can fairly easy
compose its output with 'sort'. You could do the same with ripgrep (ripgrep
supports the standard composable grep output format), but then you lose the
"pretty styling" that users appreciate. So you have no choice.

In terms of giving more structure to output, I am mostly unconvinced by your
argument, but I've been happily using text streams as my user interface for a
very long time, and I like its balance.

With that said, the next release of ripgrep will come with a --json flag,
which enables structured output. :-)

~~~
bradknowles
Which I can then pipe to "gron" so that I can make something sensible and
greppable out of that json output, right?

;)

~~~
dflock
Well, you could pipe it to "jq" \-
[https://stedolan.github.io/jq/](https://stedolan.github.io/jq/)

~~~
needlepont
Which is a pretty abominable tool TBH. It breaks on just about every little
edge and isn't very useful unless you like to see pretty colors and nested
outputs + learn it's terrible output formatting spec. When using json I still
use jansson for quick one offs.

------
dhamidi
Is anybody here aware of any TUI/CLI tools that bring UX patterns/ideas from
other programs to the terminal?

Examples:

\- bash/zsh/fish bring suggestions/autocompletion

\- fzf brings fuzzily-matching selections to the terminal,

\- [https://github.com/ericfreese/rat](https://github.com/ericfreese/rat)
brings the idea of "widgets" or "layouts",

\- [https://github.com/mrnugget/fzz](https://github.com/mrnugget/fzz) brings
"preview as you type"

I'm looking for more patterns like that, mainly to explore how to make them
work in the terminal and see whether that actually has an impact on everyday
actions people perform in the terminal many times per day.

The goal is not to save time, but to reduce mental friction.

~~~
sweetdreamerit
This is interesting. And I'm wondering if those patterns could be somehow
useful also to design the interaction of chatbots.

------
thibran
rg > all other grep tools

[https://github.com/BurntSushi/ripgrep](https://github.com/BurntSushi/ripgrep)

~~~
icc97
Also you can get ripgrep and fzf plugins for vim which are fantastic.

I think VSCode uses ripgrep too.

~~~
chillee
VSCode uses ripgrep internally to do the cross project searching.

------
hs86
With tools like these or ripgrep it is useful to know whether the authors try
to replace the old tool or not. This is usually stated somewhere in their
readme or faq.

If they choose to approach some problems with different semantics, I would not
recommend to alias the new tool over the old one. Just treat it as a like a
separate tool and in most cases their new names are as comfortable to type as
the 'legacy' tool's. The one exception that comes to my mind is 'exa' vs.
'ls'. Typing 'ls' is a single action for both hands while 'exa' has to be
typed with the left hand alone (on QWERTY/Z layouts).

~~~
thibran
If you like exa, maybe you like my modifications about hiding the time output
optionally when using '\--long', too.

[https://github.com/thibran/exa/tree/time_style_hide](https://github.com/thibran/exa/tree/time_style_hide)

Example output of 'exa -l --time-style=hide':

    
    
        drwxr-xr-x - foo Desktop
        drwxr-xr-x - foo Documents
        drwxr-xr-x - foo Downloads
        drwxr-xr-x - foo Music
        drwxr-xr-x - foo Pictures
        drwxr-xr-x - foo src
        drwxr-xr-x - foo Videos

~~~
h1d
For just listing without additional info, I'm good with just the file tree.
With '-l' it can show bunch of stuff.

    
    
      $ l (exa --tree --level 1)
    

[https://i.imgur.com/RxppCIt.png](https://i.imgur.com/RxppCIt.png)

    
    
      $ l2  (exa --tree --level 2)
    

[https://i.imgur.com/Mba79iz.png](https://i.imgur.com/Mba79iz.png)

~~~
torarnv
How did you get the folder/file icons in there?

~~~
h1d
There's exa fork that allows --icons option but you need to patch your font to
display them as they're text. (Search for nerdfont. Some are pre-patched.)

[https://github.com/ogham/exa/pull/368](https://github.com/ogham/exa/pull/368)

~~~
torarnv
Thanks!

------
orf
Is anyone else impressed with the quality (and speed!) of some of the tools
written in Rust? I'm an avid user of fd and bat, the former being ridiculously
fast. Often I find something on github, I'm impressed by the quality of the
documentation, features, UI etc, then lo and behold it's written in Rust.

Another one potentially for this list is tokei[1] I was trying to count the
code in our repos at work and used the venerable 'cloc' utility. It took over
5 minutes. Looking around I found tokei, written in rust. Same-ish results
(more accurate actually) took _10 seconds_.

1\.
[https://github.com/Aaronepower/tokei](https://github.com/Aaronepower/tokei)

~~~
steveklabnik
IIRC, loc (in rust) might be even faster than tokei at times? I always forget,
and I’m sure I saw an old benchmark...

We have a whole working group this year focused on making the experience of
writing CLIs awesome, so hopefully we’ll see even more great tools in the
future!

~~~
vram22
>We have a whole working group this year focused on making the experience of
writing CLIs awesome

Can you explain what you mean by this? Something like the people are going to
focus on language and library features that help with writing CLIs? Or
something else?

Asking because CLIs are one of my interests.

~~~
epage
We've tried to dig into various problematic areas of writing CLIs in Rust [0],
worked to create or improve libraries [1], and are working on writing a "book"
for Rust-based CLIs [2].

You can reach out to us on gitter [3].

[0]: [https://github.com/rust-lang-nursery/cli-
wg/issues](https://github.com/rust-lang-nursery/cli-wg/issues)

[1]: [https://github.com/rust-clique/](https://github.com/rust-clique/) and
[https://github.com/assert-rs/](https://github.com/assert-rs/)

[2]: [https://rust-lang-nursery.github.io/cli-wg/index.html](https://rust-
lang-nursery.github.io/cli-wg/index.html)

[3]: [https://gitter.im/rust-lang/WG-CLI](https://gitter.im/rust-lang/WG-CLI)

The areas we're trying to finish up for Rust 2018 Edition:

\- Get clap (arg parsing) to 3.0 [4]

\- Get assert_cmd [5] / assert_fs [6] to 1.0

\- Finish work on man-page generation [7]

\- Make it easier to package binaries [8] and document the CI for it [9]

[4]: [https://github.com/rust-lang-nursery/cli-
wg/issues/41](https://github.com/rust-lang-nursery/cli-wg/issues/41)

[5]: [https://github.com/assert-rs/assert_cmd/](https://github.com/assert-
rs/assert_cmd/)

[6]: [https://github.com/assert-rs/assert_fs](https://github.com/assert-
rs/assert_fs)

[7]: [https://github.com/rust-lang-nursery/cli-
wg/issues/38](https://github.com/rust-lang-nursery/cli-wg/issues/38)

[8]: [https://github.com/crate-ci/cargo-tarball](https://github.com/crate-
ci/cargo-tarball)

[9]: [https://github.com/crate-ci/crate-
ci.github.io](https://github.com/crate-ci/crate-ci.github.io)

~~~
vram22
Thanks for the detailed answer. Will check out some of those links.

------
fredsted
I like these kinds of articles, but it's rare I need that many CLI tools on my
MacBook.

I interact with hundreds of servers on a day-to-day basis, and I don't want to
go around installing random tools on my servers. But I guess it's an idea for
some tools to add to my Ansible server provisioning script :-)

~~~
h1d
I always update my Ansible script when I find something worthwhile.

Besides, why not just make a $HOME/bin/ and throw your new stuff in there?

~~~
abluecloud
that's what I do, and a git repo for my dot files

------
patja
"I'm not sure many web developers can get away without visiting the command
line."

IIS has significant market share. I'll bet most web developers who deploy on
it get away without having to use the command line interface very often if at
all.

[https://news.netcraft.com/archives/2018/08/24/august-2018-we...](https://news.netcraft.com/archives/2018/08/24/august-2018-web-
server-survey.html)

~~~
FactolSarin
I have co-workers who work on a big intranet web application that runs on IIS,
and they never touch it.

They recently finally switched to git for source control, and they want to do
everything via GUI. I've tried to show them how some things are just
easier/better from the command line, but if something isn't doable via GUI,
they won't do it. One of them keeps committing line endings differently than
everyone else, and he literally won't run _git config --global core.autocrlf
true_ because... I dunno why. He just doesn't want to, because it's the
command line.

~~~
IshKebab
Git has such a terrible command line that most things are easier in (good)
GUIs than on the command line.

The only exceptions I can think of are interactive rebase which has a weirdly
good command line interface and is really confusing in every GUI I've tried;
and continuing/aborting rebase and cherry picks when there is a conflict. And
that's only because most GUIs don't bother to actually implement that properly
and mislead you into thinking that you should make a new commit.

~~~
jolmg
I find git to be one of the best CLI programs I've ever used.

There are a few things I don't like, like how `git blame` requires me to put
my terminal in fullscreen to see the output properly. I wish there was an
option to make the output group changes of a commit together. It could put the
commit details on a line before and add a single character prefix to all lines
to differentiate between file lines and commit lines, just like how ag/ack/rg
improve grep's output format for human viewing.

There's also a long-standing bug in `git log --graph` that causes the lines of
the graph to sometimes move back to the previous line at the end of a commit
description.

I love the -p/\--patch option that's available in many subcommands. It's
really quick to work with.

What specific things do you not like about git's CLI?

~~~
unscaled
The CLI for Git is one of the most confusing CLIs I've ever seen. I can
describe all the warts here, but other did that better than me:
[http://stevelosh.com/blog/2013/04/git-
koans/](http://stevelosh.com/blog/2013/04/git-koans/)

Besides the inconsistencies, there are many gotchas which keep tripping
developers. For instance, git pull always tries to merge in the remote branch,
but you almost never want that. You can do: git pull --ff-only, but most
developers I know don't know that and end up with a mess they have to spend
time cleaning up.

The main issue is that git commands mix up so many concepts and the defaults
are almost always useless. For instance, git add manages tracking files and
staging commits. git rebase both deals with rebasing and history clean-up
(rebase -i).

A better CLI would just have consistent clear verbs that expose the git model
properly instead of mixing up concepts:

    
    
      git track    <file>
      git untrack  <file>
      git stage    <file>
      git unstage  <file>
      git commit
    

And the syntax for creating/deleting/removing branches, remotes and tags would
be unified.

~~~
lloeki
Fire and forget as part of team setup guidelines:

    
    
        git config --global pull.ff only

------
Mizza
Another tool I use religiously: `autojump` (aliased to `j`) rather than `cd`.
It learns where you go and lets you fuzzy-jump there.

[https://github.com/wting/autojump](https://github.com/wting/autojump)

I also use `loop`, my own Rust-based replacement to bash's native loops:

[https://github.com/Miserlou/Loop](https://github.com/Miserlou/Loop)

~~~
euank
I've found fasd ([https://github.com/clvv/fasd](https://github.com/clvv/fasd))
to be the most featureful of the directory jumping tools, and it's much faster
than autojump as well.

I'd be remiss not to mention pazi however, which is the tool I wrote to
replace fasd in my own workflow:
[https://github.com/euank/pazi](https://github.com/euank/pazi)

It's similar to autojump, but _much_ faster:
[https://github.com/euank/pazi/blob/master/docs/Benchmarks.md...](https://github.com/euank/pazi/blob/master/docs/Benchmarks.md#benchmarks)

Oh, and it's written in rust :)

~~~
onemanstartup
[https://github.com/gsamokovarov/jump](https://github.com/gsamokovarov/jump)
You can benchmark this tool to be fastest

------
bostonvaulter2
I'm surprised that no-one has mentioned mtr yet. I like it much better than
ping/traceroute and I don't really see anything in prettyping that makes me
willing to switch.

~~~
pmccarren
I use mtr every day, and I haven't seen anything that beats it.

You can even press 'd' twice, and you'll get something similar to prettyping,
but you get it for each hop along the path.

------
flother
At the end of the article csvkit is given an honourable mention. I’m a big fan
and I’ve used it a lot in the past, but these days I’d say that xsv > csvkit
for working with CSV files on the command-line.

[https://github.com/BurntSushi/xsv](https://github.com/BurntSushi/xsv)

~~~
mooss
I don't know how it compares to xsv, but you might be interested in Miller/mlr
([http://johnkerl.org/miller/doc/index.html](http://johnkerl.org/miller/doc/index.html)),
I've used it because csvkit was too slow for what I needed to do and was
pleasantly surprised by its features.

------
andrepd
Re: bat > cat

Cat is just a tool to dump files to stdout and maybe concatenate them. If you
want paging, syntax highlighting, etc, you probably want a tool to replace
`less`, not `cat`.

~~~
hultner
view is also perfectly good, it's vim's pager.

~~~
yaakushi
Isn't "view" just an alias to invoke vim on read-only mode (i.e. you can still
edit the text, do anything else you can do on vim and then save the contents
to another file instead of the original file)?

~~~
Pete_D
The man page suggests it's equivalent to "vim -R". I usually use that because
"view" seems to ignore my .vimrc for some reason.

------
dguo
I keep a running list in my dotfiles repo[1] of the Unix replacements that I
use. One downside is that I don't know the standard tools as well as I would
like because I almost never use them.

[1]: [https://github.com/dguo/dotfiles#replacements-for-unix-
comma...](https://github.com/dguo/dotfiles#replacements-for-unix-commands)

------
kjullien
I'd really love to know why 99% of the well made, polished and fastest of
these tools are made using Rust if anyone patient enough cares to explain.

Is Rust a particularly good fit for CLI tools like these ? Why so ?

~~~
oblio
Rust is compiled, is fast and it's a modern language. It's also a demanding
language so people who are willing to learn it are more likely to be
craftsmen.

------
lou1306
Noti looks nice, but typically I just do `whatever-long-command && tput bel`.
On Macs, the Terminal dock icon bounces and gets a badge whenever the console
bell rings and the terminal is in the background.

[https://apple.stackexchange.com/questions/47801/is-there-
any...](https://apple.stackexchange.com/questions/47801/is-there-any-way-to-
have-a-badge-appear-on-the-terminal-icon-in-the-dock-when-a)

~~~
dtjohnnymonkey
This is one of my favorite tricks. The nice thing is that it still works if
you’re ssh’ed into a remote host. If I’m feeling nostalgic I’ll do ‘... && say
“files done”’ (which only works locally)

------
braindongle
There's the convenience of these tools, then there's convenience of having a
small number of non-standard tools to carry along with you, however easy that
may be.

For example, for any diff'ing or cat-like need, I find it SUPER handy to just
pipe stdout to vim like so:

$> thing-with-output-that-needs-navigating | vim -

I'm not an Emacs user, but my impression is that over in that world, the shell
integrations are crazy good.

------
androidgirl
The inclusion of Ponysay over cowsay is dubious at best.

Let me be clear: Ponysay has its niche. But with the Ansible stack providing
great out of the box integration with Cowsay, it's clear which is the tool of
choice for modern workflows.

On a serious note, TL:DR is amazing in some cases. The man page for "tar"
compared to the TL:DR is much more unwieldy for 99% of use cases, for example.

I love ripgrep and htop, and I think that a lot of people new to *nix cli's
would love tree as well!

------
stirner
>The talk reviews reasons for UNIX's popularity and shows, using UCB cat as a
primary example, how UNIX has grown fat. cat isn't for printing files with
line numbers, it isn't for compressing multiple blank lines, it's not for
looking at non-printing ASCII characters, it's for concatenating files.

>We are reminded that ls isn't the place for code to break a single column
into multiple ones, and that mailnews shouldn't have its own more processing
or joke encryption code.

------
aumerle
As far as pretty CLI diff tools goes, the prettiest by far is:
[https://sw.kovidgoyal.net/kitty/kittens/diff.html](https://sw.kovidgoyal.net/kitty/kittens/diff.html)

The downside being it requires the kitty terminal as it uses features not
present in other terminals.

------
tambourine_man
Nice list, but I tend to keep my stuff as close to default as possible. The
feeling of not being at home on a new box outweighs the benefits of
customizations, in most of the cases.

I do have a huge .vimrc and some bash niceties, but I found it better for me
to exercise some customization discipline overall.

~~~
BozeWolf
Yes i do exactly the same thing!

------
JepZ
My htop usage has led me to a point where don't remember how to use top (sort,
kill processes, etc.) :D

------
partycoder
\- ranger (and the ranger-cd script) are pretty useful to explore folders in
the terminal.
[https://github.com/ranger/ranger](https://github.com/ranger/ranger)

\- percol and ripgrep as alternatives to grep

\- tig as TUI for git

\- kakoune as alternative to vim

~~~
h1d
I like vifm over ranger. Simple dual pane with vi key binding.

~~~
partycoder
Nice! this way better

------
canhascodez
I'm so relieved that this blog post isn't about a Bash library. It's
definitely a great collection of tools; I'm going to have to add some of these
to my recommendations.

------
gpmcadam
Thanks for sharing. I'm always looking for ways to improve my CLI experience
and there's some gems in here that I've not come across before.

------
thomasfl
Filewatcher does the same as entr. In addition it exports environment
variables. It makes it possible to send the name of the updated file as a
parameter to commands like this:

    
    
      $ filewatcher '**/*.js' 'jshint $FILENAME'
    

[https://github.com/thomasfl/filewatcher](https://github.com/thomasfl/filewatcher)

------
radarsat1
> _The bat command also allows me to search during output (only if the output
> is longer than the screen height) using the / key binding (similarly to less
> searching)._

You can do this with `less -F <file>`. It will show the file on the screen
like `cat` unless it is longer than one screen, then it will go into paging
mode and allow search with `/`.

Side note, how do you make his nice-looking prompt?

~~~
mlevental
you don't need the -F do you? unless I'm missing something you're saying about
less

~~~
another-cuppa
That makes it exit immediately like cat.

~~~
mlevental
oh. but why would you want to? even for a 1 page file i still want to / most
of the time

------
umvi
cat's primary purpose is combining files together. For example:

    
    
        cat mysoftware.tar.gz mysoftware.sig > mysoftware.bin
    

Combines an archive with a digital signature into a single file. Then, on the
other end, you just need to pop off the signature with a tail -1

Or alternatively:

    
    
        cat a.log b.log c.log > monolith.log

~~~
hk__2
Of course, but its primary purpose (combining files) differs from its primary
usage (showing a file’s content).

~~~
joombaga
The primary usage us just a special case of its primary purpose. You're
concatenating the file with nothing.

~~~
h1d
I never concatenated a file using cat.

------
h1d
Anyone know of a good markdown viewer that is formatted instead of showing the
source with colors?

I'm using pandoc to convert it to groff and read it like a formatted man page,
which is ok but not great as it loses some formatting.

    
    
      pandoc -s -f markdown -t man markdown.md | groff -T utf8 -man | less -R

~~~
dhamidi
Actually plain less works quite well when using filters:

    
    
      #!/bin/bash
      # ~/.lessfilter
      case $1 in
        *.md) view-md $1;;
        *.json) jq -C . $1;;
        *) pygmentize $1;;
      esac
    

Where view-md is just a thin wrapper around tty-markdown[1]:

    
    
      #!/usr/bin/env ruby
      
      require 'tty-markdown'
      
      puts TTY::Markdown.parse(ARGF.read, colors: 256)
    
    

[1]: [https://github.com/piotrmurach/tty-
markdown](https://github.com/piotrmurach/tty-markdown)

------
bostonvaulter2
He mentions using ccat previously, I've been using it for a while (aliased as
`cat`) but I've been meaning to switch away from it since it sometimes panics.
`bat` looks very nice, just installed it and played around with it a bit.

------
spatular
atop as replacement for both top and htop. By default it dispays CPU
frequences, disk i/o (read, write bw, average io time), disk io per process,
basic network load. And it wastes no space as htop does.

------
vmchale
I use `sn` instead of `du`. It's closer to `du` than `ncdu`.

[http://github.com/vmchale/tin-summer](http://github.com/vmchale/tin-summer)

------
saagarjha
> There is a weird bug in Mac Sierra that can be overcome by running htop as
> root

I don't think this was a bug; I think the issue was that htop uses needed
something in task_for_pid that required root.

~~~
lloeki
Oh this was definitely a bug already, and a nasty one at that, as it froze the
whole computer in a few minutes while the kernel was racing against itself and
starving for some resource (which didn't happen while being run as root). It
was fixed in macOS 10.13.4 / htop 2.2.0

[https://github.com/hishamhm/htop/commit/b2771218](https://github.com/hishamhm/htop/commit/b2771218)

[https://github.com/hishamhm/htop/issues/682](https://github.com/hishamhm/htop/issues/682)

~~~
saagarjha
Ah, that bug has now been fixed.

------
fangxing
[https://github.com/direnv/direnv](https://github.com/direnv/direnv) very
Important for me, to load envs

------
rane
With ramda-cli, the jq example would be:

    
    
        npm outdated --json | ramda --raw-output 'map (.latest)' to-pairs 'map join "@"'

------
skibz
Aliasing "help" is not a great idea, in my opinion. help gives fantastic usage
instructions for builtin shell commands.

------
benoror
Why not just using vim instead of bat?

~~~
tzury
or view (comes with vim)

------
lousken
fzf is awesome, but i don't combine it with a shortcut, i just feed its output
to xdg-open

    
    
        alias o="fzf --preview 'bat --color=always {}' | xargs -i '{}' xdg-open '{}'"

------
eximius
I'm surprised ripgrep isn't on here.

------
Grue3
atop > htop

[https://www.atoptool.nl/](https://www.atoptool.nl/)

~~~
h1d
I've fallen back to using gotop when all of these alternatives' outputs are
too noisy.

------
caiocaiocaio
climproved

------
another-cuppa
"bat" is not a better version of cat, it's a completely different tool. cat is
short for concatenate. If you want to view a file use less, and if you want
syntax highlighting etc. then use view (comes with vim).

~~~
jolmg
Most tools mentioned are completely different tools from the ones they're
suggested to be better versions of. I understand the comparison is for
specific use-cases. For example, csvkit is far better than trying and failing
to parse CSV with awk, but it's very much useless for any other type of text
format. Same thing with jq (a JSON query tool) vs grep (a general text search
tool). The only ones I can agree with in the general case are htop > top and
ag || ack > grep (though I still prefer grep sometimes).

~~~
burntsushi
If you don't mind me asking, in roughly what cases do you reach for grep
instead of ag || ack? Is it a familiarity thing, or specific features or
something else?

~~~
earenndil
Not the gp, but I generally use ripgrep when I want to find something
manually, and regular grep in a script.

~~~
vram22
Why? Does ripgrep not work as well (or better) than grep in a script? And if
so, why not?

Or is because you deploy your scripts to other machines where ripgrep may not
be present, but grep will?

~~~
jolmg
Scripts tend to be shared, so portability matters. grep alternatives, while
great for interactive use, are generally not worth being an extra dependency
to install.

------
serverlesscloud
Can we use the term text user interface (TUI) and not CLI for stuff talked
about here. I don't like the confusion and I think TUI I'd appropriate, just
because something is launched by command line doesn't make it a CLI. A CLI is
good for pipes, these things are interactive post start.

~~~
ethelward
bat can pipe just like cat, fzf can pipe and be piped, same ack/ag/rg, same
for fd, same for jq.

------
mlevental
bat is cool but is there a way to get not to dump everything into my terminal
and just page just like less? i wonder if there's a `bless` ?

~~~
jayrhynas
You should be able to pass `--paging always`. The default `auto` will only
page if the file contents is bigger than your screen.

~~~
mlevental
this does paging but still leaves the page in my buffer/terminal/whatever.

------
bronlund
I was wondering if any of you use alternatives or hacks for the cd command?

I've been testing out a couple of different ones, like xd, fcd, wcd and
pushd/popd, but I'm not quite sure which I should commit to or if there are
better ways :)

~~~
gpmcadam
Few from my aliases file that may help:

    
    
       7   │ alias ..="cd .."
       8   │ alias ...="cd ../.."
       9   │ alias gcd="cd (git rev-parse --show-toplevel)"
    

The first two should be self explanatory.

The third one will take you to the "git root" of a directory structure, i.e.
the top-level folder where the .git directory is (I find this grounds me for
when I'm doing git commands.)

