on windows the default git package (ie. git bash) installs a bash terminal that has the git PS1 enabled.

> Git does not install anything.

It's literally a Git installer.

Can you explain? A shell isn't supposed to be installing things on it's own... (Assuming you're talking about zsh or bash when you say shell.)

It's not doing it on it's own, I believe what they're referring to is a a pre-configured distribution of a shell packaged with some distributions of Git, for some OSes.

There's a lot of different ways to install Git on a lot of different OSes, and some of them put helper shell scripts down by default.

That isn't Git installing things though, that is third-party Git distributions bundling things along with Git.

I'm aware, which is why I phrased it like I did. A lot of folks don't know or understand the distinction when they're installing Git (or installing something else that happens to bring Git with it).

The overarching point is that the shell itself is not installing anything at shell runtime. E.g. it's the Git Bash installer, not opening `bash`.

Yeah, even zsh doesn't do this by default

Can you say what Linux distro does this? Seems like very poor taste for a command shell to be assuming one particular SCM.

On Ubuntu, and I presume therefore many debian derivatives and debian itself, `apt get git` will install a file called `/usr/lib/git-core/git-sh-prompt` (dpkg -S /usr/lib/git-core/git-sh-prompt).

This script allows you to see repository status in your prompt. It comes with 5 utility functions that AFAIKS are usable in all common shells:

    __git_ps1_show_upstream ()
    __git_ps1_colorize_gitstring ()
    __git_eread ()
    __git_sequencer_status ()
    __git_ps1 () 

On Ubuntu those aren't installed into bash by default, but you need to add it yourself to your ~/.bashrc (or zsh or whatever, but those aren't the default in Ubuntu). The mechanisms aren't in place for a package to inject itself into your prompt, but it isn't unthinkable (though maybe unwanted) to have that. Similar to how tab-complete for bash is handled:

The `git` package installs a file `/usr/share/bash-completion/completions/git` which is picked up by bash, on Ubuntu, as a pluggable way to extend autocomplete on bash. Many packages do this, on my machine there's 960 files in there (ls -1 /usr/share/bash-completion/completions/ | wc -l).¹ It would be trivial to have a similar mechanism for `bash_rc.d` which allows for a pluggable system to extend and modify your bash. Again, I presume this to be unwanted. I would oppose it.

¹ This is why I was surprised to learn that people like zsh for the reason that it offers tab-completion: I always presumed bash did that out of the box for any installed package already. Turns out it is Ubuntu (or better: Debian) doing this for me.

> It would be trivial to have a similar mechanism for `bash_rc.d` which allows for a pluggable system to extend and modify your bash.

There is /etc/profile.d/ which serves much the same purpose for login shells, though PS1 is normally a non-exported shell variable so it wouldn't be inherited. You can configure most other aspects of the shell this way, however. And there is also /etc/bash.bashrc which is read before ~/.bashrc, though it doesn't provide a convenient directory for drop-in scripts by default the way /etc/profile does. It would be trivial to add that if desired. (All based on Debian; YMMV.)

This feels like tab completion is a more serious attack vector then?

Anything installed through `apt` could be an attack vector, but that is silly, really.

If we start treating "apt get will install software that can change my system" as a security issue, we should stop using all electronic devises right now.

And yea: I know, we should have sandboxing, isolation, chroot and whatnot. And we are heading there. Yet in 2022, the vast majority of computers, servers and such are installed using package managers which install packages that have access to all the system. If you count mobile devises amongst "computers" then I guess a majority (Android) does have sandboxing in packages, which solves this particular issue.

You need to be root to add a file to the basl completions directory, so not really.

There is no the bash completion directory; there is a default one which happens to be system wide and only root writable (as should be the case in a combination of such circumstances).

Fish allows for custom ones in ~/.config/fish and there is zero reason you cannot install custom ones in ~/.bashrc or user writable (on macOS) /usr/local

Command shells assume a lot of things, such as your preferred text editor, locale, input and output devices, etc. Most of these things can be configured, but the default install makes assumptions based on common configurations.

The shell doesn't assume a particular one, but if it's in a directory where a supported one is present, then it enables those extras.