I never knew that what I've known as 'hotstrings' (since the AutoHotKey days) other sometimes also call 'text expanders'.

The irony in the number of extra commas you've used in this comment...

Love Alfred Snippets for this same text expander need.

Why are those scripts running in interactive login shells? If they are influenced by the configuration of profile, then the scripts are bad.

From my own aliases:

   alias curl='/opt/homebrew/opt/curl/bin/curl '
   alias rsync-copy='/opt/homebrew/bin/rsync -avz --progress -h '
   alias rsync-move='/opt/homebrew/bin/rsync -avz --progress -h --remove-source-files '
   alias rsync-synchronize='/opt/homebrew/bin/rsync -avzu --delete --progress -h '
   alias rsync-update='/opt/homebrew/bin/rsync -avzu --progress -h '
   alias vi='/opt/homebrew/bin/vim -S ~/.vimrc'
   alias vim='/opt/homebrew/bin/vim -S ~/.vimrc'
   alias wget='/opt/homebrew/bin/wget -c '

One rarely actually needs to shadow binaries. Some cases could indeed be covered by introducing an alias that binds the binary's name to call a different copy of that binary.

You use shadowing to fix issues where you install some software that expects you to have a sane and ~recent version of some tool like git, but you don't as your system provides that binary and unfortunately it is either not sane (not GENERALLY sane [while it could be sane for system scripts]) or not recent enough. In that case the program's function would simply fail if it would call the system's binary and you shadow the binary with your version to fix that.

> adding your script directory in front of the PATH

That's a poor advice for the scripts you call relatively frequently. Instead, (as a general approach, we aren't discussing some particular script) don't use shadowing for scripts: just pick a non-conflicting script name and append the script's dir to $PATH.

‘command grep’ also works in several shells. A little longer but looks good in scripts etc.

You can use an alias, which takes priority over $PATH. e.g. I have this in .zhsrc to override the "claude" executable to run it in the OS sandbox:

    alias claude="sandbox-exec -f ~/agents-jail.sb ~/.local/bin/claude --dangerously-skip-permissions"

I also do this.

Random flags added to core tools are done with aliases, which do not affect the launched processes, not by shadowing them in ~/bin. Shadowing in ~/bin are for cases where a newer (compared to the system-wide version) or custom version of a tool is needed.

Not really, since if one usually does that - they probably understand the possible consequences and don't shadow whatever they like, but do it carefully.

On MacOS I shadow that way just curl and git binaries to the versions installed from homebrew and nothing has broken (yet). I know that tar on MacOS is also a weirdo that I'd rather shadow with the homebrew's gtar, but their args are different and I of course understand that there's a high probability of something in system to be bound to mac's version of tar, so here I better remember to use 'sane' tar as gtar or use an alias (instead of shadowing the binary) for tar to use gtar (because aliases are for users, not for system scripts/processes).

And on my home desktop's Debian - I don't even use shadowing of binaries at all (never needed it).

Also, I just realized: I change PATH env via my shell's rc script (~/.zshrc), so I probably could worry even less about shadowing system binaries (like tar on MacOS) possibly breaking things.

That would require someone to already want to sabotage me in particular, learn my private workflows, and also have write access to my home folder. At that point, All is Lost.

Don't tell people to sacrifice agency for apocalypse insurance that doesn't work, lol

If someone can drop a file in your ~/bin, they can also edit your shell’s startup files to add their malicious command.

I think it's already game over if they have access to your home directory. They can also edit your path at that point.

The issue of rootless malicious command overrides is solved by typing the whole path, such as "/bin/sudo".

While true, what you describe is very unlikely to happen and most definitely won’t happens on systems where i’m the only users.

Care to share?

Not if it is an alias.

Others have already given valid answers: grep is not ripgrep [their params don't match], so it's a bad idea to alias 'grep' to use ripgrep. But it's okay to alias 'ripgrep' (or 'rg' or whatever) to use ripgrep with some args.

repgrep's CLI options and general behavior are different from grep. I tend to use both for different things.

Not OP, but I use ripgrep and customize it with an alias as well, so it applies equally there