Comment by mathfailure
17 days ago
I didn't like the idea. I prefer the alternative approach: _I_ decide the order of dirs in the PATH env. If I introduce an executable with a name, that overrides a system one - I probably do that intentionally.
If I introduce an alias (like `grep='grep --binary-files=without-match --ignore-case --color=auto`) that matches the name of a system binary - I probably do that intentionally.
And if I EVER need to call grep without my alias - I just prefix it with a backslash: \grep will search with case sensitivity and no color and will scan binaries.
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).
I never knew that what I've known as 'hotstrings' (since the AutoHotKey days) other sometimes also call 'text expanders'.
Love Alfred Snippets for this same text expander need.
The irony in the number of extra commas you've used in this comment...
As a non-native English speaker and writer/typer I'm not well versed in usage of commas unfortunately.
Feel free to add the required ones while reading this comment.
Sorry for the inconvenience this might create.
4 replies →
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.
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.
> That's a poor advice for the scripts you call relatively frequently.
Why? It protects you from someone else (cough updated packages introducing new commands cough) picking a name you already use.
6 replies →
From my own aliases:
There are others with flags added. These are the ones that override the builtin MacOS versions that aren't up-to-date.
Slightly confused as to why - surely homebrew adds itself to the PATH ahead of the system utilities?
Also - surely vim auto-reads your vimrc?
1 reply →
TIL: Backslash overrides alias - wow!
Thanks, mathfailure - this genuinely improves my life!
‘command grep’ also works in several shells. A little longer but looks good in scripts etc.
I have an almost identical grep alias.
Word of warning, I use `\grep` quite frequently. The usage is when you are piping after grep or saving to a variable.
Illustrative example:
Annoyingly `--color=auto` can change the representation of the characters so when you run again there's a mismatch. I just find `\grep` easier than `grep --color=never`.
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.
most pipe-friendly commands check if stdout is attached to tty or not, and if not, they drop the extra color/formatting. so grep --color=auto shouldn't output color during pipes.
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 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.
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:
How does your sandbox ruleset look? I've been using containers on Linux but I don't have a solution for macOS.
5 replies →
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
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.
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”
Why are those scripts running in interactive login shells? If they are influenced by the configuration of profile, then the scripts are bad.
That’s true, but I would still call overloading system binaries bad practice. Your making yourself foot gun.
2 replies →
The problem with this is that you don't know what future conflicts will be. You spend years training yourself to use your own "jq" alias and then you find yourself needing to use the "jq" program and you have to remember to prefix it with backslash every time you use it (including when you copy-and-paste a command line from a webpage), or rename your own alias and re-train yourself to use its new name.
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.
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.
While true, what you describe is very unlikely to happen and most definitely won’t happens on systems where i’m the only users.
The issue of rootless malicious command overrides is solved by typing the whole path, such as "/bin/sudo".
No, don't do that as a precaution. As others have already answered correctly - it's too late to worry about such things if a malicious agent has write access to your ${HOME} dir.
The premise of the article is the desire to avoid accidental collisions, especially from newly installed system binaries.
In such cases you might get errors like sl being both a version control system and the steam locomotive
I do the same thing, but I also have a command that shows me what functions or scripts might be shadowing other scripts
Care to share?
the sibling answer but with `-a` before command name, will display all path hits for a command.
2 replies →
quite simple
type -a <commandname>
1 reply →
curious if you're customizing anyway, why not use eg ripgrep?
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.
That wasn't my point. The params don't match so you'd be hurting yourself to alias grep=rg; my point was if you're already customizing the system, then upgrading to ripgrep should also be on the table.
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
> If I introduce an executable with a name, that overrides a system one
... and breaks existing scripts that reference the system one, right?
Not if it is an alias.
But yes if it’s another executable.