Hacker News Reader

Comment by whartung | Hacker News Reader

The singular habit I picked up way back in the day was to simply cope with what was available.

There's all sorts of utilities and such. Emacs was a grand example at the time as well. Lots of better mousetraps.

But when you bounce around to a lot of different machines, machines not necessarily in your control, "lowest common denominator" really starts to rear its ugly head.

That vast majority of my command line concoctions are burned into muscle memory.

Today, I think the base line install of modern *nixes are higher than they were back in the day, but the maxim still applies of working with what they have out of the box.

View on HN

> The singular habit I picked up way back in the day was to simply cope with what was available.

Nothing wrong with that. There are other ends of the spectrum of "make the things I do often as easy as I can", too. Both work.

It reminds me of my father; when he got in a car that wasn't his, he would NOT CHANGE ANYTHING. You couldn't tell he was in it. Safety issues aside, there's an argument to be made to make it as comfortable for you as you can; seat, mirrors, environment, etc. to minimize any distractions.

I see this too in my (software development) communities; some people like to tailor their development experience to the n'th degree to extract as much personal enjoyment/optimization/etc. out of it as they can. Others like to use whatever they're given and be happy with that. Both work.

Myself, I type for a living so I like to use keyboards I like. I bring my own with me in my "go bag" for when I'm out so I don't have to use the (IMO!) crappy Apple Laptop KB's. I /can/ use it, I just choose not to. Other people either like them, or have learned they don't care enough. All good.

Counterpoint, deciding not to put up with old things that are a pain in the ass is part of unseating the existing momentum so we can finally move on to better things.

Knowing how to do things the annoying way doesn't mean that has to be the preferred way. Being open to retooling is part of staying relevant

What I would like to see in that case is a "next gen utils", a bundling that makes it likely to find a number of these tools together in future servers.

Really the "right" way to go about it would be to employ an existing package manager (there's enough already, we don't need another) and some magic glue on top that makes it easy.

For example, you have your configuration of packages, in the ephemeral cloud somewhere, and you do the really dangerous no good thing of piping through bash with some kind of uuid that's assigned to your account, something like (totally made up url)

    curl packman.info/users/aed1242faed60a | bash

And it sniffs the architecture, version of binaries to install, which ones are there, and then puts it into an install directory configured by you.

This is like 97% existing things with a little glue and interface polish so you can easily bring in an environment.

There's certainly other ways but the idea remains the same

Yep, I've started keeping a github repo of install scripts / dotfiles / etc that basically amounts to the workflow you described.

YES. That isn't a completely new shell. I keep trying the fishes and z-shells of the world and I keep coming back to "my own hacked up bash" because of muscle memory on random edge case things.

That's why I stuck with vi and sh back in the day: I knew they were on every machine I might telnet to (this was before ssh, sigh).

On machines I controlled, I mostly used ksh, but it wasn't available on all machines; I cannot remember if it was the SunOS boxes or the older HP-UX or the Apollos, but there were a few. (csh? Go away. No, just go.)

Nowadays, vim and bash are everywhere I need them to be, even if I have to kludge around some version differences.

My only real gripe about find is the awkwardness of pruning multiple hierarchies. After you've written

  find / -path /sys -prune -o -path /dev -prune -o ... -o -type f -exec grep -H WHATEVER {} \;

a few times, and have returned to the previous command to add yet another

  -o -path ... -prune

tuple, it gets a little old.

But it works. Everywhere.

(* that I need it)

This is fine and all, but there are also subtle differences in standard CLI tools depending on the implementation. I'm used to GNU stdutils, and butt heads with the macOS and BusyBox implementations.

Yes, to get by with what is available is a useful trait. No matter how good these tools are, I will often arrive at a prompt where they are unavailable.

Why don't you make them available in ~/bin and have a better shell life?

This.

I have exa and rg and fd all installed but unlearning the find and grep muscle memory is hard.

Occasionally I give the newer stuff a go and then end up stumbling over syntax differences and end up just going back to what I know.

If you ever give ripgrep a go, stumble over something and are inclined to: please post a Discussion question[1]. "beginner" or "stupid" questions are welcome. If you can show me what you know works with grep, for example, and are curious about an equivalent rg command, that could be a good question. I might be able to give you some "fundamental" answers to it that let you reason about the tools more from first principles, but on your terms.

[1] - https://github.com/BurntSushi/ripgrep/discussions

I aliased grep and find to their newer alternatives. Sure, the syntax will be off from time to time but due to muscle memory I couldn’t relearn the new tools otherwise.

Can't you just install Homebrew on your home dir and stop being locked up with the ancient environment?

Or you could just create a git repo with those executables and pull them to your machines?

I think about a month after I learned enough Vim to be dangerous RHEL (8, I think) started shipping nano as the default editor. Ah well, now I can scroll with the home row on my local box.

I found out recently that I can't even count on

    du -sh * | sort -h

to be portable. Got a batch of machines that don't support '-h'.

Agree. For most situations find and then grep is good enough.

Reply on news.ycombinator.com