Prevent MacPorts editing .bash_profile over and over again...

[Ryan Schmidt]

> On Feb 1, 2017, at 08:20, Bachsau <web at bachsau.name> wrote:
> 
> Am 01.02.2017 um 07:38 schrieb Ryan Schmidt:
>> Sorry. Repeated modifications of the profile when the modifications were already there was a bug. It looks like a fix was committed, so hopefully 2.4.1 will not have this bug anymore.
> 
> Not only repeated modifications. It simply should not do that in any case, without asking back!
> 
>> Using /etc/paths to add the MacPorts paths is not recommended because that appends the MacPorts paths to the default, while we want the MacPorts paths to be prepended. We want MacPorts versions of software to supersede probably older versions provided by the OS, not vice versa as using /etc/paths will do.
> 
> It depends on the order in your /etc/paths. If I put it first, it is first. The advantage of /etc/paths is it is applied even to the graphical environment, not just when running a login shell.

Oh, I was thinking of /etc/paths.d

https://trac.macports.org/ticket/24105


>> The MacPorts installer has always done this. I'm pretty sure it tells you it will do this, and our documentation says so too.
> 
> It did not, never.

The installer's Read Me page says:

> A file named ~/.profile is created for the "bash" shell (default on Mac OS X 10.3 and newer) during the MacPorts installation. It contains the necessary statements to append MacPorts' binary paths within /opt/local/ to your shell environment, so MacPorts is available to you on subsequent terminal sessions. You may have to quit and restart your terminal application for this change to take effect.

The guide says:

https://guide.macports.org/#installing.shell

> MacPorts requires that some environment variables be set in the shell. When MacPorts is installed using the OS X package installer, a “postflight” script is run after installation that automatically adds or modifies a shell configuration file in your home directory, ensuring that it defines variables according to the rules described in the following section. Those installing MacPorts from source code must modify their environment manually using the rules as a guide.
> 
> Depending on your shell and which configuration files already exist, the installer may use .profile, .bash_login, .bash_profile, .tcshrc, or .cshrc.



>> The alternative is that the user installs MacPorts, then when they try to use it they get an error that "port" could not be found in the path; this will cause tons of support requests that I would prefer to avoid, so I'd like to keep things the way they are, with the installer modifying the user's profile when needed.
> 
> People using MacPorts are those who know about the insides of their system and want to customize it. I think they should at least be able to read and follow documentation.

This is definitely not the case. There are many nontechnical users who are directed to MacPorts by other projects (such as Inkscape) and they only want to install that project; they don't want to understand how MacPorts or the shell works. We should work toward making MacPorts easier for nontechnical users, not harder.