4 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. No, installers should

by 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.
        bipson 5y ago
        Yes, exactly! So why should I have a tool modify my home, just because you prefer it that way?
  - auscompgeek 5y ago
    Sure, but macOS doesn't ship a /etc/profile that sources /etc/profile.d/*.
    - Jakob 5y ago
      Macos sources /etc/paths.d/ instead.
herpderperator 5y ago
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.
- chillpenguin 5y ago
  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.
  - saurik 5y ago
    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.
ThePadawan 5y ago
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

by seneca 5y ago

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.
      - bipson 5y ago
        Yes, exactly! So why should I have a tool modify my home, just because you prefer it that way?
- auscompgeek 5y ago
  Sure, but macOS doesn't ship a /etc/profile that sources /etc/profile.d/*.
  - Jakob 5y ago
    Macos sources /etc/paths.d/ instead.

herpderperator 5y ago

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.

chillpenguin 5y ago
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.
- saurik 5y ago
  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.

ThePadawan 5y ago

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