Hacker News Reader

Comment by mid-kid | Hacker News Reader

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.

View on HN

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.

Because it's useless extra typing. People try to narrow commands down to two fucking chars and you suggest to type the whole goddamn path!

Nobody suggested typing whole paths.

They did. Just not explicitly.

I've asked you why prepending paths to PATH instead of appending was a bad idea. How is having typing full paths has anything to do with it?

The only situation where you'd need to type a full path is when you have a name collision. But the suggestion to not worry about collisions with unknown system binaries also said to put the script folder first. In that situation running the script doesn't need a full path, and you won't be running the unknown system binary. So you won't be typing full paths.

Please explain the non-explicit suggestion you see, because I don't see it.

It's clear that "adding your script directory in front of the PATH" means a one time edit to .bashrc or equivalent, right? In normal use you're not typing it.

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 '

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?

I learned to deliberately declare paths pretty early on in my adventures at the CLI. I don't leave room for accidental alternative execution. It might be overkill, but it gives me a sense of security and that's why it's there. Don't worry, I probably made a terrible mistake somewhere else that completely negates my attempts at a correct shell environment.

Reply on news.ycombinator.com