Apple. Apple Please

The default shell on debian autocompletes git commands and things like branch names pretty robustly for me, so somebody figured it out.

That works in similar ways as posh-git ( https://github.com/dahlbyk/posh-git ) - the tooling for Powershell to be able to be able to do things with git.

This has a fair bit of code that goes in and examines the .git directory when present.

Additionally, the shell has been programed to be aware of the git sub commands.

But is it aware of... say... svn sub commands? The same amount of effort would be need to be done to have bash aware of .svn and its sub commands.

This is special tooling written for one suite of commands.

It doesn't work for arbitrary commands or arbitrary data structures. Even well known ones.

    tar -zxvf  {specific file}

That doesn't do tab expansion for the specific files that are within the tar file. Nor does doing --f show the expansion options for --file --format --fflags

Someone wrote special case tooling for one shell for one command named git.

I just looked it up and for zsh (MacOS default) it’s Ctrl+_

Hopefully I’ll remember that next time I need it.

PS: not saying reusing a flag is a good idea, but like, macOS is not Linux, it’s Unix, and mostly it’s the exact same differences on FreeBSD or illumos or openbsd, because the syntax comes from AT&T Research Unix in the 1970s (the oldest known code in FreeBSD is around 1979 iirc, and there is a direct lineage back to sys-v). Obviously it’s a little different, but on the flip side this is how you avoid churn - you don’t change things just for change’s sake, and you fit into the existing style even if you don’t like it.

From the BSD perspective it’s like you’re coming in and shouting about rewriting everything in rust on your first day, especially since BSD does place a much higher emphasis on interface stability etc. For example unlike linux, BSD offers ABI stability, and that is one of the selling points for building something on top of it. Nor is there any systemd or upstart - or a million different directories and styles for conf files. rc.conf basically does almost everything you need for OS conf.

One net benefit is that it’s actually possible to write and maintain documentation, and it doesn’t bitrot in every single major release. Those FreeBSD forum posts from 2007 are still valid. And if you need to build some appliance that will be running unattended for years… BSD doesn’t churn like that.

But the price is you have to learn new syntax (really, the old syntax) for a half dozen system commands. Or just install the gnu version of those packages (“brew/portmaster install findutils gtar greputils” mostly covers it). It’s pretty much the first speedbump everyone hits on their first Unix, and it’s ultimately a trivial one, but yeah, there’s no desire or real reason to churn it either.

It’s the bazaar vs the cathedral, and the cathedral has some advantages too. You’d say code smell, I’d say fine patina. A lot of Unix code has had 30 or 40 years to work out the bugs and edge-cases in a controlled manner. It’s not worth losing that so newbies can have a little easier time their first week. Use gnu versions if there’s a pain point.

> This could be more accurately phrased as Linux

I do agree and acknowledge the point. But yes, I do find it frustrating that there are such differences in core utils. I guess the frustration is more about not working harder to find consistency. I many of the man pages it is not uncommon to find flags and options that exist simply for historical reasons. But many of the frustrating points are addressable in similar ways. An example might be with `du`. The OSX implementation has no `--max-depth` flag, despite `-d` being supported. Unless I am missing something, there is no downside to incorporating the long version of the flag. I can understand some other choices, but even `grep` is different enough.

> I'm not sure what your noise cancellation point is, because that works absolutely fine here between myself and everyone else I know.

In part, this is my point. Finding where generalization fails is non-obvious and non-homogeneous. So when it fails, it typically fails in a sub class of problems. These are of far more concern than edge cases[0]. Generalization is VERY hard. It is why dogfooding is so important as well as listening to the userbase. Because it helps you identify where you're lacking.

And maybe I caused confusion by my choice of words, thinking it would be simpler and context would clarify. I specifically mean sound isolation when speaking. As in she can ride the train, call me, and hear me perfectly fine (that side is working as expected). But what sound is being sent to me is not her voice (this is clearly suppressed as it has that same format as what background noise often sounds like), but the train itself. And worse, the train is amplified. So there is a identification in what is noise and what is speech. It may help to specify that this is happening when she is not in America. There are no issues with Bart, and that should tell us quite a lot. (I'll also add that augmentation is one of my niches as a researcher)

[0] The common approach to this is by using more data. Crude, but effective. Though it can exacerbate your issues if you don't expand the distribution you sample from, since you'll just reinforce your local density.