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.

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 with /nix/store/HASH...

Glad it worked for OP, but I've never once in 30+ years of this had a conflict that did something I didn't want. ~/bin/ is early in my PATH, and for a good reason. Things I put in there I want to take precedence, so I use this to purposely override provided bins. (Though I can only think of one time I wanted to do that, too.)

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.

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.

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.

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

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.

    Every tool and shell that lay in arm's reach treated the comma as a perfectly normal and unobjectionable character in a filename.

Why so many people use ~/bin/? What’s wrong with ~/.local/bin?

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!

This has been a popular topic nearly every time the post makes the HN front page.

* https://news.ycombinator.com/item?id=40769362 (2024, 169 comments)

* https://news.ycombinator.com/item?id=31846902 (2022, 123 comments)

* https://news.ycombinator.com/item?id=22778988 (2020, 90 comments)

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

instead of using ~/bin I use ~/installed/bin, sometimes I need build a command from source then install it, which might have share/ man/ etc so I can avoid installing them under the home dir.

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.

It’s clever, but is not aesthetic. A comma feels unnatural in the fs.

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.

This is one of those "obvious in hindsight" tricks. The comma prefix gives you a namespace that's guaranteed to never collide with system binaries, shell builtins, or anything from a package manager.

I do something similar with my personal scripts — prefix them with a short namespace. The real win isn't just avoiding collisions though, it's tab completion. Type the prefix and tab, and you immediately see all your custom stuff without wading through hundreds of system commands.

The 2009 date on this is wild. Some of these simple unix conventions age better than most frameworks.

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.

I prefer all my custom commands as 1 letter.

On my most frequently used machine/dev env this means -

e for vim

m for mise

n for pnpm

c for Claude

x for codex

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.

I think its a fairly good idea - but for myself, i had already mapped csh’s default history character (!) to a comma (,) for the same reason - no shift key to invoke.

In many contexts in which I am trying to deconflict namespaces, I use my initials. I hadn't thought about it in this particular context, though now that I do, it seems fortunate that I am ced rather than sed.

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 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.

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

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?

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...

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.

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)

> 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.

similarly, I start all my underscorends with an underscore

This is just brilliant. Thanks.

(2009)

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.