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.
mid-kid 1 hours ago [-]
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.
alance 32 minutes ago [-]
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.
functionmouse 11 minutes ago [-]
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
znpy 19 minutes ago [-]
While true, what you describe is very unlikely to happen and most definitely won’t happens on systems where i’m the only users.
CGamesPlay 10 minutes ago [-]
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.
e1g 7 minutes ago [-]
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"
112233 1 hours ago [-]
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
deredede 31 minutes ago [-]
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.
fragmede 1 hours ago [-]
curious if you're customizing anyway, why not use eg ripgrep?
llimllib 9 minutes ago [-]
Not OP, but I use ripgrep and customize it with an alias as well, so it applies equally there
1 hours ago [-]
chrisjj 1 hours ago [-]
> If I introduce an executable with a name, that overrides a system one
... and breaks existing scripts that reference the system one, right?
amszmidt 37 minutes ago [-]
Not if it is an alias.
caeruleus 2 hours ago [-]
Prefixing commands solves the namespace problem and discoverability (at least partly). I use a slightly more sophisticated method, which helps me remember which custom utilities are available and how to use them: sd [1], a light wrapper written for zsh that, in addition to namespaces, provides autocompletion, custom help texts + some other QoL enhancements. Can definitely recommend if you're looking for something a bit more fancy.
Using commas in filenames feels kind of weird to me, but I do use a comma as the initiator for my Bash key sequences.
For example:
,, expands to $
,h expands to --help
,v expands to --version
,s prefixes sudo
You put keyseqs in ~/.inputc, set a keyseq-timeout, and it just works.
ljouhet 2 hours ago [-]
Most of my aliases contain `--` for the same reason, `git--progress`, `grep--rIn`, `nvidia--kill`, `ollama--restart`, `rsync--cp`, `pdf--nup`...
Easy autocomplete, I know there won't be any collision, and which command is mine.
finghin 15 minutes ago [-]
Great hack!
tomcam 1 hours ago [-]
Every tool and shell that lay in arm's reach treated the comma as a perfectly normal and unobjectionable character in a filename.
WTF. After 40 years maybe I should have figured that one out.
pm215 1 hours ago [-]
It's not a completely non special character: for instance in bash it's special inside braces in the syntax where "/{,usr/}bin" expands to "/bin /usr/bin". But the need to start that syntax with the open brace will remind you about the need to escape a literal comma there if you ever want one.
mike-the-mikado 28 minutes ago [-]
Until someone forces you to use a file system that cannot tolerate commas...
temporallobe 14 minutes ago [-]
I don’t think this is a terrible idea, though stylistically it bothers me. I suppose you could simply have a prefix command router that would essentially do the same thing. I also started using “task” recently and it’s been a game changer for my CLI life.
mogoh 5 minutes ago [-]
What is task?
impoppy 1 hours ago [-]
Why so many people use ~/bin/? What’s wrong with ~/.local/bin?
1313ed01 54 minutes ago [-]
Random things are installed in ~/.local/bin. In ~/bin I have only what I put there.
dark-star 1 hours ago [-]
~/bin/ preceeds the XDG Base Directory Specification.
~/.local was only invented around 2003 and gained widespread usage maybe 15 years or so ago...
People used ~/bin already in the 90s ;-)
zhouzhao 1 hours ago [-]
Nothing. I also use `~/.local/bin/`
vitorsr 54 minutes ago [-]
Nice although I think the ASCII comma feels wrong as part of a filename even if for purely aesthetic reasons.
If we want to stay within (lowercase) alphabetic Latin characters I think prefixing with the least common letters or bigrams that start a word (x, q, y, z, j) is best.
`y' for instance only autocompletes to `yes' and `ypdomainname' on my path.
Choosing a unique bigram is actually quite easy and a fun exercise.
And we can always use uppercase Latin letters since commands very rarely use never mind start with those.
Tade0 24 minutes ago [-]
As a non-native English speaker I just name them in my native language or using British English spelling.
I have a command named "decolour", which strips (most) ANSI escape codes. Clear as day what it does, almost nobody uses this spelling when naming commands that later land as part of a distribution.
mromanuk 2 hours ago [-]
It’s clever, but is not aesthetic. A comma feels unnatural in the fs.
mystifyingpoi 1 hours ago [-]
It doesn't have to be a literal file, it can be an alias.
tezza 57 minutes ago [-]
This is a really good practical step if you worry about name collisions
quick, easy and consistent. entirely voluntary.
Bravo
52 minutes ago [-]
jph 2 hours ago [-]
Clever hack! <3 I also do namespacing yet in a different way.
I create a home directory "x" for executables that I want to manage as files, and don't want on PATH or as alias.
To run foo: ~/x/foo
For example I have GNU date as ~/x/date so it's independent of the system BSD date.
sevg 2 hours ago [-]
This is one of those ideas that is so simple and elegant that it makes you think “why did I never think of doing this?!”
Neat trick! I don’t think I’ll namespace everything this way, because there’s some aliases and commands I run so often that the comma would get annoying, but for other less frequently used helper scripts then this will be perfect!
bonzini 1 hours ago [-]
I do something similar with build trees, naming them +build, +cross-arm etc.
This convention was suggested by the GNU Arch version control system years ago (maybe 20??), but it's really useful for the same tab completion reason and I have kept it for almost two decades, even when I switched to git.
amszmidt 39 minutes ago [-]
It was suggested by Tom Lord (RIP), who used it heavily long before he wrote GNU Arch.
File names or directories starting with a comma where considered “junk”, and ones with a plus sign I think where considered “precious”.
pjerem 2 hours ago [-]
Maybe then try ending your commands with a comma so that you don’t break first-char autocomplete !
stavros 2 hours ago [-]
But that's the killer feature for me! I always forget the little commands I've written over the years, whereas a leading comma will easily let me list them.
skerit 51 minutes ago [-]
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?
1vuio0pswjnm7 2 hours ago [-]
I use a different prefix character, e.g. "[", but I have been doing this for years
I started using a prefix because I like very short script names that are easy to type
I prefer giving scripts numbers instead of names
Something like "[number"
I use prefixes and suffixes to group related scripts together, e.g., scripts that run other scripts
I have an executable directory like ~/bin but it's not called bin. It contains 100s of short scripts
feelamee 36 minutes ago [-]
do you publish dotfiles and scripts anywhere? I'm interested to see them
falloutx 2 hours ago [-]
Finally a post that is relevant to what I have been looking for quite some time.
Also, kudos to keeping it so concise and to the point, thats some prime writing.
can someone explain security consideration of placing scripts into $HOME?
Some time ago I moved all my scripts to /usr/local/bin, because I feel that this is better from security perspective.
Galanwe 24 minutes ago [-]
There are no security implications, on the contrary.
It is objectively cleaner to keep your user scripts in your home, that way they are only in _your_ PATH, whereas putting them in /usr/[local/]bin implicitly adds them to every [service] user on the machine, which I can see creating obscure undesired effets.
Not even mentioning the potential issues with packages that could override your scripts at install, unexpected shadowing of service binaries, setuid security implications, etc.
dadandang 2 hours ago [-]
,Start all of your commands with a comma
zdc1 2 hours ago [-]
Should be titled Prefix your script names with a comma.
Current title is a little clickbait-y through its ambiguity.
albert_e 1 hours ago [-]
Agree.
I thought the title meant I should type ,ls instead of ls.
JamesTRexx 1 hours ago [-]
,sudo make me a sammich
Like so?
gugod 2 hours ago [-]
I tried a variant or this idea so many years ago after I leaned git and rearranged some of my personal tools as subcommands (like git) of a single executable named "dude,"
It went weird pretty quickly...
laughing_snyder 1 hours ago [-]
> Like many Unix users, I long ago created a ~/bin/ directory in my home directory
`.local/bin` seems to be much more common in my experience for this use case. And for good reason.
Levitating 1 hours ago [-]
~/bin is actually created per default on OpenSUSE (though it's removal has been discussed several times).
zhouzhao 1 hours ago [-]
Unclutter your $HOME!
ndsipa_pomu 2 hours ago [-]
I appreciate the idea, but the comma just looks horrible to me as part of a filename. I can imagine someone unfamiliar with the naming scheme to get confused.
I'd prefer to use underscore (when writing BASH scripts, I name all my local variables starting with underscore), but a simple two or three letter prefix would also work. I don't like the idea of a punctuation prefix as punctuation usually has a specific meaning somewhere and including it as the first character in a filename looks wrong. (e.g. Comma is typically used as a list separator and it's a bit of cognitive dissonance to see it not used in that context)
eterps 2 hours ago [-]
I use my_ as a prefix.
ndsipa_pomu 22 minutes ago [-]
I used to use "do" as a prefix e.g. "doBackup"
Nowadays, I tend to skip using a personal prefix and just try to name commands with a suitable verb in front (e.g. "backupMySQL") and ensure that there's no name collisions.
JamesTRexx 59 minutes ago [-]
Whenever I see "my" as a prefix, it feels like such a childish "my first Sony" thing.
I hate official sites using that.
luplex 2 hours ago [-]
similarly, I start all my underscorends with an underscore
I read this blog a few years ago, and implemented it soon after with a refresh of my rc files and shortcuts. Gamechanger - has helped me every single day since. It’s easy to remember, autocompletes easily, and adds a little flair of personalization.
2 hours ago [-]
Rendered at 12:55:24 GMT+0000 (Coordinated Universal Time) with Vercel.
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.
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.
Btw on the second suggestion, I think there's a command named `command` that can help with that sort of thing, avoids recursive pitfalls.
Don't tell people to sacrifice agency for apocalypse insurance that doesn't work, lol
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.
Because I cannot imagine much 3rd party scripts working with random flags added to core tools
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.
... and breaks existing scripts that reference the system one, right?
[1] https://github.com/ianthehenry/sd
You put keyseqs in ~/.inputc, set a keyseq-timeout, and it just works.
Easy autocomplete, I know there won't be any collision, and which command is mine.
~/.local was only invented around 2003 and gained widespread usage maybe 15 years or so ago...
People used ~/bin already in the 90s ;-)
If we want to stay within (lowercase) alphabetic Latin characters I think prefixing with the least common letters or bigrams that start a word (x, q, y, z, j) is best.
`y' for instance only autocompletes to `yes' and `ypdomainname' on my path.
Choosing a unique bigram is actually quite easy and a fun exercise.
And we can always use uppercase Latin letters since commands very rarely use never mind start with those.
I have a command named "decolour", which strips (most) ANSI escape codes. Clear as day what it does, almost nobody uses this spelling when naming commands that later land as part of a distribution.
quick, easy and consistent. entirely voluntary.
Bravo
I create a home directory "x" for executables that I want to manage as files, and don't want on PATH or as alias.
To run foo: ~/x/foo
For example I have GNU date as ~/x/date so it's independent of the system BSD date.
Neat trick! I don’t think I’ll namespace everything this way, because there’s some aliases and commands I run so often that the comma would get annoying, but for other less frequently used helper scripts then this will be perfect!
This convention was suggested by the GNU Arch version control system years ago (maybe 20??), but it's really useful for the same tab completion reason and I have kept it for almost two decades, even when I switched to git.
File names or directories starting with a comma where considered “junk”, and ones with a plus sign I think where considered “precious”.
Off-topic: What the hell is that font on this website? And why does the "a" look like that?
I started using a prefix because I like very short script names that are easy to type
I prefer giving scripts numbers instead of names
Something like "[number"
I use prefixes and suffixes to group related scripts together, e.g., scripts that run other scripts
I have an executable directory like ~/bin but it's not called bin. It contains 100s of short scripts
Also, kudos to keeping it so concise and to the point, thats some prime writing.
It is objectively cleaner to keep your user scripts in your home, that way they are only in _your_ PATH, whereas putting them in /usr/[local/]bin implicitly adds them to every [service] user on the machine, which I can see creating obscure undesired effets.
Not even mentioning the potential issues with packages that could override your scripts at install, unexpected shadowing of service binaries, setuid security implications, etc.
I thought the title meant I should type ,ls instead of ls.
Like so?
It went weird pretty quickly...
`.local/bin` seems to be much more common in my experience for this use case. And for good reason.
I'd prefer to use underscore (when writing BASH scripts, I name all my local variables starting with underscore), but a simple two or three letter prefix would also work. I don't like the idea of a punctuation prefix as punctuation usually has a specific meaning somewhere and including it as the first character in a filename looks wrong. (e.g. Comma is typically used as a list separator and it's a bit of cognitive dissonance to see it not used in that context)
Nowadays, I tend to skip using a personal prefix and just try to name commands with a suitable verb in front (e.g. "backupMySQL") and ensure that there's no name collisions.
2024: https://news.ycombinator.com/item?id=40769362
2022: https://news.ycombinator.com/item?id=31846902
2020: https://news.ycombinator.com/item?id=22778988