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.

    alias claude="sandbox-exec -f ~/agents-jail.sb ~/.local/bin/claude --dangerously-skip-permissions"

  which <commandname>

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.

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

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.

  openssl ,v

  openssl --version

    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.

    file,.txt   
    file,,.txt   
    file,,,.txt

    echo file{",",",,",",,,"}.txt

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)

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

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

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.

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!

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.

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.

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

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.

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

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.

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.

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

This is a really good practical step if you worry about name collisions

quick, easy and consistent. entirely voluntary.

Bravo

,Start all of your commands with a comma

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.

[dead]