When I read the headline I thought this was going to be a terrible idea but I quite like it, especially the bit about using tab to list all your tooling.<p>Anecdotally I haven’t had many namespaces collisions recently. I’ve also let myself go a bit after going into management. My tech skills are 10 years too old.<p>Any tips from someone else on where they started to be hip again?
> Because my shell script names tended to be short and pithy collections of lowercase characters, just like the default system commands, there was no telling when Linux would add a new command that would happen to have the same name as one of mine.<p>Not sure I understand this problem. I just put my bin directory at the front of $PATH rather than the end. To browse my commands, I simply `ls ~/bin`.
I use short custom command names like aa, st, di, dp, cm and le in some thin wrappers around git.<p>One of these names actually collides with a utility that is installed by default on some systems.<p>Doesn’t matter to me. I have my own bin dirs before the system dirs in my path, so mine “win”, and I’m not really interested at all in the tool that mine has a name collision with.<p>If someone were to make a useful to me tool that collided with one of my own tools, I’d probably sooner alias that other tool to a new name that didn’t collide with mine, than to change any of my own tool names.<p>It’s just too comfortable to use these two-character tools of mine.
A kinda relevant question.<p>I use Windows most of time. Like the author, I have bunch of CLI scripts (in Python mainly) which I put into my ~/bin/ equivalent.<p>After setting python.exe as the default program for `.py` extension, and adding `.py` to `%pathext%`, I can now run my ~/bin/hello.py script at any path by just type `hello`, which I use hundreds of time a day.<p>I now use Linux more and more (still a newbie) but I never get it to work similarly here.<p>Firstly, Linux seems to have no concept of "associated program", so you can never "just" call .py file, and let the shell to know to use python to execute it. Sure, you can chmod +x to the script, but then you have to add a shebang line directly to the script itself, which I always feel uncomfortable since it's hard-coded (what if in future I don't want to execute my .py script with `/usr/bin/python` but `/usr/bin/nohtyp`?).<p>Furthermore, I failed to find <i>any</i> way to omit `.py` part when calling my script.<p>Again, none of the above is to question the design of the Linux -- I know it comes with lots of advantages.<p>But I really, really just want to run `hello` to call a `hello.py` script that is in my $PATH.
An alternative method for avoiding collisions in PATH is to use really long executable names that are unlikely to be used by other executables and then have shorter aliases for them in your bashrc. The aliases won't affect executables called from within scripts and you can still refer to your executables by their long names in your own scripts.<p>One drawback is that this doesn't have the same tab completion ergonomics, which I have to admit is really nifty.<p>EDIT: And another is that collisions can still occur in scripts that need to be sourced rather than executed as a sub-process (like Python's venv activation scripts). But those are rare.
I was recently poking around ~/.local/bin/ when I noticed that it had dozens of executables that I don't remember putting there. Mostly pyside things, but some other scripts as well. I really had to open each to jog my memory, especially about which scripts I had written myself and which were by other people.<p>The idea about starting my own scripts' names with a comma would have made the job go much faster, and I'm sure would have helped to job some memories about why each script was written, before opening it.
No thank you. Put your personal bin first in PATH, and use /usr/bin or /bin for referring to the shadowed programs.<p>You can list your personalized tooling using ~/bin/[Tab] for whatever value there is in that.
Encountering this idea 5 years allowed me to bring order to my bag of shell tricks! I have over 50 ,commands between aliases and ~/bin and my shell life is way smoother than the previous agglomeration.
I've been doing this for at least a decade. Was introduced to the idea by a colleague who might have read this blog post.<p>I usually do the same with commands where you are able to create sub-commands too, like git-,home (which allows you to run `git ,home add -p` and it conveniently set GIT_DIR to something and GIT_WORKTREE to $HOME). Sadly you can't do it with git aliases, I have to live with them starting with a dot (via '[alias ""]' as a section).
This works for text-expansion snippets too. All of the text expansions that I do with Alfred (other tools might work, too) are all comma phrases. I realize that writing English or even programming scripts/tag, I'd never (not so far) encounter a word or text that starts with a comma immediately followed by anything. I used to use period but have stumbled on instances such as file extension where a period can be followed by words.
The problem is that *nix has system utilities who's binaries are named in such a way to make it difficult to replace the nice shorthands that are useful during interactive use, because they may cause problems during script execution.<p>If we could go back to the drawing board I'd say every system utlity should have a verbose name with some kind of aliasing system that provides easy shorthands to them. Then the shorthands could be replaced easily, with the verbose names being used during scripting.<p>This might seem like a moot point, since we can't go back to the drawing board, but many projects continue to make this problem worse by insisting on naming their binaries like we're still living with the constraints of the 80s. I guess because it gives them the flavour of "real" system utilities. It would be nice if projects stopped doing that, but oh well.
Doesn't work with powershell (which, to be fair, was quite new at the time this blog post was released).<p>But honestly, while 2 or 3-letters aliases are tricky, I've very rarely had issues with 4-letter aliases. There are 456k possibilities. On my small opensuse install, my PATH contains only 105 4-letter executables.
With command completion, another option is to use descriptive names.<p>Just a few examples on this machine: backup-workstation-to-foo, backup-workstation-to-usb-restic, make-label-for-laptop-battery, set-x-keyboard-preferences, update-pocketbook<p>For one-letter and two-letter commands that might conceivably overlap with some command in some package someday (e.g., `gi` for `grep -i`), I only do those as interactive shell aliases. So they shouldn't break any scripts, and I'll know if someday I'm typing one of those and intending to get something different.<p>In a few cases, those one-letter aliases have been for very-often-used scripts of mine.
Great idea! And if for some reason you feel like your filenames should stay as they are (without a comma), you could just add symlinks to all executable files in your bin directory:<p><pre><code> $ cd ~/bin
$ for x in $(find . -type f -perm /a=x -exec basename {} \;) ; do echo $x ; done
temps
$ for x in $(find . -type f -perm /a=x -exec basename {} \;) ; do ln -s $x ,$x ; done
$ ls -l
total 4
lrwxrwxrwx 1 tanel tanel 5 Jun 23 16:38 ,temps -> temps
-rwxr--r-- 1 tanel tanel 251 May 30 23:26 temps</code></pre>
Similarly, some Lisps (like Scheme48 IIRC) use a comma to begin REPL commands (as distinct from Lisp forms) because commas outside of quasiquotation forms are otherwise syntax errors.
I don't really understand the problem it solves. can't you just put your own bin directory first in the PATH?<p>I do like the idea of autocompleting your own commands though.
I'm curious how folks manage their important local configurations, e.g.<p>- is your ~/bin directory a git repo?<p>- if you git to manage your dot files, do you use hard links or soft links?
Ah! I called them comma-commands <a href="https://wiki.roshangeorge.dev/index.php/Comma_command" rel="nofollow">https://wiki.roshangeorge.dev/index.php/Comma_command</a> and I was wondering what the source material was. Now I know!<p>I feel like these small web people's blogs were so much more accessible before link aggregators got this mainstream.
I’ve used this method for a while now, not sure if it’s from this particular article or if someone else blogged the same idea. I also prefix any aliases or sh functions from my rc file with a comma. Mostly it gets me easy to find custom commands when I “forget what I called that one alias”.
I use different namespaces for different convenience scripts, and use the notation [character].[command] for all of them.<p>I've used a character for each company I've worked for, and a different one for common scripts. This way is very easy to clean $HOME when I move.
> The lower-case letters are the very characters used in system commands; brackets, backslashes, the colon, the back-tick, and the single-tick all had a special meaning to the shell<p>Please note that brackets have no special meaning to the shell.
I like it I think. I'd probably be more inclined to add the comma to the end, that way tabbing on "mount" would bring up "mount and mount," which is your personal one.
Thought this was going to be about Comma [0]<p>0: <a href="https://github.com/nix-community/comma">https://github.com/nix-community/comma</a>
I dislike this immensely. It costs nothing to type "~/bin" in front of the command each and every time. And it means I can put comma's wherever I want in some commands that use them, like SQL ..<p>I do, however, like to comment my custom commands:<p><pre><code> $ mv ~/Desktop/*pdf ~/Documents/PDF # pdfsync
$ for i in ~/Documents/Development/JUCE/JUCE_Projects/* ; do ; cowsay $i ; cd $i ; git pull ; git fetch --all ; git submodule update --init --recursive ; done # updatejuce
</code></pre>
CTRL-R "updatejuce" or "pdfsync" .. and off we go ..<p>A much nicer way of finding my custom commands ..