Hacker News Reader

Comment by keybored | Hacker News Reader

> The binary name for `ripgrep` is `rg`.

I don’t understand when people typeset some name in verbatim, lowercase, but then have another name for the actual command. That’s confusing to me.

Programmers are too enarmored with lower-case names. Why not Ripgrep? Then I can surmise that there might not be some program ripgrep(1) (there might be a shorter version), since using capital letters is not traditional for CLI programs.

Look at Stacked Git:

https://stacked-git.github.io/

> Stacked Git, StGit for short, is an application for managing Git commits as a stack of patches.

> ... The `stg` command line tool ...

Now, I’ve been puzzled in the past when inputing `stgit` doesn’t work. But here they call it StGit for short and the actual command is typeset in verbatim (stg(1) would have also worked).

View on HN

How would you capitalise it? RipGrep? RIPGrep? You’d need to pick a side and lose the pun. (And of course grep itself would need to be GReP if we took it all the way)

I wrote Ripgrep.

And they wrote "... you'd need to pick a side and lose the pun.."

And I am able to read four sentences.

Evidently reading isn't the same as comprehension

Yeah, you repeatedly failing to comprehend that I made a choice already and don’t care about losing hacker pun points.

Because we are constantly writing variables that are lowercase. Coming up with a name that is both short but immediately understandable is what we live for. Variables are our shrine, we stare at them everyday and are used to their beauty and simplicity.

Don't get me started on `nvim` to run neovim...

This was my first thought as well. I think I end up just calling it nvim sometimes even conversationally, the binary name is the most "real" thing to me.

It’s only 2 characters - if you use it all the time it becomes muscle memory.

You can simply add a shell alias with whatever name you like and move on.

True, but easier said than done, because one often need to work in more shells than their local machines..

This is a nonstandard tool. If you can't customize your machine, you already don't have it.

But it could be one day..

Do something like this to fall back to plain grep. You will somehow have to share these configurations across machines though.

    alias g=grep
    command -v rg 2>&1/dev/null && alias g=rg

You can't in most corporate env machines.

You may be able to download ripgrep, and execute it (!), but god forbid you can create an alias in your shell in a persistant manner.

> You can't in most corporate env machines.

Really? "most" even? What CAN you do if you can't edit files in your own $HOME?

`[citation needed]`

huh? If you can download and execute files, you can alias it. Either in your .bashrc file, or by making a symlink.

I daily drive linux, but I hop from clients to clients and I have probably served about 200 different structures so far.

Most corporate machines are Windows boxes with ps and cmd.exe heavily restricted, no admin, and anti malware software surveilling I/O like a hawk.

You might get a git bash if you are lucky, but it's usually so slow it's completely unusable.

In one client I once tried to sneak in Clink. Flagged instantly by security and reported to HR.

It's easy to forget that life outside the HN bubble is still stuck there.

How can you possibly get development work done in an environment where you can even make a Microsoft.PowerShell_profile.ps1?

You will be even more horrified to learn that installing the entire list of deps of a project that would take a few seconds on my home laptop may take up to 20 minutes at some clients because many FS calls do a network round-trip.

We are not talking about exceptions either. This is pretty standard stuff when you work outside of the IT-literate companies.

At one client, they provided me with a part time tester, they neglected to give him the permissions to install git. Took 3 weeks to fix.

The same client makes us dev on Windows machine but deploy on Linux pods. We can't directly test on the linux, nor connect to them, only deploy on it. In fact, we don't even have the specs of the pods, I had to create a whole API endpoint in the project just to be able to fetch them.

Other things I got to enjoy:

- CTO storing the passwords of all the servers in an libre office file

- lead testing in prod, as root, by copying files through ftp. No version control.

- sysadmin that had an interesting way of managing his servers: he remote controlled one particular windows machine using team viewer which ones the only one that could connect through ssh to them.

The list is quite long.

This makes you see the entire world with a whole new perspective.

I always thought that all devs should spend a year doing tech support for a variety of companies so that they get a reality check on what most humans actually have to deal with when working on a computer.

If you are on HN, you are the 1%.

Sixty-six words about capitalizing things properly and you think this is something that learning about shell aliases can solve. Impressive.

Reply on news.ycombinator.com