141–150 of 252 posts
The problem in other distros is that if you prefix PATH so that it contains your executable "foo", and then run a program that invokes "foo" from PATH and expects it to do something else, the program breaks.
With Nix, this problem does not exist because all installed programs invoke all other programs not via PATH but via full absolute paths starting with /nix/store/HASH...
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…
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.
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 '
Why so many people use ~/bin/? What’s wrong with ~/.local/bin?
~/.local/bin is tedious to write, when I want to see directory content and - most important - I treat whole ~/.local/ as managed automatically by other services and volatile.
Tangentially related. Don't ever put "." in your PATH. I used to do this to avoid typing the "./" to execute something in my current directory. BAD IDEA. It can turn a typo into a fork bomb. I took down a production server trying to save typing two characters.
Why does this go wrong and in what situation?
Oh, that's without even going into the security risks and loss of portability.
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…
Thanks, mathfailure - this genuinely improves my life!
Worth pointing out that with Nix/NixOS this problem doesn't exist. The problem in other distros is that if you prefix PATH so that it contains your executable "foo", and then run a program that invokes "foo" from PATH and expects it to do something else, the program breaks. With Nix, this problem does not exist because all installed programs invoke all other programs not via PATH but via full absolute paths starting…
/nix/store/grep-hash -flags files | /nix/store/head-hash
instead of: "grep -flags files | head"?
I would have never thought of that. Funny that a comma can be used like that. Off-topic: What the hell is that font on this website? And why does the "a" look like that?
There’s this program on nix that lets you type a comma, then any application name that exists anywhere in the Nix repos. It then downloads that app and runs it once, without “installing” it. Sometimes I find myself running something dozens of times this way before I realize it should probably be in my config.
https://github.com/nix-community/comma
Earlier quoted context omitted.
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 s…
Why? It protects you from someone else (cough updated packages introducing new commands cough) picking a name you already use.
Worth pointing out that with Nix/NixOS this problem doesn't exist. The problem in other distros is that if you prefix PATH so that it contains your executable "foo", and then run a program that invokes "foo" from PATH and expects it to do something else, the program breaks. With Nix, this problem does not exist because all installed programs invoke all other programs not via PATH but via full absolute paths starting…
So if I want to use grep in a small script, do I have to write: /nix/store/grep-hash -flags files | /nix/store/head-hash instead of: "grep -flags files | head"?
[user@nixos:~]$ which grep
/run/current-system/sw/bin/grep
[user@nixos:~]$ ls -l /run/current-system/sw/bin/grep
lrwxrwxrwx 1 root root 65 Jan 1 1970 /run/current-system/sw/bin/grep -> /nix/store/737jwbhw8ji13x9s88z3wpp8pxaqla92-gnugrep-3.12/bin/grep