Hacker News Reader

Comment by seneca | 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.

No, installers should not be automatically modifying your profile or your PATH. That would be overstepping significantly, and violating the expectations of most users.

View on HN

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

Reply on news.ycombinator.com