Skip to content(if available)orjump to list(if available)

Start all of your commands with a comma (2009)


I do something a bit special... Instead of naming my script foobarnator (and hence risking that another foobarnator may exist in the future and may clash with my script), I name my script Then in my list of aliases I alias foobarnator to

The alias itself looks a bit weird in that to pass arguments to an aliased command you need to use a function (in Bash at least AFACIT) but it all works fine.

As aliases aren't sourced when other scripts are running, I'm sure my scripts/commands ain't ever going to clash with anything.

I've been doing that since years.

It also works fine to add "wrappers" to existing commands: for example to add additional input sanitization catching common mistakes I'm making when calling some commands.


> The alias itself looks a bit weird in that to pass arguments to an aliased command you need to use a function (in Bash at least AFACIT) but it all works fine.

No you don't:

    $ alias say=echo
    $ say beep
You do need to do something special the other way around (if you wrap a command in a function it needs to explicitly pass the arguments on).


Another advantage of aliases: in zsh at least, autocompletions of the aliased command Just Work (it breaks in wrapper functions)


What has always been a blocker for me to follow your example, is the desire to use many such scripts from the command lines provided inside an $editor or $email client. There probably is a way to configure both of them to see the aliases, but it's more straightforward to just have everything in the PATH.


Yes, it seems cleaner to just put "export PATH=$HOME/bin:$PATH" in $HOME/.bashrc. That avoids collisions with /usr/bin and /usr/local/bin. (Or rather, resolves collisions in favor of your personal bin directory.)


Your PATH is inherited by child processes that you start, including scripts that expect the system version of commands that have the same name as your commands.


Porque no los dos? It seems that

    function ,foo() { printf "Fooo\n"; }
actually works! (at least in my bash 5.0.17 shell)


I know this is unimportant, but the phrase is "¿Por qué no los dos?".


I used to do this, but it doesn't work with things like "watch".


I actually just learned from a different HN thread yesterday [1] that aliases do get expanded if you add this to your shell's rc file:

    alias watch='watch '
Specifically, if an alias ends with a space, it will cause the subsequent arg to be expanded as well. For example, try running:

    alias beep=echo
    watch beep hello # This will fail
    alias watch='watch '
    watch beep hello # Now it works!


Brilliant feature, but this is the sort of thing that reinforces the idea that CLIs have awful discoverability compared to GUIs.


I start my aliases with a period so that I have...

.foo1,.foo2, .foo3, and so on.




If I unknowingly named my command the same as some system command and the custom command ends up earlier in my path it doesn't really cause any problems does it? I wasn't using that system command anyways, and my custom command is only going to take priority if my .bashrc file was run first.


It can if you are executing programs that then try to execute those commands and get your commands instead.


I wish it was easier to create "snapshots" of a particular set of environment variables in order to use them later as run environments. I also wish that Unix desktop environments generally made it easier to manage env vars, but that's another complaint. And don't get me started on PAM env vars...


Direnv has been mentioned, and it meshes well with functional package managers like Nix and Guix, each of which include the concept of "Profiles". Each profile can access a specific set of programs via it's environment, but PATH is far from the last variable that you can use Direnv or Profiles to control.


Just env vars?

    env > "$(date +s).env-snapshot"
(And use it again slightly more awkwardly as

    <$file | xargs -I@ echo '"@"' | tr '\n' ' ' | xargs -I@ env @ cmd
or something more convenient to `cmd`.)


> I wish it was easier to create "snapshots" of a particular set of environment variables in order to use them later as run environments.

docker gives you this (but only as part of a whole ecosystem, which for various reasons you might not want to hitch your horse to).


Until you use a different machine and accidentally type your command without realizing it's not there.


Yes, all of that. And if you later decide to start using the system command, you just rename your custom command.


I use zsh and have the following alias (rather, function):

``` cp () { rsync -avhW --progress --inplace ${@} } ```

If I ever need to use the `cp` binary, I execute `=cp`, which evaluates to `/bin/cp`.


Why use rsync? Only for the progress bar?


I have used a similar windows trick. I wanted to add to the default window system a place for my library of tools. Most are "portable" cmd apps from various sources (sysinternals, nirsoft). I put them all into a directory called ] in the root of a drive.

Because of some common layout of keyboards the \ and ] are near each other, or in reach of left and right pinkies I can type \]\ before the name of the tools. This means I don't even have add a dir to the path.

I am sure this violates someone sensibilities but it has saved time over the years as a consultant when I had to deal with a wonky machine and owner did not want permanent install of diagnostic tools.


Unrelated but I heard it's possible to rename c:\ to /usr/bin or something, depending on your usage. I personally wouldn't mind renaming it to ~/<user-name> and be able to use some of my dotfiles in Windows.


It's possible, but 90% of software will break because of this lol


I put c:\tools in my path, then put shortcuts to all my tools in there (ie: shortcut to AgentRansack named ar). Now, I pull up the run command (WND+R) type ar and agent ransack opens.



Post-vista, c:\programdata\tools

Set yourself a %TOOLS% environment variable.


Clever trick. Too bad there's no good way to namespace commands. It would be interesting if you could have, for instance:

  $ mkdir -p /tmp/bin/my
  $ printf '%s\n%s\n' '#!/bin/sh' 'echo hello' > /tmp/bin/my/hello
  $ chmod 755 /tmp/bin/my/hello
  $ PATH="/tmp/bin:$PATH"
  $ my/hello


Plan 9 does that, I'm not sure why it never made it into Unix because I always loved it. Your networking-related commands were in `/bin/ip` and you'd run e.g. `ip/ping`. If you created the dir `$home/bin/rc/my` and put scripts in it, they would have been runnable as `my/hello` etc like in your example.


Plan 9 also more or less does away with the concept of $PATH in the first place; just union-mount (with `bind`) whatever you want onto `/bin` and call it a day. Yet another thing that would've been great for Unix-likes to pull in (I think some Linuxen can technically do it, but with some limitations).


All linuxen should be able to do that with overlayfs, I think.


no matter which kind of twisted idea someone comes up with related to terminals, there is always a guy who chimes in with "in Plan 9 you can do that...". It makes me smile every time. :)


I've tested it and it works on Linux (bash and zsh), at least for your custom commands


Ahem, technically there is one way (don't know if it is "good", though):

    $ export $MY = /tmp/my
    $ $MY/hello


What about:

  my hello
I.e. only my needs to be in the global namespace and all other commands are resolved by my itself.


You’d need to set up tab completion for the `my` command. This is more effort than just naming everything `my-foo` — or `,foo`.


Good point.


You could (ab)use home directories for that. I.e. place your hello into /home/my, and then you can invoke it as ~my/hello. You even get namespace completion for free after the `~`.


In zsh you can do "hash -d my=/path/to/my" and then you can use "~my/hello" from anywhere, and it doesn't need to be in /home.


> and it doesn't need to be in /home.

Neither do home directories.


Just add another comma. Of course, this needs some deeper magic to work :)



I think shells should support that, allowing you to do

  $ my hello
It would mean tools such as git, microk8s and aws wouldn’t have to implement that “look up first argument, check whether it’s a command I know, and if so, run it” on their own, and would have slightly simpler auto complete configs.

It also could mean launching fewer processes (for the case where ‘my’ is a script or executable that looks up the location of ‘hello’ and launches it)


I don't know if I would actually recommend this, but it works:

    $ touch foo::bar
    $ chmod +x foo::bar
    $ ./foo::bar && echo $?
It's an empty file so it does nothing, but most shells' lexers should be smart enough to not try and lex '::'.

Edit: Forgot to mention, this also works with bash functions and aliases. I'm not sure if POSIX sh will allow it. You can also do things like this (again, not sure I'd recommend it):

    $ alias +x='chmod +x'


I tend to give programs longer, more descriptive names and then do the short names as shell aliases. That way there’s little risk of name collision for the original program, scripts using the canonical name remain readable, and the shorthand is free to evolve to fit varying work habits.


My keyboard came with a tab key, so I don't worry about my commands having short names.


Until you have five commands which all use the prefix `sort-incoming-` and then three commands named `sort-incoming-hourly` and `sort-incoming-monthly` etc.


It would be nice to have camel-case completion in the shell, i.e. have “SIH” be completed to “SortIncomingHourly” and “SIM” to “SortIncomingMonthly”, etc. (only for upper-case characters). That way one could get more mileage out of the possible character combinations.


Why do the names have to be shorter, I never have to type it all out just the first couple of letters and then autocomplete. Dealing with aliases/“shortcuts” is such a pain plus I hate that pattern anyways.



Do you know any of the history of why your link to `.../Shopify/...` redirects to `.../nix-community/...`? Is the latter an open-source contribution by Shopify?


I think it was originally developed and maintained by Shopify, but was then handed off to the nix community


Correct. Source: I used the shit out of that command. Thanks Burke




This is for Nix.


I do something similar but 1. for aliases and 2. use period. For example, when working on a Rails project I define the following alias:

    function .routes() {
      if [[ $# -eq 0 ]]; then
        .rails routes
        .rails routes | grep $@
where .rails is another alias (for running bundle exec rails ...). I can then run ".routes webhook" and see all routes containing "webhook".

Last but not least, I automated the whole thing with bash-ctx (


I started creating wrapper-scripts or simple scripts that has the commands with my prefered options or a selection menu for said command. I have started calling those scripts my<command>

rsync becomes myrsync mount becomes mymount ssh becoms myssh

No collision and the naming convention empathise that it is indeed used be MYself.


Why people worry so much to create "short, easy to type" (coff coff cryptic) command names, nomenclature is so important in our profession and almost everybody sucks at it, give meaningful names to things even if they are 30+ chars long, is it really that though to press 3 or 4 keys along with maybe 3 or 4 tabs?


I was going to post the same thing. With tab completion long names can be typed quickly anyway. Also, the keyboard is the most fundamental input device for developers... learn how to use it well. It amazes me how many people who are professional developers use copy/paste so much because they can't type well. It slows them down to a crawl.

I don't particularly want to have to type 30-character names all the time without tab completion, but I'm not going to worry about an eight character command vs. a four character one.

Obviously this doesn't apply if you are dyslexic or disabled in some way or something.


I use this method for aliases in my `.*rc` file so I can remember what the heck I called things. Otherwise, I forget whether I have to type something like `COMMANDNAME-log` or `log-COMMANDNAME` or some other weird combo like `print-COMMANDNAME-log`. With a comma, I type `,<tab>` and get all of my custom commands listed easily.



I have a script that creates new ~/bin scripts that checks for collisions locally (functions, builtins, and executables) and in linux distros.

For example, I have a ~/bin/up script on every box and platform to install updates. So far so good on collisions.


Commas can also be used in filenames to help you sort things instead of using underscore as a separator, useful for the same reason -- you don't have to hit shift to type it.