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.
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.
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.
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
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.
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.
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.
Properly manage PATH for the context you're in and this is a non-issue. This is the solution used by most programming environments these days, you don't carry around the entire npm or PyPI ecosystem all the time, only when you activate it.
Then again, I don't really believe in performing complex operations manually and directly from a shell, so I don't really understand the use-case for having many small utilities in PATH to begin with.
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.
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.
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.
It is like make but designed specifically for the way non-C(++) users - people like me for example adding scripts like "make run" and "make build" to my node/python/PHP/etc repos - use it. It is great! I still don't use it literally just because make is already installed on any *nix system I encounter day to day.
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.
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!
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.
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.
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.
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.
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,"
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)
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.
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.
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.
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.
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:
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.
While true, what you describe is very unlikely to happen and most definitely won’t happens on systems where i’m the only users.
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.
curious if you're customizing anyway, why not use eg ripgrep?
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.
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.
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.
[1] https://github.com/ianthehenry/sd
Properly manage PATH for the context you're in and this is a non-issue. This is the solution used by most programming environments these days, you don't carry around the entire npm or PyPI ecosystem all the time, only when you activate it.
Then again, I don't really believe in performing complex operations manually and directly from a shell, so I don't really understand the use-case for having many small utilities in PATH to begin with.
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.
Great hack!
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.
Until someone forces you to use a file system that cannot tolerate commas...
Why so many people use ~/bin/? What’s wrong with ~/.local/bin?
Random things are installed in ~/.local/bin. In ~/bin I have only what I put there.
~/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 ;-)
Nothing. I also use `~/.local/bin/`
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.
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.
What is task?
It is like make but designed specifically for the way non-C(++) users - people like me for example adding scripts like "make run" and "make build" to my node/python/PHP/etc repos - use it. It is great! I still don't use it literally just because make is already installed on any *nix system I encounter day to day.
It’s clever, but is not aesthetic. A comma feels unnatural in the fs.
It doesn't have to be a literal file, it can be an alias.
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.
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
do you publish dotfiles and scripts anywhere? I'm interested to see them
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.
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!
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.
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”.
Maybe then try ending your commands with a comma so that you don’t break first-char autocomplete !
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.
This is a really good practical step if you worry about name collisions
quick, easy and consistent. entirely voluntary.
Bravo
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?
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.
Interesting, though I never had enough custom scripts to justify this, I prefer oh-my-zsh plugin style short aliases instead, i.e. https://github.com/ohmyzsh/ohmyzsh/tree/master/plugins/git
,Start all of your commands with a comma
Should be titled Prefix your script names with a comma. Current title is a little clickbait-y through its ambiguity.
Agree.
I thought the title meant I should type ,ls instead of ls.
,sudo make me a sammich
Like so?
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.
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.
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...
> 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.
~/bin is actually created per default on OpenSUSE (though it's removal has been discussed several times).
Unclutter your $HOME!
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)
I use my_ as a prefix.
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.
Whenever I see "my" as a prefix, it feels like such a childish "my first Sony" thing. I hate official sites using that.
similarly, I start all my underscorends with an underscore
This is just brilliant. Thanks.
(2009)
Previous discussions:
2024: https://news.ycombinator.com/item?id=40769362
2022: https://news.ycombinator.com/item?id=31846902
2020: https://news.ycombinator.com/item?id=22778988
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.