* tree - print directory structure
* bat - cat, but actually designed for reading files. Syntax highlighting, line numbers, automatic paging.
* rg - better grep
* direnv - local environment variables
jot -- print sequential or random data
rs -- reshape a data array
vis -- display non-printable characters in a visual format
apply -- apply a command to a set of arguments
mc -- multicolumn print
tw -- file tree walk
align -- align text columns
crop -- crop lines to a width
dabl -- delete adjacent blank lines
dtb -- delete trailing blanks
emboxxen / deboxxen -- convert to/from box drawing characters
eol -- convert line endings
field -- simple line field extraction
freeze / thaw -- cross-shell synchronization
mergl -- merge lines into previous lines' blanks
pad -- pad lines to a width
put / take -- cross-shell pipe
uni -- unicode character properties and searchAnd seq in Linux is like jot for sequential data, at least.
And from my blog: An Unix seq-like utility in Python: https://jugad2.blogspot.com/2017/01/an-unix-seq-like-utility...
I've found I'm using the `put`/`take` pair, for splitting a pipeline across shells, more again in the WFH era where I often have multiple ssh sessions into a machine, when I would probably have used the clipboard in a GUI session. Also useful for things like seeing stderr from different parts of a pipeline in different windows. `put` is just `cat >>$(mkpipe "$1")` and `take` is `cat $(mkpipe "$1")` where `mkpipe` is
fifo="${TMPDIR:-/tmp}/fifo-$(id -u)-$1}"
test -p "$fifo" || mkfifo "$fifo"
echo "$fifo"Not all Unix tools are simple. E.g. make. But I know what you mean - the Unix philosophy.
https://en.m.wikipedia.org/wiki/Unix_philosophy
The TAOUP book by Eric Raymond (The Art Of Unix Programming) has a lot about that.
https://en.m.wikipedia.org/wiki/The_Art_of_Unix_Programming
And my IBM developerWorks tutorial / case study on Developing a Linux command-line utility (in C) may be of interest to people who want to write their own Unix tools that play well with others.
https://jugad2.blogspot.com/2014/09/my-ibm-developerworks-ar...
I agree, tree is great. It can be somehow replicated by using "find .", if you are in a hurry.
> bat
If you need that functionality, why don't you open the file with vim, for example?
> rg - better grep
Grep is pretty nifty, I don't see how could it be improved. What is the main advantage of of rg over grep?
> direnv - local environment variables
I read the manpage for direnv and I was really scared. What is it for? I never used an .envr. If I need to see my environment I can simply use "env". What is it missing?
The main advantage of rg is how much faster it is than grep. It’s WAY faster.
I don’t use direnv but I have colleagues who do. I think the idea is that it can set environment variables/run arbitrary commands when you cd into a certain directory (such as activating a Python virtual env, for instance).
I figure you can also use it in conjunction with `module load` to automatically load the right module when you enter a project's directory. Modules are used in many computing clusters to manage environments.
Also direnv will never execute an .envrc without permission, you need to run `direnv allow` whenever there is a new or newly modified .envrc.
function lenv {
path=$PWD
while [[ ! -f "$path/.env" && "$path" != '/' ]]; do
path=$(dirname "$path")
done
if [ -f "$path/.env" ]; then
source "$path/.env"
fi
}It lacks the security but it works recursively and allows more than just environment variables. A common script I have is to automatically build for instance:
here=$(dirname ${BASH_SOURCE[0]})
function autobuild {
(
mkdir -p build
cd $here/build
../configure
while true; do
make && make check
inotifywait -qr -e close_write,delete $here/src $here/test $here/Makefile.am
done
)
}
If there is no .envrc in the directory it will look for one in the parent directory, but it won't activate more than one.
Also one thing it does that your hand-rolled version does not is that it remembers what the environment variables were before and restores them to that state when you exit the directory.
My above example wasn't running the command, just defining it to be run manually. The .env becomes a dumping ground for all sorts of project specific stuff. The docs say direnv doesn't support this.
> Also one thing it does that your hand-rolled version does not is that it remembers what the environment variables were before and restores them to that state when you exit the directory.
I've thought of adding this, but apart from a couple of things I reset manually I haven't really found the need.
You're right, you can't define aliases/functions using direnv. That's a shame, that does seem useful.
(Also, yeah, let's ignore that Rust in the standard libraries is still a problem.)
Why is bat better than less?
I admit to catting files for reading as much as the next guy, but I almost always have the tiniest regret that I didn’t feed it into less and kept my terminal cleaner.
As for RG and AG. other than being faster, how are they better? I thought they were api complainant drop-in replacements so it’s not like they fill in a missing role.
To grep? Not that I know, I don't think either respects POSIX grep to say nothing of GNU grep. Though the trivial usage is identical, and many basic options carry over (e.g. -C and friends).
> other than being faster, how are they better?
Way better defaults for one. `rg` defaults to being recursive, ignoring binary files, respecting various types of ignore files, not being limited to BREs, coloring, …
They also have useful convenience features like "file categories" (e.g. `-t` will expand to a bunch of predefined include glob patterns so you don't have to input them by hand, which can be tedious), or parallelism (recursive ripgrep will parallelise searches across files, with grep you have to remember to combine `find`, `xargs -P` and `grep` for that to happen).
Could you please let me know how you came to that understanding? Because I'd really like to fix it. ripgrep was never intended to be POSIX compatible. It would have been a straight-jacket over its functionality. See: https://github.com/BurntSushi/ripgrep/blob/master/FAQ.md#pos...
> As for RG and AG. other than being faster, how are they better?
For ripgrep at least, a lot of it comes down to speed, better output formatting by default and suppressing results you probably don't want by default (but that can be turned off quite easily).
But there are other features, like better Unicode support, built-in support for searching compressed files, support for file types and a few other things. The README includes a bit more. ;-)
I have actually read a few of your (great) articles about ripgrep. I hope I didn’t come off as dismissive of your impressive work - though rereading my comment I should perhaps have chosen my wordS a bit more thoughtfully.
I did know that RG would skip more files than normal grep, so I guess I knew it’s not a safe replacement for all shell scripts.
But other than that, I’ve never thought of AG or RG as tools that brings something new to the table. I’ve always thought of them as a drop ins, with slightly new defaults and much faster speed. And the discussion related to TFA is tools that are missing, not tools that are better.
Maybe it’s a mix of the name and countess blog posts telling readers to use RG instead of GREP, that lead me to consider RG as a better grep and not a different tool.
`less` not good enough?
Never going to happen because it's written in rust. ag (https://github.com/ggreer/the_silver_searcher) on the other hand is written in C.
(I have some patches to improve things but I have not been able to submit them to LLVM yet, and with those patches I did manage to get a working x32 build of rg on my system. I hope to be able to do so in the future.)
https://doc.rust-lang.org/nightly/rustc/platform-support.htm...
AFAIK, rust is still marked as "guaranteed to build" on these platforms, but assume only Linux. BSDs, not so much.
If Rust being added to the Linux kernel[1] isn't far-fetched, I don't think adding a utility in Rust is crazy either.
[1] - https://lore.kernel.org/lkml/CAKwvOdmuYc8rW_H4aQG4DsJzho=F+d...
Isn't it the case that LLVM doesn't support all architectures that Linux does?
https://github.com/fishinabarrel/linux-kernel-module-rust/is... is a chart of Linux architectures and whether Rust and LLVM support them.