Hacker News new | ask | show | jobs
by bqmjjx0kac 733 days ago
> Because my shell script names tended to be short and pithy collections of lowercase characters, just like the default system commands, there was no telling when Linux would add a new command that would happen to have the same name as one of mine.

Not sure I understand this problem. I just put my bin directory at the front of $PATH rather than the end. To browse my commands, I simply `ls ~/bin`.

4 comments

But then you start using some tool that expects $0 in the system path and breaks causing frustration and debugging.

Pick your poison

Fair point. I've been doing this for years and none of my scripts have ever caused any (noticeable) breakage, though.

The danger is also mitigated because I only modify my own user's shell rc file. Any daemons running as root or their own user are unaffected.

Article is from 2009. Plenty of prevalent short named tools have been released since then, causing exactly this sort of issues. Just thinking about it, "node" and "npm" come to mind.
> causing exactly this sort of issues

POTENTIALLY. This (for me, anyway), is a solution in search of a problem. Been using some sort of *nix since the early 90's, writing scripts and commands and aliases and functions the whole time - this has never once happened to me.

It obviously _can_, and PROBABLY has, to some. But it's more a "can" than "will". Maybe I just name my homebrew stuff in a way that's unlikely to collide, dunno.

In 35 years of using Unix I've never come across anything like this. What tool do you use that this is an issue?
Mostly build tools. I also have a custom script called ip way before Linux made theirs and caused some problems.
I put ~/bin/ at the start of my path as well. It works very well for me, but I also have to admit that I've never experienced a name collision from doing this as far as I'm aware.

I'm not on the comma train here because it makes the name ugly and confusing, and doesn't solve any problem that I have. But it is a clever hack for those who do have this problem.

What is "system path"? Every tool inherits the caller's path. I don't think this could be a problem unless a tool talked directly to systemd to execute itself.
Default PATH minus ~/bin.
There is no "default PATH", the default is inheriting the parent process's.
I’m here to communicate not be pedantic. I’m sure you could understand what I meant.
in the context of "some tool that expects $0 in the system path..." - i do not understand either.

if a tool looks up a command name "x" given to it, it just takes $PATH and goes through it. the same $PATH as in your shell when you call "x" directly.

thinking more about it, you must thought something like putting "@daily mycommand ..." in crontab, then being annoyed by it not finding your command. then the problem is not that some tools expecting a "system path", but that some tools being defiant and overrides inherited path on their own accord. which is totally unneccessary: environment is called environment because it is prepared for you (the given program) to run in.

I just… remember the names I give things? Why is this considered a “hack” of some kind?
It may not be useful to you, but it seems a bit too much to then jump to the conclusion it must be useless for everyone.

I forget names all the time. I even forget I wrote entire projects sometimes. That's why I try to organise my systems in a way I can easily stumble upon things I haven't thought about in months, or years.

I find this article's approach actually solves a problem for me. I do find myself going back to the ~/bin folder once I a while to look for some script I use less often. So at least for N=2, it's a cool hack.

I go to my bin dir and list the files.
One of the benefits is using fzf autocomplete. E.g. in fish type the first char of the command and Tab to launch fzf. Then `,`+Tab is a quick way to filter these custom commands. Versus `ls ~/bin` would be a lot of characters for something I do a lot, or maybe I'd be going `ls`+UpArrow+UpArrow+UpArrow to autocomplete that first.
The “ls “ part is not necessary for tab completion.

    ~/bin<tab><tab>
Is enough. Not that short, but is something done infrequently in my experience. Maybe I’d do it more if it was easier?
ls ~/bin is wayyyyy slower to type than ,<tab>
You could make a command called , that runs ls ~/bin ...
Name it ","
Yep, that's what I said.
Dang, sorry, I misread your comment.
I'm not dang.

</s> :)