4 ms·

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

dotancohen 5y ago
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.
berkes 5y ago
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.
- leni536 5y ago
  This feels like tab completion is a more serious attack vector then?
  - dahfizz 5y ago
    You need to be root to add a file to the basl completions directory, so not really.
    - Fnoord 5y ago
      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
  - berkes 5y ago
    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.
- nybble41 5y ago
  > 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.)
fragmede 5y ago
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.

dotancohen 5y ago

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.

berkes 5y ago

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.

leni536 5y ago
This feels like tab completion is a more serious attack vector then?
- dahfizz 5y ago
  You need to be root to add a file to the basl completions directory, so not really.
  - Fnoord 5y ago
    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
- berkes 5y ago
  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.
nybble41 5y ago
> 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.)

fragmede 5y ago

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.