Hacker News Reader

Comment by herpderperator | Hacker News Reader

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.

View on HN

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

> 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.

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

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.

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.

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.

> 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.

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.

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.

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.

If you remember the total trashfire that was config.sys/autoexec.bat on DOS, I really hope installers do not start editing startup scripts.

Don't fucking edit my bash profile.

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.

That is /etc/paths.d/ on macos.

I think the parent comment wants the files per user no global.

Maybe with consent I guess; IIRC fzf asks if you want to append a couple config lines to bash config which seems sensible

I like this. Give me the option to hit yes or no.

> 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.

One could also argue that "most users" should know what those two commands mean. Instead, your "most users" are actually users with above-average knowledge of the shell who prefer vetting their dotfiles. That is certainly not "most users" using brew at work to install some simple dependencies for their SWE dayjobs.

I think it could be argued that the average software developer should know how PATH works and how to edit their shell's dotfile. So "most users" may not know how to do this, but they really should. It doesn't take that long to learn and it will help out tremendously. Compared to all the fancy web frameworks and complex languages, editing a dotfile is relatively simple and the skills involved are not likely to "go out of style" any time soon.

And to the extent to which someone doesn't know how paths or shell profiles work, they end up getting burned eventually. Is this a sane complexity? Maybe not. But if so--and to be clear, I would totally be willing to believe it is a sane complexity!--then whose fault is it? I think probably Apple, as I don't think they offer something like /etc/profile.d? We can fix it by education, not by pretending it isn't a problem. We can fix it by changing how shells work (though adding features to shells has no guarantee Apple will bother updating them; maybe they will start now that they moved to zsh?). When we say "developers shouldn't have to know about how X works" and then try to solve that by adding some rickety automation we don't solve the underlying problem: we create a second problem.

It shouldn’t be modifying your dotfiles but I think there’s a good case it should drop a file in /etc/paths.d.

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

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.

I would much rather a program modify something in the /home/user folder than anything in /etc.

.aliases .exports .paths????

Aehm, no? After all, this is my "home", quite literally.

Yes, but what you do in your home should not affect what goes on in my home.

Yes, exactly! So why should I have a tool modify my home, just because you prefer it that way?

Sure, but macOS doesn't ship a /etc/profile that sources /etc/profile.d/*.

Macos sources /etc/paths.d/ instead.

I think this is a very linux-centric view.

I'm developing on Windows, and here are the tools that took the libery to add themselves to PATH:

- mingw64

- ImageMagick

- Chocolatey

- pdftk

- calibre

- OpenSSH

- Docker

- GnuPG

- VS Code

and also simply lots of runtimes:

- Java

- Python

- Ruby

- .NET Core

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)

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.

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.

Reply on news.ycombinator.com