Live data from Hacker News

Moreutils – Unix tools that nobody thought to write (2012)

joeyh.name

211–220 of 225 posts

Re: Moreutils – Unix tools that nobody thought to write (2012)

#211

Earlier quoted context omitted.

> tree 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 i…

direnv is super useful if you're working in Python and have multiple projects: you can add an .envrc file that activates the right virtualenv whenever you enter a directory. It's one less thing to worry about. 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. Al…

I've got a hand rolled direnv that's quite simple:

  function lenv {
    path=$PWD
    while [[ ! -f "$path/.env" && "$path" != '/' ]]; do
      path=$(dirname "$path")
    done
    if [ -f "$path/.env" ]; then
      source "$path/.env"
    fi
  }
function cd { builtin cd "${@}"; lenv; }

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
    )
  }
I've tried generalizing the latter but between different targets, different build systems, different projects structures etc, copy and pasting something like this per project is the least worst option.

Re: Moreutils – Unix tools that nobody thought to write (2012)

#212

I wish there was a short and simple command for “list all files of a directory and no subdirectories“. ls doesn’t seem to have a switch for that kind of functionality. It’s discussed on stack-overflow. [0] Someone even wrote a nodejs tool for this functionality [1], but I would rather have something written in a compiled language. [0]: https://stackoverflow.com/questions/10574794/how-to-list-onl... [1]: https://githu…

> Someone even wrote a nodejs tool for this functionality

Coming from a more low level background but doing front end development from time to time, I am always amazed by the sheer amount of seemingly useless javascript reimplementations of what would be bash one liners.

For your question, how about "find -type f - maxdepth 1" ?

You can put that in an alias or script in your path

Re: Moreutils – Unix tools that nobody thought to write (2012)

#213
post #123

ts looks like it's a subset of https://github.com/ThomasHabets/ind sponge can be replaced with dd Other than that, yeah nice ideas. And very much in the unix spirit of one tool to do one thing.

sponge buffers the whole input before writing the output. Its utility would be in reading from a file, working on it with other tools, and writing the result back to the original file, all in one line.

Seems like the example command should be easily doable with just `sed -i`, though.

sed -i 's/root/toor/;/joey/d' /etc/passwd

But I get your point.

Re: Moreutils – Unix tools that nobody thought to write (2012)

#214

Earlier quoted context omitted.

Good list of things you can install to better your CLI experience, but I am not sure if I agree that they fill out missing features. 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 co…

> I thought they were api complainant drop-in replacements so it’s not like they fill in a missing role. 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 bei…

Hi thanks setting me straight.

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.

Re: Moreutils – Unix tools that nobody thought to write (2012)

#215
post #31

There's a few programs I wish were standard on all Unix systems by now: * 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

One of the reasons is Rust, but another reason is that the standard shied away from adding anything with frills because UNIX-likes run on all kinds of systems, many which don’t have space for this. There is a reason why something as seemingly ubiquitous as bash or vim are not available everywhere (but sh and vi are). The base set of utilities is really “do more with less” and the ability to keep to this philosophy me…

My phrasing was a bit narrow-minded there, I meant consumer *nix distributions like Debian and what have you. These all manage to make room for Thunderbird and whatever awful music client they've come up with, but lack handy CLI tools.

Re: Moreutils – Unix tools that nobody thought to write (2012)

#216

Earlier quoted context omitted.

> I thought they were api complainant drop-in replacements so it’s not like they fill in a missing role. 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 bei…

Hi thanks setting me straight. 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 though…

Interesting. Hmm. Not quite sure how to combat that one. The issue is that even though ripgrep is not POSIX compatible, it can pretty easily replace grep in most or all circumstances. The similarities between the tools are, for example, much greater than their differences. I know for me at least, I don't ever run grep interactively. The only time I ever use it is in shell scripts.

Re: Moreutils – Unix tools that nobody thought to write (2012)

#217
post #75

Earlier quoted context omitted.

I use Emacs shell-mode for most of my terminals, which allows navigating and editing the buffer just like any other file. I'll often make several copies of a command, then use a macro to alter each one; after checking that they look right, pressing Enter will send them all to the shell.

I always tried to use the shell with emacs (eshell, multi-term) but it didn't render correctly curses and all the fancy stuffs like emojis. Out of curiosity, how do you manage that?

When I used Emacs, Eshell was perhaps my favorite feature. I loved how modern it felt in many ways; why shouldn’t you be able to just `cd` into a remote location (TRAMP+SSH under the hood), or invoke Elisp commands like Magit straight from the shell. It could however be quite slow, and choked on some common escape codes (e.g. the progress bars emitted by the modern Ubuntu `apt` command.)

Regarding curses, I found that there was two solutions. The first is to automatically spawn curses apps in a proper terminal emulator, you just have to setup the `visual-commands` variable properly. The second alternative is to replace curses apps with Emacs apps, e.g. htop to helm-top. Personally, I ended up going the second route after a while, as I realized that there are actually very few curses apps that are important to me, and that Emacs apps are better integrated if you use Emacs for everything else.

If you rely on a lot of curses apps, a “real” terminal like emacs-libvterm may however suit you better. Renders curses apps and emojis as well as any other terminal I’ve used. It’s also much faster than ansi-term and friends at rendering.

Re: Moreutils – Unix tools that nobody thought to write (2012)

#218
post #211

Earlier quoted context omitted.

direnv is super useful if you're working in Python and have multiple projects: you can add an .envrc file that activates the right virtualenv whenever you enter a directory. It's one less thing to worry about. 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. Al…

I've got a hand rolled direnv that's quite simple: function lenv { path=$PWD while [[ ! -f "$path/.env" && "$path" != '/' ]]; do path=$(dirname "$path") done if [ -f "$path/.env" ]; then source "$path/.env" fi } function cd { builtin cd "${@}"; lenv; } 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=$(d…

direnv does allow more than just environment variables, you can run arbitrary commands. Personally I wouldn't run potentially expensive commands like building the project, but if that's really what's best for your workflow, it can be 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.

Re: Moreutils – Unix tools that nobody thought to write (2012)

#219

Earlier quoted context omitted.

According to Stack Overflow [1], this works: sed -i.bak 's/foo/bar/' filename [1]: https://stackoverflow.com/a/22084103/3266847

That works when specifying a backup extension, but not if you don’t want to create a backup file. sed -i ‘’ ... works on BSD sed but not GNU. Meanwhile: sed -i’’ ... sed -i ... both work on GNU but not BSD.

Well, yes, you can't use it without creating a backup file, but it uses "-i" and is portable.

Re: Moreutils – Unix tools that nobody thought to write (2012)

#220
post #15

Nice collection of quite useful tools. Some of these can be easily replicated by using a more modern shell (bash, zsh) like mispipe, others are just shortcuts (e.g. ifne, chronic). But what immediately stood out to me is `vidir`. I really like the idea of editing file names with an editor. Using loops and regex in a shell for mass renaming can be a mess. It should be way easier with `vim`. This tool made me install m…

I've known about `moreutils` for years, but the only two I ended up actively using myself are `vidir` and `vipe`.

Outside of `moreutils`, one of the utilities I always install on all my machines is `atool`, which is just so much nicer and more intuitive than trying to remember the command-line options needed to handle the various tar.*, rar, zip, 7zip, lzip, etc. archive formats from the command line.

Post reply on HN