6 ms·

If people don't even know what those commands mean, why are they even presented as a step? The installer could do both things for them.

jandrese 5y ago
I guess people get touchy when you start editing their startup scripts? I agree that it would be pretty easy for the installer to check and add the lines if they are missing.
- MereInterest 5y ago
  > I guess people get touchy when you start editing their startup scripts? I'm definitely one of those people. The startup script is my personal configuration, under source control and managed to set up an environment exactly how I want it. The very first thing I do on a new computer is clone that repo, so that I have my standard working environment available. It's definitely not a dumping ground for anything that has just been installed. > I agree that it would be pretty easy for the installer to check and add the lines if they are missing. But this is where it gets difficult, because that's in no way an easy thing to check. My .bashrc sources a .bashrc_local, so that I can have some computer-specific settings. It has conditionals, based on what tools are available on the current machine. Heck, some of the commands are generated by a python script, such as coloring the PS1 pseudorandomly based on the hostname, so I can tell at a glance which computer I'm ssh'ed into. (Side note, I definitely need to clean it out at some point, as it has definitely accumulated a lot of cruft over the years.) Determining if a particular script is sourced requires solving the halting problem. Granted, doing a quick grep for the name of the setup script is probably sufficient, but an installer shouldn't be editing my setup script even if it doesn't find anything.
  - pjerem 5y ago
    At least it could ask if you want it to add it for you. I’d answer yes, you’ll answer no and everybody would be happy.
  - comex 5y ago
    Definitely not without asking. But I think giving a yes/no prompt for whether to add the line is reasonable. One counter-argument might be that if the user doesn’t add it themselves, they’re less likely to remember where it is so they can remove it if needed. However, Homebrew already gives you a command to add it that you can blindly copy and paste, which is already not going to stimulate memory very much. I don’t think the script doing it automatically is any worse, as long as it makes sure to explain what it’s doing – that is, display the line it’s adding and the path it’s adding it to.
- chillpenguin 5y ago
  Yes exactly, I really do not like it when programs edit my bashrc/zshrc. I will admit though that the PATH stuff was confusing when I was first starting out with programming. But now that I'm a unix nerd, I much prefer to have more control and set things up exactly how I like.
- rwmj 5y ago
  If you remember the total trashfire that was config.sys/autoexec.bat on DOS, I really hope installers do not start editing startup scripts.
seneca 5y ago
> If people don't even know what those commands mean, why are they even presented as a step? The installer could do both things for them. No, installers should not be automatically modifying your profile or your PATH. That would be overstepping significantly, and violating the expectations of most users.
- Spivak 5y ago
  It shouldn’t be modifying your dotfiles but I think there’s a good case it should drop a file in /etc/paths.d.
- dylan604 5y ago
  This is clearly not accepted as gospel, as there are plenty of times my PATH has been updated to PATH=$PATH:/some/new/thing/just/installed I know mercurial and other packages of type have done this to me
  - FeepingCreature 5y ago
    To be fair, PATH can be edited via /etc/profile.d/ in a relatively clean, reversible way. Packages should definitely never patch your .bashrc though.
    - dylan604 5y ago
      I would much rather a program modify something in the /home/user folder than anything in /etc. .aliases .exports .paths????
      - bipson 5y ago
        Aehm, no? After all, this is my "home", quite literally.
        dylan604 5y ago
        Yes, but what you do in your home should not affect what goes on in my home.
brendanfalk 5y ago
Completely agree. There is a tradeoff between letting user do everything themselves such that they know exactly what's happening in their system vs just doing it for them and making sure they don't make a mistake. Perhaps a better implementation would be a choice: You need too add `eval "$(/bin/brew shellenv)"` to your dotfiles. Would you like us to do this for you? 1. Yes 2. No I will do this myself
- SAI_Peregrinus 5y ago
  > There is a tradeoff between letting user do everything themselves such that they know exactly what's happening in their system That makes the (IMO false) assumption that people doing things for themselves by following instructions tend to learn what those things do, rather than simply remembering a "magic" ritual that made something work. Some people will take the time to study and learn how the various commands work and the syntax of different shell & scripting languages. Most won't.
nixpulvis 5y ago
Don't fucking edit my bash profile.
- kyleee 5y ago
  Maybe with consent I guess; IIRC fzf asks if you want to append a couple config lines to bash config which seems sensible
  - portpecos 5y ago
    I like this. Give me the option to hit yes or no.
- bmn__ 5y ago
  Why don't we have a `~/.config/bash.d/` directory whose files are automatically sourced? That they there is no need for installers to step on the toes of a central profile, they would just add a file to the directory which also is easily and safely undone.
  - Jakob 5y ago
    That is /etc/paths.d/ on macos.
    - corpMaverick 5y ago
      I think the parent comment wants the files per user no global.
hollerith 5y ago
I've been using Unix and Linux since 1992, and its only in the last 6 years or so that I've started to see an installer or any other program modify ~/.profile or ~/.bashrc. (This is one instance in which I wish the installers, etc, would keep to the tradition.) Linux distros usually have a mechanism that allows a package to modify a shell's environment without touching dot files that user is used to editing. On Fedora, /etc/profile sources all the .sh files in /etc/profile.d. So for example, installing the "snap" package write a file named /etc/profile.d/snap.sh, which contains this: # Expand $PATH to include the directory where snappy applications go. snap_bin_path="/var/lib/snapd/snap/bin" if [ -n "${PATH##*${snap_bin_path}}" ] && [ -n "${PATH##*${snap_bin_path}:*}" ]; then export PATH="$PATH:${snap_bin_path}" fi
- soneil 5y ago
  osx provides /etc/paths.d/ for this too, editing dotfiles isn't necessary. This one arguably makes sense though. Because it's being used to install separately from the OS (eg you can use brew on linux to provide a per-user package manager in $HOME), setting "my brew" system-wide might not be the sensible default. (But then, I can't remember the last time I saw a mac that was genuinely multi-user). I guess there's no one answer, but creating /etc/paths.d/homebrew might belong on the list of options.
- nerdponx 5y ago
  I use ~/.config/envrc.d and ~/.config/zshrc.d for this. The former is only run "on startup" and the latter is run for every interactive shell.
deleted 5y ago
[deleted]
caymanjim 5y ago
The installer should update the shell rc file (with a power user option to disable it), but it's not possible for it to do the second step and source it in the current shell. They could just tell you to restart your session, though.
YetAnotherNick 5y ago
Because the shell rc detection is not easy. Also the prompt is not correct in multi user environment. I guess brew has list of hardcoded paths(~/.zshrc for zsh ~/.bashrc for bash etc)
amazingman 5y ago
Modifying a user’s shell profile(s) is a step way too far for many (most?) people who work in their shell all day. If people don’t know what the commands mean, this can be solved with better/more context.

jandrese 5y ago

I guess people get touchy when you start editing their startup scripts? I agree that it would be pretty easy for the installer to check and add the lines if they are missing.

MereInterest 5y ago
> I guess people get touchy when you start editing their startup scripts? I'm definitely one of those people. The startup script is my personal configuration, under source control and managed to set up an environment exactly how I want it. The very first thing I do on a new computer is clone that repo, so that I have my standard working environment available. It's definitely not a dumping ground for anything that has just been installed. > I agree that it would be pretty easy for the installer to check and add the lines if they are missing. But this is where it gets difficult, because that's in no way an easy thing to check. My .bashrc sources a .bashrc_local, so that I can have some computer-specific settings. It has conditionals, based on what tools are available on the current machine. Heck, some of the commands are generated by a python script, such as coloring the PS1 pseudorandomly based on the hostname, so I can tell at a glance which computer I'm ssh'ed into. (Side note, I definitely need to clean it out at some point, as it has definitely accumulated a lot of cruft over the years.) Determining if a particular script is sourced requires solving the halting problem. Granted, doing a quick grep for the name of the setup script is probably sufficient, but an installer shouldn't be editing my setup script even if it doesn't find anything.
- pjerem 5y ago
  At least it could ask if you want it to add it for you. I’d answer yes, you’ll answer no and everybody would be happy.
- comex 5y ago
  Definitely not without asking. But I think giving a yes/no prompt for whether to add the line is reasonable. One counter-argument might be that if the user doesn’t add it themselves, they’re less likely to remember where it is so they can remove it if needed. However, Homebrew already gives you a command to add it that you can blindly copy and paste, which is already not going to stimulate memory very much. I don’t think the script doing it automatically is any worse, as long as it makes sure to explain what it’s doing – that is, display the line it’s adding and the path it’s adding it to.
chillpenguin 5y ago
Yes exactly, I really do not like it when programs edit my bashrc/zshrc. I will admit though that the PATH stuff was confusing when I was first starting out with programming. But now that I'm a unix nerd, I much prefer to have more control and set things up exactly how I like.
rwmj 5y ago
If you remember the total trashfire that was config.sys/autoexec.bat on DOS, I really hope installers do not start editing startup scripts.

seneca 5y ago

> If people don't even know what those commands mean, why are they even presented as a step? The installer could do both things for them. No, installers should not be automatically modifying your profile or your PATH. That would be overstepping significantly, and violating the expectations of most users.

Spivak 5y ago
It shouldn’t be modifying your dotfiles but I think there’s a good case it should drop a file in /etc/paths.d.
dylan604 5y ago
This is clearly not accepted as gospel, as there are plenty of times my PATH has been updated to PATH=$PATH:/some/new/thing/just/installed I know mercurial and other packages of type have done this to me
- FeepingCreature 5y ago
  To be fair, PATH can be edited via /etc/profile.d/ in a relatively clean, reversible way. Packages should definitely never patch your .bashrc though.
  - dylan604 5y ago
    I would much rather a program modify something in the /home/user folder than anything in /etc. .aliases .exports .paths????
    - bipson 5y ago
      Aehm, no? After all, this is my "home", quite literally.
      - dylan604 5y ago
        Yes, but what you do in your home should not affect what goes on in my home.

brendanfalk 5y ago

Completely agree. There is a tradeoff between letting user do everything themselves such that they know exactly what's happening in their system vs just doing it for them and making sure they don't make a mistake. Perhaps a better implementation would be a choice: You need too add `eval "$(/bin/brew shellenv)"` to your dotfiles. Would you like us to do this for you? 1. Yes 2. No I will do this myself

SAI_Peregrinus 5y ago
> There is a tradeoff between letting user do everything themselves such that they know exactly what's happening in their system That makes the (IMO false) assumption that people doing things for themselves by following instructions tend to learn what those things do, rather than simply remembering a "magic" ritual that made something work. Some people will take the time to study and learn how the various commands work and the syntax of different shell & scripting languages. Most won't.

nixpulvis 5y ago

Don't fucking edit my bash profile.

kyleee 5y ago
Maybe with consent I guess; IIRC fzf asks if you want to append a couple config lines to bash config which seems sensible
- portpecos 5y ago
  I like this. Give me the option to hit yes or no.
bmn__ 5y ago
Why don't we have a `~/.config/bash.d/` directory whose files are automatically sourced? That they there is no need for installers to step on the toes of a central profile, they would just add a file to the directory which also is easily and safely undone.
- Jakob 5y ago
  That is /etc/paths.d/ on macos.
  - corpMaverick 5y ago
    I think the parent comment wants the files per user no global.

hollerith 5y ago

I've been using Unix and Linux since 1992, and its only in the last 6 years or so that I've started to see an installer or any other program modify ~/.profile or ~/.bashrc. (This is one instance in which I wish the installers, etc, would keep to the tradition.) Linux distros usually have a mechanism that allows a package to modify a shell's environment without touching dot files that user is used to editing. On Fedora, /etc/profile sources all the .sh files in /etc/profile.d. So for example, installing the "snap" package write a file named /etc/profile.d/snap.sh, which contains this: # Expand $PATH to include the directory where snappy applications go. snap_bin_path="/var/lib/snapd/snap/bin" if [ -n "${PATH##*${snap_bin_path}}" ] && [ -n "${PATH##*${snap_bin_path}:*}" ]; then export PATH="$PATH:${snap_bin_path}" fi

soneil 5y ago
osx provides /etc/paths.d/ for this too, editing dotfiles isn't necessary. This one arguably makes sense though. Because it's being used to install separately from the OS (eg you can use brew on linux to provide a per-user package manager in $HOME), setting "my brew" system-wide might not be the sensible default. (But then, I can't remember the last time I saw a mac that was genuinely multi-user). I guess there's no one answer, but creating /etc/paths.d/homebrew might belong on the list of options.
nerdponx 5y ago
I use ~/.config/envrc.d and ~/.config/zshrc.d for this. The former is only run "on startup" and the latter is run for every interactive shell.

deleted 5y ago

[deleted]

caymanjim 5y ago

The installer should update the shell rc file (with a power user option to disable it), but it's not possible for it to do the second step and source it in the current shell. They could just tell you to restart your session, though.

YetAnotherNick 5y ago

Because the shell rc detection is not easy. Also the prompt is not correct in multi user environment. I guess brew has list of hardcoded paths(~/.zshrc for zsh ~/.bashrc for bash etc)

amazingman 5y ago

Modifying a user’s shell profile(s) is a step way too far for many (most?) people who work in their shell all day. If people don’t know what the commands mean, this can be solved with better/more context.