I must say, I think that’s a terrible name for a tool. No software intended for wide distribution should use single character binary names, those should be reserved for end-users to use for shell aliases and the like.
I’d be inclined to agree in principal, but can’t help but feel that this presents fantastic UX to the user. If I ever implemented an equivalent in Guix, it’d likely use the ',' character too, shortening 'guix shell firefox -- firefox' to just ', firefox'. 70% shorter, at the cost of an intentional collision in violation of rational principles. Namespacing these (even just to ,nix and ,guix) quickly cuts into the efficiency and elegance of the shortcut, highlighting a lack of support in the shell for some form of modality.
Perhaps flags preceding commands could apply broad modes to that invocation, like '-, firefox' or '-C firefox' to containerize it. It feels appropriate (to me) to have some modal keybinds, a la Vim or (more so) Emacs prefixes, which might work in the context of an application runner like dmenu or Rofi, but presents it’s own challenges on the command line in regards to pipes (which otherwise work with 'guix shell ...', and presumably with comma).
Which is all to say I agree, and that perhaps allowing the user to establish the shell alias to ',' themselves is the best design we have right now, but there’s an unaddressed design space for broadly-applicable per-invocation command-line switches.
This is useful and clever. I’ve been bitten by namespace collisions, so
I tend to give my own commands more verbose names. Sometimes I start
them with cmb- (my initials). I have cmb-html2txt for instance, because
there are quite a few things out there calling themselves html2txt. The
comma convention appeals. I’m adopting it.
My only concern with using anything except letters / numbers and underscore / hyphen in tool names is how badly it will interact with other tooling that make assumptions about what a “proper” executable name should be. For example I would expect some build tools (although perhaps not make or ninja, but others) to assume that a comma is a separator and treat that name as a list, especially when combined with string splicing and formatting.
My own approach is to prefix all my tools with x- (especially those that should work under Xorg) or z- (those that are more elaborated), or suffixing them with -w (from “wrapper”) for those that just provide some simplifications over existing tools. Meanwhile for bash aliases or functions I use _ as a prefix (after I clear all other aliases).
Perhaps either the FreeDesktop organization (the one in charge of XDG standards), or any other organization recognized in the Linux / BSD ecosystem, should just come with some guidelines about “private namespaces” with regard to tool naming, just like we used to have X-Whatever in the HTTP world.
I read this yesterday and wrote a new shell command later the same evening. Today I tried that command and my laptop subsequently froze after a few minutes.
I use a similar system where I start project-specific commands with a period (e.g. .start will always start up the development server and use the right command depending on the project). I turbo-charge this approach with bash-ctx. For example, in a Rails project I may define aliases such as:
alias .bundle="bundle3.1"
alias .exec=".bundle exec"
alias .rubocop=".exec rubocop"
alias .rails=".exec rails"
alias .test=".rails test"
alias .test.system=".rails test:system"
alias .console=".rails console"
function .routes() {
if [[ $# -eq 0 ]]; then
.rails routes
else
.rails routes | grep $@
fi
}
alias .migrate=".rails db:migrate"
It’s a huge productivity boost that helps me focus on the task at hand instead of trying to guess which version of Ruby/Bundler/Rails/etc. a given project is using.
You are the author of bash-ctx, right? At a glance it looks quite similar to https://direnv.net/ , is that correct or are there additional features or differences that I am missing?
what about placing your own folder before the built-in path in the $PATH variable… that should prevent the system bundled command from shadowing your own, right?
what about placing your own folder before the built-in path in the $PATH
variable… that should prevent the system bundled command from
shadowing your own, right?
This enforces an order of precedence and prevents shadowing, but that’s
not quite sufficient for preventing harm from a namespace collision.
Here’s a real-world example. I use a program called edbrowse. While it
is based on the venerable /bin/ed, it is not a drop-in replacement for
that program.
So about 15 years ago, I made the mistake of symlinking /usr/local/bin/ed to
edbrowse, to save some typing. I was using Gentoo at the time. During
a package upgrade, my package manager printed a bunch of nonsense. I
don’t recall what it was exactly. After looking through ps I found the
culprit. The package manager was using an ed script to patch a
file. However, my ed wasn’t the one it was expecting…
The moral of the story is that it’s better to just prevent namespace
collisions outright, rather than rely on a precedence order.
I do this with aliases that shadow system commands. Aliases always come first in interactive shell sessions but are not present when scripting or to other tools on the system. E.g. vim ⇒ nvim, ls ⇒ exa, fmt ⇒ cargo fmt, top ⇒ zenith, tar ⇒ bsdtar. If ed was aliased to edbrowse then there would have been no issue.
There’s a tool named ‘,’ in the nix community https://github.com/nix-community/comma ;)
I must say, I think that’s a terrible name for a tool. No software intended for wide distribution should use single character binary names, those should be reserved for end-users to use for shell aliases and the like.
I guess you are unfamiliar with /usr/bin/[ then. I think it’s been around since the 80s (maybe earlier).
I am familiar with it.
Do I think it’s great engineering? No, not really. Do I accept its existence? Yes, of course.
Things that are old enough get a pass on modern sensibilities.
I’d agree in general, but in this case it’s quite a niche product and in the end it’s the user who’s deciding what to install (under which name)
I’d be inclined to agree in principal, but can’t help but feel that this presents fantastic UX to the user. If I ever implemented an equivalent in Guix, it’d likely use the
','character too, shortening'guix shell firefox -- firefox'to just', firefox'. 70% shorter, at the cost of an intentional collision in violation of rational principles. Namespacing these (even just to,nixand,guix) quickly cuts into the efficiency and elegance of the shortcut, highlighting a lack of support in the shell for some form of modality.Perhaps flags preceding commands could apply broad modes to that invocation, like
'-, firefox'or'-C firefox'to containerize it. It feels appropriate (to me) to have some modal keybinds, a la Vim or (more so) Emacs prefixes, which might work in the context of an application runner like dmenu or Rofi, but presents it’s own challenges on the command line in regards to pipes (which otherwise work with'guix shell ...', and presumably with comma).Which is all to say I agree, and that perhaps allowing the user to establish the shell alias to
','themselves is the best design we have right now, but there’s an unaddressed design space for broadly-applicable per-invocation command-line switches.This is useful and clever. I’ve been bitten by namespace collisions, so I tend to give my own commands more verbose names. Sometimes I start them with cmb- (my initials). I have cmb-html2txt for instance, because there are quite a few things out there calling themselves html2txt. The comma convention appeals. I’m adopting it.
My only concern with using anything except letters / numbers and underscore / hyphen in tool names is how badly it will interact with other tooling that make assumptions about what a “proper” executable name should be. For example I would expect some build tools (although perhaps not
makeorninja, but others) to assume that a comma is a separator and treat that name as a list, especially when combined with string splicing and formatting.My own approach is to prefix all my tools with
x-(especially those that should work under Xorg) orz-(those that are more elaborated), or suffixing them with-w(from “wrapper”) for those that just provide some simplifications over existing tools. Meanwhile forbashaliases or functions I use_as a prefix (after I clear all other aliases).Perhaps either the FreeDesktop organization (the one in charge of XDG standards), or any other organization recognized in the Linux / BSD ecosystem, should just come with some guidelines about “private namespaces” with regard to tool naming, just like we used to have
X-Whateverin the HTTP world.I read this yesterday and wrote a new shell command later the same evening. Today I tried that command and my laptop subsequently froze after a few minutes.
You can probably guess the issue and how adding a comma to it would have helped :)
Took me a sec… oh no
Been using Linux for 10+ years. Still can’t avoid that semi-annual fork bomb from time to time
I use a similar system where I start project-specific commands with a period (e.g.
.startwill always start up the development server and use the right command depending on the project). I turbo-charge this approach with bash-ctx. For example, in a Rails project I may define aliases such as:It’s a huge productivity boost that helps me focus on the task at hand instead of trying to guess which version of Ruby/Bundler/Rails/etc. a given project is using.
You are the author of bash-ctx, right? At a glance it looks quite similar to https://direnv.net/ , is that correct or are there additional features or differences that I am missing?
Yes, I’m the author of bash-ctx.
I haven’t seed direnv before. Thank you for bringing it up. A cursory look indicates direnv differs slightly, i.e.:
For me, this is a big deal because aliases and functions are 90% of what I use bash-ctx for.
see also this long-standing direnv issue https://github.com/direnv/direnv/issues/73
what about placing your own folder before the built-in path in the $PATH variable… that should prevent the system bundled command from shadowing your own, right?
This enforces an order of precedence and prevents shadowing, but that’s not quite sufficient for preventing harm from a namespace collision.
Here’s a real-world example. I use a program called edbrowse. While it is based on the venerable /bin/ed, it is not a drop-in replacement for that program.
So about 15 years ago, I made the mistake of symlinking /usr/local/bin/ed to edbrowse, to save some typing. I was using Gentoo at the time. During a package upgrade, my package manager printed a bunch of nonsense. I don’t recall what it was exactly. After looking through ps I found the culprit. The package manager was using an ed script to patch a file. However, my ed wasn’t the one it was expecting…
The moral of the story is that it’s better to just prevent namespace collisions outright, rather than rely on a precedence order.
I do this with aliases that shadow system commands. Aliases always come first in interactive shell sessions but are not present when scripting or to other tools on the system. E.g.
vim⇒nvim,ls⇒exa,fmt⇒cargo fmt,top⇒zenith,tar⇒bsdtar. Ifedwas aliased toedbrowsethen there would have been no issue.I was more dull than that. Prepending some of my commands with
my-This is neat, totally gonna snatch this one!