Start all of your commands with a comma (2009)

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.

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.

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.

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

~/bin/cmd

$HOME/bin/cmd

c=$HOME/bin/ ; ${c}cmd # if you really are dead set on obfuscating your scripts.

Rather than the limited "magic of tab completion" I prefer the simple, yet general ls $HOME/bin

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.

WTF. After 40 years maybe I should have figured that one out.

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!

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

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

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

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.

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

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

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.

I actually have the below clashes function in my bashrc to detect overloaded names, and a few compgen aliases for sorted formatted command lists. Clashes takes a few seconds to chew through the 3000ish commands on my Steam Deck.

I also discovered the comma thing myself, and use it for `xdg-open <web-search-url>` aliases, i.e. `,aw xdg` searches archwiki for "xdg", since the SteamOS on this thing doesn't have manpages.

  alias words='iftty xargs'   # join by spaces
  alias c='compgen -c | sort -u | words' # eg: c | grep ^k | chop
  # ... a for aliases, f for functions etc ...
  alias man='g !archman'      # https://man.archlinux.org
  alias ,aw='g !aw'           # https://wiki.archlinux.org
  alias ,mdn='g !mdn'         # https://developer.mozilla.org
  alias ,nix='g !nixpkgs'     # https://search.nixos.org
  # ... a dozen others ...

  g() { local IFS=+; xdg-open "https://ddg.gg/?q=$*"; }
  iftty() { if [ -t 1 ]; then "$@"; else cat; fi; }

  chop() { # [TABS] [STARTCOL] [CUTOPTS..] # eg. ls ~/.co* | chop
    set -- "${1:-2}" "${2:-1}" "${@:3}"
    cut -c "$2"-$(($2+8*$1-2)) "${@:3}" | column #| less
  }

  clashes() { # [CMDS..] # print overloads eg: clashes $(c)
    (($#)) || set -- $(compgen -A alias -A function)
    local ty cmd; for cmd; do ty=($(type -at "$cmd"))
    ((${#ty[@]}>1)) && echo -n "$cmd "; done; echo
  }

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.

The comma has an unusual but super handy usage in PowerShell. When it precedes a variable of any array (list) type, the code it's the input to handles it as an array object, defending against the usual tendency to "unpack" the array and read in the elements that compose it.

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.

,Start all of your commands with a comma

I do something similar but with a project prefix. I maintain a lot of packaging scripts and settled on prefixing them by project - gps-build, gps-deploy, gps-sync etc. Tab completion does the rest.

The real issue isn't collisions though, it's discoverability. Six months later you forget half of what you wrote. The prefix at least lets you type gps-<tab> and see everything at a glance.

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.

Love this thread reminding me that most experts in computers are unhinged lunatics doing convoluted and tortured things on a daily basis that they consider perfectly normal and even convenient.

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.

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.

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.

One could set an env var to their local bin dir which is otherwise not in the path, like L=/home/ahepp/.local/bin, and then do $L/mycommand. Doesn't meet the OP's requirement of no shift key.

Or prefix files in the local bin dir with a couple letters from your username, like /home/ahepp/.local/bin/ah-mycommand

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

A lot of vim users use comma as the leader key so this is probably natural for a lot of folks.

Also seems convenient to be able to type ,<tab> to autocomplete over your custom commands, in case you forgot the name you assigned them.

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

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

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.

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

quick, easy and consistent. entirely voluntary.

Bravo

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.

I never did this and never once experienced a name conflict.

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 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 do this, and it's a huge quality of life improvement. No so much because of shadowing existing binaries, but for better command auto-complete. For example: I have a bunch of tmux utilities and all start with `,t` which is not a polluted command-name prefix compared to just `t`.

But I'm now facing the problem that LLM agents don't like this, and when I instruct them to run certain tools, they remove the leading comma. It's normally fixed with one extra sentence in the prompt, but still inconvenient.

Alternative, you can check whether there are duplicates under $PATH resolutions - binaries that can come from more than one place in $PATH.

    #!/usr/bin/env -S cargo eval --
    // cargo-deps: derive-error="0", is_executable="0"
    // vi: ft=rust

    use derive_error::Error;
    use is_executable::IsExecutable;
    use std::collections::{BTreeMap, HashSet, btree_map};
    use std::os::unix::fs::MetadataExt;
    use std::path::{Path, PathBuf};

    #[derive(Debug, Error)]
    pub enum Error {
        VarEnv(std::env::VarError),
        Io(std::io::Error),
    }

    fn main() -> Result<(), Error> {
        let mut paths_seen = HashSet::new();
        let mut path_fileid_seen = HashSet::new();
        let mut exes_seen = BTreeMap::new();

        for path in std::env::var("PATH")?.split(":") {
            let path = PathBuf::from(path);
            if !path.is_dir() {
                continue;
            }
            if !path_fileid_seen.insert(path.metadata()?.ino()) {
                continue;
            }
            if paths_seen.insert(path.clone()) {
                match std::fs::read_dir(&path) {
                    Err(_) => {
                        eprintln!("error listing {:?}", path);
                    }
                    Ok(readdir) => {
                        for entry in readdir {
                            let entry = entry?;
                            if entry.path().is_executable() {
                                let mut item = match exes_seen.entry(
                                    String::from(entry.path().file_name()
                                        .unwrap().to_string_lossy().as_ref()))
                                {
                                    btree_map::Entry::Vacant(v) => v.insert(vec![]),
                                    btree_map::Entry::Occupied(o) => o.into_mut(),
                                };
                                item.push(path.clone());
                            }
                        }
                    }
                }
            }
        }

        for (exe, paths) in exes_seen.into_iter() {
            if paths.len() == 2 {
                let mut strs = vec![];
                for path in paths.iter() {
                    strs.push(path.to_str().unwrap());
                }
                if strs.as_slice() == ["/usr/bin", "/usr/sbin"] {
                    continue;
                }
            }
            if paths.len() > 1 {
                println!("{}: ", exe);
                for path in paths {
                    println!("    {}", path.to_str().unwrap());
                }
                println!("");
            }
        }

        Ok(())
    }

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.

Why not just start every alias or script with ë or something?

(2009)

similarly, I start all my underscorends with an underscore

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

in vim i am very fond of two mapping prefixes: <space> and ,

they're both so easy to reach for

This is just brilliant. Thanks.

yes this is totally cursed but I kinda love the idea

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