
Start all of your commands with a comma (2009) - Tomte
https://rhodesmill.org/brandon/2009/commands-with-comma/
======
samatman
This is clever given what we have, but it seems like the wrong solution to the
problem.

I already have a PATH order. What would be nice is if typing say `sc` gave me
the first `sc` program, but typing `,sc` gave me the one after that.

This would generalize, so if I were stuck with _cough_ several pythons I could
call them with `python`, `,python`, `,,python` and so forth.

This would be a shell-level patch but surely not an impossible one.

Ironically, the one person whose workflow this would clobber is the one who
wrote this blog post!

~~~
heavenlyblue
Your solution requires shell support and is incompatible with previous code,
while the author’s solution works today.

Who has the wrong solution now?

~~~
rdlw
Software can be bad.

------
JulianWasTaken
Seemingly this is just as a cheap version of namespacing or something in the
event something comes out that uses the same name as a name you chose, rather
than actually being about "overriding"?

Because otherwise why not just do what I assume everyone else does, and put
~/bin _before_ everything else on your PATH?

~~~
function_seven
It’s to avoid collisions altogether, not to prioritize the custom commands
over the standard ones.

For example, let’s say I have a script that improves upon the systemctl
command, and I want to use it all the time and not type a bunch of characters
to invoke it. I might call it “sc”, forgetting that I also use the spreadsheet
calculator sometimes.

If I always prefix, then “,sc” is my shortcut, and “sc” is the spreadsheet
calculator.

~~~
kazinator
There isn't just the risk of a name clash between programs that you use. It's
a hygiene problem: a clash that you don't know about, involving some program
you don't use (or not directly).

The system programs can potentially rely on each other, invoking each other in
a way that relies on PATH searching, and not set PATH to a sane value when
they are invoked. Your utility can accidentally shadow something and break the
program whicc relies on it.

In other words, setting PATH to point to ~/bin first breaks unhygienic
programs which blindly inherit PATH --- which is pretty much all non-setuid
programs in a Unix-like system!

Setting PATH to point to your ~/bin last, on the other and, potentially breaks
_your_ programs when they call each other (in a way that relies on path
searching), and are shadowed by new system programs. A fix for that is to to
put ~/bin last, and ensure that all your programs refer to each other in a way
that doesn't rely on PATH. E.g. _prog_ is invoked as _$bob_utils /prog_.

------
kazinator
According to POSIX, variables that contain lower-case letters are for
application use. If Debian (or whoever) introduces such variable names, they
are being nonconforming.

For instance, my programs might be in /home/kaz/bin. Suppose I create a one-
letter variable:

    
    
      k=/home/kaz/bin
    

Then /home/kaz/bin/foo can be run as

    
    
      $k/foo
    

Bash will complete on this. Firstly, $k[Tab] will add the missing slash to
make $k/. Then if Tab is hit twice, the completions under /home/kaz/bin are
shown.

Since k contains an absolute path, it does not rely on PATH searching.

The programs under $k/ can refer to each other using the $k/ notation, without
relying on PATH.

The comma notation relies on PATH. When the ,foo script wants to invoke the
,bar script and just calls it ,bar args ... that relies on PATH containing the
directory in which ,bar lives.

For interactive use, I'd use PATH anyway: put /home/kaz/bin _at the end_. Then
if the system shadows one of my programs _prog_ , I can just use ~/utils/prog
or $k/prog to detour around the clashing system program. My programs
themselves don't rely on PATH for calling each other, so they are immune to
the shadowing, and since I added the new PATH element at the end, I haven't
perpetrated any shadowing that would break system programs.

~~~
aliveupstairs
If you are using absolute paths, I found this easier to get used to:

    
    
        hash -d b=/home/me/bin
    

Then you call foo as:

    
    
        ~b/foo
    

I have an array of these defined to my most used directories.

~~~
mineo
I believe hash -d and supsequent expansion of those paths only works in ZSH,
which calls this "static named directories"
([http://zsh.sourceforge.net/Doc/Release/Expansion.html#Static...](http://zsh.sourceforge.net/Doc/Release/Expansion.html#Static-
named-directories)).

------
bitwize
Many Lisp REPLs require you to prefix REPL metacommands with a comma. This
helps distinguish between metacommands and variables to be evaluated, because
the comma is the unquote operator to the Lisp reader, and is unlikely to occur
in a Lisp expression outside a quasiquoted sexpr.

------
JadeNB
This is a great idea. I would have assumed by default, with no particular
reason, that tools would choke at least on file names starting with, if not
all of those containing, a comma, but a quick test with a few basic bash tools
shows no issue.

I wonder (having never really grokked the latter) if it's productive to think
of this as akin to a leader key in vim ….

------
rwmj
> Red Hat never really worried me, because they packaged (comparatively) so
> little software.

Erm, nope:

    
    
        $ dnf repoquery -l $(dnf repoquery -f /usr/bin/\*) | grep ^/usr/bin | wc -l
        34989

~~~
mwcampbell
I think the OP meant in comparison to Debian. Official Red Hat repositories
have been way smaller than the official Debian repositories for as long as I
can remember, back to the 90s. I know Fedora has a lot more packages though.

~~~
rwmj
That's hardly a fair comparison, unless you can call up Debian on the phone
and get 4 hour support for any of those binaries. Back in reality Fedora is
the closest analog to Debian.

~~~
mwcampbell
Touché. I didn't actually point out the difference as a point in favor of
Debian; I can see the advantages of both approaches.

------
narsil
The author has helpfully open-sourced the scripts as well, some of which are
quite helpful like this one to convert dates to unix time and back:
[https://github.com/brandon-
rhodes/homedir/blob/master/bin/%2...](https://github.com/brandon-
rhodes/homedir/blob/master/bin/%2Cdate)

Agree with the commit message; I've probably spent way too much time the past
decade firing up a python prompt or using an online epoch converter to do
this.

~~~
Hello71

      date -d @$1 +%Y-%m-%d

~~~
danappelxx
$ date -R Gets you very close with fewer characters

~~~
Hello71
I mean, if you're not fixed on the output format, then date +%c.

------
fit2rule
How is this ugliness a solution? How about just name the binaries properly -
I'd rather just prefix my commands with ~/bin.me/<blah> and keep ~/bin out of
my PATH, than futz with horrid looking names. Or, even better, just put my
username in front of it .. "fit2rule_grep" ..

------
leni536
Some time ago I wrote a simple tool to implement directory history in bash.
Unfortunately I couldn't use 'cd<' and 'cd>' for obvious reasons, so I used
'cd^' and 'cd,' instead.

~~~
dan-robertson
But bash already has pushd and popd

~~~
leni536
Umm, I wasn't aware.

------
Gys
> And, best of all, thanks to the magic of tab-completion, it became very easy
> to browse my entire collection of commands.

This. I always forget the names of all these useful tools that I only use now
and then.

~~~
yiyus
What's wrong with ls ~/bin?

~~~
makapuf
Two keystrokes vs 9 (using shift with some keyboard layouts). Also,
interaction with zsh or fish is better.

------
unnouinceput
Brrrr, such an ugly solution. If you want proof against future then you should
use longer naming, maybe something that ends in <First name initial, Last name
initial, Middle name initial, Underscore, my>. Allows to get better
implementations of existing ones and having a fixed schema can help you in the
future as your personal tools library grows.

Examples:

cat -> cat_uni_my (personal implementation of standard cat)

grep -> grep_uni_my (personal implementation of standard grep)

~~~
jon889
That’s not really easier to type though :)

~~~
unnouinceput
maybe, but it's a lot easier to understand if you share your tools with other
people. As for personal use, sure, you can do whatever you want, including
using his comma style naming.

------
malkia
That's weird, because I use comma every time I type something in my shell (on
Windows, not cmd.exe, but FAR). Why? In order to make sure that builtin
",time" is called, not "time.exe", because FAR Manager would try to run the
executable under the PATH, instead of the command.

~~~
jakub_g
FYI in bash there's somehow similar `command` built-in.

Say you have an alias that overrides `ls`. When you want to run original ls,
you run `command ls`.

~~~
dredmorbius
Or, you know, fully-specified path:

    
    
        /bin/ls

~~~
jakub_g
When you override a bash built-in like `cd` with an alias, `command` is the
only option.

~~~
dredmorbius
Fair point.

Is there an alternate mechanism for invoking a shell's built-ins externally?
Obviously for state-changing operations such as 'cd' that's of limited use.

    
    
       $SHELL -c '<commands>'
    

Comes to mind. Though likely bypassing initialisations might be useful.

------
ajuc
BTW I've long wanted to do sth like this:

Assume I have commands my_cat, my_grep, my_sort, my_send, and I want to use
them in a pipe

with_prefix my_ | cat file | grep phrase | sort | send | end_with | cat

The last cat would be the system one.

I don't think it's possible with bash?

~~~
Crestwave
> I don't think it's possible with bash?

No, pipes don't work like that. The closest I can think of is something like
`(PATH=~/bin; cat file | grep phrase | sort | send) | cat`, where the custom
commands don't have a prefix.

------
vordoo
TL;DR Prefixing your custom commands/scripts with a comma, in order to avoid
collision with present or future system commands.

Been doing it for years with a jj prefix instead, it is just under my index
finger on the home row :-)

~~~
amelius
Typing jj+tab gives me:

    
    
        jjdoc   jjs     jjtree
    

on Ubuntu 18.04

------
every
I just name all my shell scripts in all-caps. Nary a collision...

~~~
saagarjha
I hope you don't use APFS…

~~~
patrec
APFS can handle FOO and foo just fine, and I think only on macOS do you have
to ask nicely that you'd like to have them not conflict, iOS and watchOS
already do that by default. I have observed no problems with running a fully
case sensitive macOS install.

~~~
saagarjha
Interesting! I seem to recall that not all to long ago a lot of things would
completely break if you tried to use a case-sensitive filesystem.

~~~
patrec
I think Adobe or other entrenched bloatware might still break, but I had zero
problems with it so far and I use a reasonable range of applications.

------
lazyjones
On my International English Magic Keyboard I'd use § for convenience though.
Neat idea, works with aliases too.

~~~
viburnum
I’d never heard of that keyboard before. Is this something that’s handy for
programming because it had extra keys?

~~~
lazyjones
No, I just chose it over US English for the L-shaped Enter key and over UK
English because # was easier to access. You can see the layout differences
here:

[https://www.apple.com/uk/shop/product/MLA22B/A/magic-
keyboar...](https://www.apple.com/uk/shop/product/MLA22B/A/magic-keyboard-
british-english)

------
Seirdy
Although this seems like a good idea, I wouldn't like typing an extra symbol.
Maybe I'm just irrational.

Instead of prefixing my commands, I just search for a command in a manpage
repo, cht.sh [0], and with my package manager (`dnf provides` for the DNF
package manager). If nothing shows up, I'm probably safe. The process is easy
to automate.

~~~
feifan
Typing a comma is too hard, but that 4-step jerry-rig isn't?

~~~
swimfar
He does that check once, when he's deciding on what to name it, not every time
he runs the command.

~~~
Seirdy
This, plus I also said "Maybe I'm just irrational".

------
20after4
the dash character would also work.

    
    
      ▷ echo 'echo "this is a -test"' > ~/bin/-test
      ▷ chmod +x ~/bin/-test
      ▷ -test
      this is a -test

------
jdxcode
Why not just use shell aliases?

~~~
kazinator
They are not real system commands; they can't be exec-ed.

------
gerdesj
"Like many Unix users, I long ago created a ~/bin/ directory in my home
directory"

No, this is my laptop - /usr/bin is the place for that. No, this is a simple
server - /usr/bin is the place for that.

Perhaps I'm missing something after 23 odd years of using Unix systems
including this Arch laptop.

~~~
Macha
/usr/bin is under the control of your package manager _ unless you're building
and installing packages for all your adhoc scripts, aren't you worried about
name collisions?

~~~
yissp
I know Arch's package manager, at least, will refuse to install a package if
it would overwrite an existing file.

