> I just prefix it with a backslash: \grep

Word of warning, I use `\grep` quite frequently. The usage is when you are piping after grep or saving to a variable.

Illustrative example:

  $ TO_DL=$(curl "https://foo.com/releases/" \
            | grep -e "latest" \
            | head -n1 \
   )
  $ curl $TO_DL
  curl: (3) bad range in URL position XX
  https://foo.com/releases/latest.tar.gz
                           ^^^^^^

Annoying footgun, but something to be aware of in case you go down this extremely confusing rabbit hole like me. I couldn't figure it out until I decided to hexdump the string.

[Side note]: My first thought reading the article was also about how `\` basically solves the problem but they do have one advantage in that they can do `,<tab>` and get a list of all their custom commands. Personally not worth it for me but I can definitely see this being useful for some. Especially on shared systems. But getting everyone to prefix a script name seems just as unlikely as getting everyone to place programs in the right location.

Looked so backwards to me, too. However, I decided to give it a go, anyway. Now, I have some scripts and small commands which start with a comma, and it looks neat and time saving.

Yes, I can do path ordering to override usual commands. However, having a set of odd-job scripts which start with a comma gives a nice namespacing capability alongside a well narrowed-down tab-completion experience.

While it's not the neatest thing around, it works surprisingly well.

Another idea which looks useless until you start using is text expanders (i.e.: Espanso and TextExpander).

Either adding your script directory in front of the PATH, or creating `alias` that provide a full path to your script where a conflict exists, makes a whole lot more sense to me.

I've never had this collision problem yet, despite appending my script directory to the end, but I'll use either of the above solutions if that ever becomes a problem.

TIL: Backslash overrides alias - wow!

Thanks, mathfailure - this genuinely improves my life!

When “I” means me then this usually works for me. But when “I” becomes “we”, sometimes this goes off the rails because someone introduces a bin with breaking changes that silently fucks up projects that dev doesn’t really know about, or forgot about.

Call it the Chesterton’s Fence of ‘which’.

I would recommend against overriding standard system binaries, you could break compatibility on your system with scripts that depend on those binaries. I just use an abbreviation like rg=“grep -RE”

I do this, and routinely shadow commands with my own wrappers to do things like set environment variables.

And then there’s Claude. It deletes whatever it finds at ~/.local/bin/claude, so I have to use a shell function instead to invoke the full path to my wrapper.

Any severe side effects so far? Have you set PATH up somehow so it is effect only on interactive prompt, and not in the launched processes?

Because I cannot imagine much 3rd party scripts working with random flags added to core tools

Just on your first suggestion, this also means that if a person or process can drop a file (unknown to you) into your ~/bin/ then they can wreak havoc. Eg they can override `sudo` to capture your password, or override `rm` to send your files somewhere interesting, and so on.

Btw on the second suggestion, I think there's a command named `command` that can help with that sort of thing, avoids recursive pitfalls.

I do the same thing, but I also have a command that shows me what functions or scripts might be shadowing other scripts

> If I introduce an executable with a name, that overrides a system one

... and breaks existing scripts that reference the system one, right?

curious if you're customizing anyway, why not use eg ripgrep?