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

[Christopher Jones]

> On 22 Mar 2017, at 1:32 pm, Jan Stary  wrote:
> 
> On Mar 22 12:53:15, rai...@macports.org wrote:
>> On 2017-03-21 21:43, Jan Stary wrote:
>>> +echo "Remember to set your environment:"
>>> +echo "Prepend ${BINPATH} and ${SBINPATH} to PATH."
>>> +echo "Prepend ${MANPAGES} to MANPATH if you use MANPATH."
>>> +echo "Remember to set DISPLAY if you are on 10.4 or older."
>>> +echo "See https://guide.macports.org/#installing.shell for details."
>> 
>> Where do you think users would see this?
> 
> The same place where all the other echo's go.
> 
>> I am quite sure the installer
>> does not show any output of the postflight script.
> 
> Does it go to a log?

Frankly, it does not matter where the message may or may not go. It could be 
flashed on the screen in huge red letters, some users will still ignore it and 
then complain that MacPorts does not work because $prefix is not in their 
paths… 

This is why a proposal to remove this from the installer is (IMHO) a non 
starter. Now, if you where instead to propose extending the installer with a 
page, that clearly explained why editing the users path is needed, and offered 
an option to opt out (the default would have to stay yes) then I think you 
stand a better chance of getting something included. But as it stands just 
removing this feature isn’t going to fly, in my view.

Chris


> 
>   Jan
> 



smime.p7s
Description: S/MIME cryptographic signature

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

[Jan Stary]

On Mar 22 14:32:03, h...@stare.cz wrote:
> On Mar 22 12:53:15, rai...@macports.org wrote:
> > On 2017-03-21 21:43, Jan Stary wrote:
> > > +echo "Remember to set your environment:"
> > > +echo "Prepend ${BINPATH} and ${SBINPATH} to PATH."
> > > +echo "Prepend ${MANPAGES} to MANPATH if you use MANPATH."
> > > +echo "Remember to set DISPLAY if you are on 10.4 or older."
> > > +echo "See https://guide.macports.org/#installing.shell for details."
> > 
> > Where do you think users would see this?
> 
> The same place where all the other echo's go.

(But I don't mind if the snippet above disappears,
the documentation says it in much more detail.)

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

[Jan Stary]

On Mar 22 12:53:15, rai...@macports.org wrote:
> On 2017-03-21 21:43, Jan Stary wrote:
> > +echo "Remember to set your environment:"
> > +echo "Prepend ${BINPATH} and ${SBINPATH} to PATH."
> > +echo "Prepend ${MANPAGES} to MANPATH if you use MANPATH."
> > +echo "Remember to set DISPLAY if you are on 10.4 or older."
> > +echo "See https://guide.macports.org/#installing.shell for details."
> 
> Where do you think users would see this?

The same place where all the other echo's go.

> I am quite sure the installer
> does not show any output of the postflight script.

Does it go to a log?

Jan

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

[Rainer Müller]

On 2017-03-21 21:43, Jan Stary wrote:
> +echo "Remember to set your environment:"
> +echo "Prepend ${BINPATH} and ${SBINPATH} to PATH."
> +echo "Prepend ${MANPAGES} to MANPATH if you use MANPATH."
> +echo "Remember to set DISPLAY if you are on 10.4 or older."
> +echo "See https://guide.macports.org/#installing.shell for details."

Where do you think users would see this? I am quite sure the installer
does not show any output of the postflight script.

Rainer

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

[Ryan Schmidt]

On Mar 21, 2017, at 18:21, Brandon Allbery wrote:
> On Tue, Mar 21, 2017 at 7:18 PM, Brandon Allbery wrote:
>> vim $(port logfile thePort)
> 
> ...and the port you installed will usually get expanded with . 
> (bash/zsh, in default emacs mode) so you don't even need to type that :)

I'm not aware of this. Can you explain how to make this work?

You mention "emacs mode"... I don't know what that is.

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

[Ryan Schmidt]

> On Mar 21, 2017, at 16:23, Dave Horsfall  wrote:
> 
> On Tue, 21 Mar 2017, Brandon Allbery wrote:
> 
>> Never assume people will read instructions. How often do we get people 
>> who cut and paste the boilerplate at the end of a failed build that 
>> tells them to check the build log, and mail it here asking what they 
>> should do?
> 
> Which reminds me: would it be possible to symlink to the log file from 
> somewhere in /tmp?  It's a real PITA doing a C with a path that wraps 
> lines...  Yes, I'm an old fogey, and use 80 columns...

If I want to copy the logfile path, I usually use:

port logfile thePort | pbcopy

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

[Chris Jones]

On 21/03/17 20:43, Jan Stary wrote:

Here is a diff to postflight and an accompanying diff to installing.xml
(what other places need to be touched if this goes through?)


I do not think this will get committed. At least I hope it does not. As 
explained by others the current situation where if you use the installer 
then the config file gets updated, but if you install from source is the 
best compromise of user friendliness.




Jan


diff --git a/portmgr/dmg/postflight.in b/portmgr/dmg/postflight.in
index 750553f0..a3a8bd80 100755
--- a/portmgr/dmg/postflight.in
+++ b/portmgr/dmg/postflight.in
@@ -87,28 +87,6 @@ function update_macports {
 fi
 }

-# Through this command we write an environment variable to an appropriate 
shell configuration file,
-# backing up the original only if it exists and if it doesn't contain the 
${OUR_STRING} identification string,
-# which hints that we've already tweaked it and therefore already backed it up.
-function write_setting () {
-if [[ -f "${HOME}/.${CONF_FILE}" ]] && ! grep "${OUR_BASESTRING}" 
"${HOME}/.${CONF_FILE}" > /dev/null; then
-echo "Backing up your ${HOME}/.${CONF_FILE} shell confguration file as 
${HOME}/.${CONF_FILE}.${BACKUP_SUFFIX} before adapting it for MacPorts."
-/bin/cp -fp "${HOME}/.${CONF_FILE}" 
"${HOME}/.${CONF_FILE}.${BACKUP_SUFFIX}" || {
-echo "An attempt to backup your original configuration file failed! 
Please set your MacPorts compatible environment manually."
-update_macports
-exit 1
-}
-echo -e "\n##\n# Your previous ${HOME}/.${CONF_FILE} file was backed up as 
${HOME}/.${CONF_FILE}.${BACKUP_SUFFIX}\n##" >> "${HOME}/.${CONF_FILE}"
-fi
-{
-echo -e "\n# ${OUR_STRING}: adding an appropriate ${1} variable for use 
with MacPorts."
-echo "${ENV_COMMAND} ${1}${ASSIGN}${2}"
-echo -e "# Finished adapting your ${1} environment variable for use with 
MacPorts.\n"
-} >> "${HOME}/.${CONF_FILE}"
-chown "${USER}" "${HOME}/.${CONF_FILE}" || echo "Warning: unable to adapt 
permissions on your ${HOME}/.${CONF_FILE} shell configuration file!"
-echo "An appropriate ${1} variable has been added to your shell environment by 
the MacPorts installer."
-}
-
 function cleanup_man () {
 # Remove old non-compressed man pages
 echo -e "\nRemoving old man pages..."
@@ -195,8 +173,6 @@ function create_run_user {
 fi
 }

-echo "The MacPorts Project, postflight script version ${VERSION}: checking the shell 
environment for user \"${USER}\"."
-
 # create macports user
 create_run_user
 # Set up config files
@@ -207,78 +183,11 @@ cleanup_man
 delete_old_tcl_package_link
 delete_old_tcl_packages

-# Determine the user's shell, in order to choose an appropriate configuration 
file we'll be tweaking.
-# Exit nicely if the shell is any other than bash or tcsh, as that's 
considered non-standard.
-USHELL=$(${DSCL} . -read "/Users/${USER}" shell) || {
-echo "An attempt to determine your shell name failed! Please set your MacPorts 
compatible environment manually."
-update_macports
-exit 1
-}
-# leave full path to shell
-USHELL=${USHELL#*shell: }
-
-case "${USHELL}" in
-*/tcsh)
-echo "Detected the tcsh shell."
-LOGIN_FLAG=""
-ENV_COMMAND="setenv"
-ASSIGN=" "
-if [[ -f "${HOME}/.tcshrc" ]]; then
-CONF_FILE=tcshrc
-elif [[ -f "${HOME}/.cshrc" ]]; then
-CONF_FILE=cshrc
-else
-CONF_FILE=tcshrc
-fi
-;;
-*/bash)
-echo "Detected the bash shell."
-LOGIN_FLAG="-l"
-ENV_COMMAND="export"
-ASSIGN="="
-if [[ -f "${HOME}/.bash_profile" ]]; then
-CONF_FILE=bash_profile
-elif [[ -f "${HOME}/.bash_login" ]]; then
-CONF_FILE=bash_login
-else
-CONF_FILE=profile
-fi
-;;
-*)
-echo "Unknown shell ($USHELL)! Please set your MacPorts compatible 
environment manually."
-update_macports
-exit 0
-;;
-esac
-
-# Adding our setting to the PATH variable if not already there:
-# Run as the $USER: /usr/bin/su $USER -l
-# Run a command in the shell: -c "/usr/bin/printenv PATH"
-# Only process the last line output (profile may print info): tail -n 1
-# Output each path on its own line: tr ":" "\n"
-# Look for exactly the BINPATH: grep "^${BINPATH}$"
-if /usr/bin/su "${USER}" -l -c "/usr/bin/printenv PATH" | tail -n 1 | tr ":" "\n" | grep 
"^${BINPATH}$" > /dev/null; then
-echo "Your shell already has the right PATH environment variable for use with 
MacPorts!"
-else
-write_setting PATH "\"${BINPATH}:${SBINPATH}:\$PATH\""
-fi
-
-# Adding our setting to the MANPATH variable only if it exists:
-if /usr/bin/su "${USER}" -l -c "/usr/bin/printenv MANPATH" > /dev/null; then
-# check for MANPAGES already in MANPATH
-if /usr/bin/su "${USER}" -l -c "/usr/bin/printenv MANPATH" | tail -n 1 | tr ":" 

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

[Brandon Allbery]

On Tue, Mar 21, 2017 at 7:18 PM, Brandon Allbery 
wrote:

> vim $(port logfile thePort)
>

...and the port you installed will usually get expanded with .
(bash/zsh, in default emacs mode) so you don't even need to type that :)

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

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

[Brandon Allbery]

On Tue, Mar 21, 2017 at 5:23 PM, Dave Horsfall  wrote:

> On Tue, 21 Mar 2017, Brandon Allbery wrote:
> > Never assume people will read instructions. How often do we get people
> > who cut and paste the boilerplate at the end of a failed build that
> > tells them to check the build log, and mail it here asking what they
> > should do?
>
> Which reminds me: would it be possible to symlink to the log file from
> somewhere in /tmp?  It's a real PITA doing a C with a path that wraps
> lines...  Yes, I'm an old fogey, and use 80 columns...
>

vim $(port logfile thePort)

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

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

[Dave Horsfall]

On Tue, 21 Mar 2017, Brandon Allbery wrote:

> Never assume people will read instructions. How often do we get people 
> who cut and paste the boilerplate at the end of a failed build that 
> tells them to check the build log, and mail it here asking what they 
> should do?

Which reminds me: would it be possible to symlink to the log file from 
somewhere in /tmp?  It's a real PITA doing a C with a path that wraps 
lines...  Yes, I'm an old fogey, and use 80 columns...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

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

[Daniel J. Luke]

On Mar 21, 2017, at 9:30 AM, Jan Stary  wrote:
> I appreciate you concern about being spammed with trivia.
> But it's one line in ~/.profile, which is equally trivial.

While I agree with you in principle (see list archives where I disagreed with 
adding this to the installer way back when it was first introduced) - Ryan is 
right that we used to get lots of support requests where people apparently 
weren't capable of reading the instructions and updating their $PATH themselves.

Our actual experience around this issue tells us that it's worse to not try to 
set $PATH in the installer.

> I find mangling the user's shell configuration worse:
> someone who uses macports to install software
> is capable of editing one line in their config if told so.

users who are smart enough to edit their configs are also smart enough to 
install from source (where you don't have this issue at all).

-- 
Daniel J. Luke

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

[Bachsau]

Am 05.02.2017 um 12:03 schrieb Barry Scott:

Editing a system wide setting would have to come with a option to
disable it.


Editing any setting has to come with that option. However, I never said 
the installer should modify /etc/paths. I just said I did it that way 
and if the installer would check my actual PATH variable it would notice 
there's no need to edit .bash_profile




smime.p7s
Description: S/MIME Cryptographic Signature

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

[Brandon Allbery]

On Thu, Feb 2, 2017 at 8:09 PM, Ryan Schmidt 
wrote:
>
> > 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
>
>
Right. The problem with /etc/paths is Apple can and will (or at least used
to, and I would not trust it) smack it back to their default whenever they
feel like.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

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

[Eneko Gotzon]

On Fri, Feb 3, 2017 at 2:09 AM, Ryan Schmidt 
wrote:

> There are many nontechnical users…


Yes…​


> they don't want to understand how MacPorts or the shell works.


Rather, ​at least in my case,
the​
is
​s
ue
​is ​
to not having enough time to learn.


> We should work toward making MacPorts easier for nontechnical users, not
> harder.


​Thank you very much (wonderful) Ryan.​

Anyway, I accept that every user should assume a minimum of obligations.

​Have a great day; all you deserve it.​

-- 
Eneko Gotzon Ares
enekogot...@gmail.com

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

[Ryan Schmidt]

> On Feb 1, 2017, at 08:20, Bachsau  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.

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

[Chris Jones]

On 01/02/17 17:23, Barry Scott wrote:



On 1 Feb 2017, at 14:20, Bachsau > 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!


It is not uncommon to have your profile modified. The python.org
 installer will do this.
But in that case there is a Customise button that allows you to turn
this off.


This is something I think the Macports installer should do, have a 
dedicated 'page' in the installer that explains why this is needed, 
defaults to enabling it, but offers the option to opt out if the users 
wants.


Chris






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.


The fix that I contributed fixed the bug and will in fact take into
account your edits to /etc/paths as there terminal will start with PATH
set to this.




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



I don’t think its safe to assume all MacPorts uses are expert admins.

Barry

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

[Eneko Gotzon]

On Wed, Feb 1, 2017 at 6:23 PM, Barry Scott  wrote:

> I don’t think it's safe to assume all MacPorts uses are expert admins.


You are right, at least on my case.

-- 
Eneko Gotzon Ares
enekogot...@gmail.com

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

[Dan D.]

until it is fixed, a cludge is to have a profile to copy over .profile, 
perhaps in .profile itself.


Any subsequent macports calls/activity will not add additional path info to 
the working .profile.

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

[Barry Scott]

> On 1 Feb 2017, at 14:20, Bachsau  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! 

It is not uncommon to have your profile modified. The python.org 
 installer will do this.
But in that case there is a Customise button that allows you to turn this off.

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

The fix that I contributed fixed the bug and will in fact take into account 
your edits to /etc/paths as there terminal will start with PATH set to this.

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

I don’t think its safe to assume all MacPorts uses are expert admins.

Barry

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

[Bachsau]

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.



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




smime.p7s
Description: S/MIME Cryptographic Signature

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

[Ryan Schmidt]

> On Jan 31, 2017, at 07:50, Bachsau wrote:
> 
> Am 28.01.2017 um 17:31 schrieb Barry Scott:
>> I want to be able to stop MacPorts Installation from editing my 
>> .bash_profile.
>> As it happens I already set all the env var that are needed my self.
>> 
>> Is there a “do-not-edit-bash-profile” settings somewhere?
>> 
>> So far I have 3 sets of the settings in the same file.
>> 
>> Barry
> 
> This is driving me mad as well. >:[[
> 
> Whenever I install a new base using the pkg it changes my .bash_profile, even 
> though I set all my paths in /etc/paths and am using MacPort's Bash as my 
> default shell.

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.

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.


> Nothing should change my .bash_profile without asking back. It is something 
> that malware usually does.

The MacPorts installer has always done this. I'm pretty sure it tells you it 
will do this, and our documentation says so too. 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.

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

[Bachsau]

Am 28.01.2017 um 17:31 schrieb Barry Scott:

I want to be able to stop MacPorts Installation from editing my .bash_profile.
As it happens I already set all the env var that are needed my self.

Is there a “do-not-edit-bash-profile” settings somewhere?

So far I have 3 sets of the settings in the same file.

Barry


This is driving me mad as well. >:[[

Whenever I install a new base using the pkg it changes my .bash_profile, 
even though I set all my paths in /etc/paths and am using MacPort's Bash 
as my default shell. Nothing should change my .bash_profile without 
asking back. It is something that malware usually does.




smime.p7s
Description: S/MIME Cryptographic Signature

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

[Barry Scott]

Here is a pull request that fixes the issue for me.

https://github.com/macports/macports-base/pull/16 


"Fix the detection of /opt/local/bin in user's PATH

The postflight script was using the SHELL variable, which is root's shell
and not USHELL, which is the user's shell.

The test for MacPorts paths in the users PATH can be made more robust.
The old code will match on /opt/locale for example.

Spit the PATH into one path per line with tr and then grep for an exact match
with /opt/local/bin.”

I tested this for bash and checked the logs of the installed for unexpected 
messages.

Barry

> On 30 Jan 2017, at 20:48, Clemens Lang  wrote:
> 
> Hi,
> 
> On Mon, Jan 30, 2017 at 05:37:41PM +, Barry Scott wrote:
>>> On 30 Jan 2017, at 12:44, Barry Scott  wrote:
>>> 
>>> When I run the postinstall as me it works are intended for my
>>> .bash_profile. When I run via sudo it looks at root’s file and
>>> states tit does not support the “sh” shell. I suspect that the
>>> environment that postinstall is running in is a strange in some way.
>>> (I have seen Mac specific oddities when developing python based apps
>>> like no LANG env var.)
> 
> That may very well be the problem. I suspect the installer is run as
> root, and $USER is actually root for the installer.
> 
> You should be able to see the debug output of the script in installer
> using Window > Installer Log and switching the detail level to 'Show All
> Logs'.
> 
>> I found the sudo port -d pkg MacPorts command. But that does not use
>> my git tree.
> 
> We use sudo port pkg MacPorts to create the installer. You can modify
> the MacPorts port file to point to your source tree. Instead of
> 
> github.setup macports macports-base v2.4.0
> ...
> distname ${name}-${version}
> github.tarball_from releases
> ...
> checksums ...
> 
> use
> 
> fetch.type git
> git.url file:///absolute/path/to/your/working/dir/.git
> git.branch $latest_commit_hash (or just HEAD for testing)
> 
> Note that this will only pick up committed changes, so you'll have to
> commit things for this to work. Also note that the 'macports' user must
> be able to read the path.
> 
> Since the installer won't be signed using this method you may have to
> open it using right click > open.
> 
> -- 
> Clemens
> 

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

[Clemens Lang]

Hi,

On Mon, Jan 30, 2017 at 05:37:41PM +, Barry Scott wrote:
> > On 30 Jan 2017, at 12:44, Barry Scott  wrote:
> > 
> > When I run the postinstall as me it works are intended for my
> > .bash_profile. When I run via sudo it looks at root’s file and
> > states tit does not support the “sh” shell. I suspect that the
> > environment that postinstall is running in is a strange in some way.
> > (I have seen Mac specific oddities when developing python based apps
> > like no LANG env var.)

That may very well be the problem. I suspect the installer is run as
root, and $USER is actually root for the installer.

You should be able to see the debug output of the script in installer
using Window > Installer Log and switching the detail level to 'Show All
Logs'.

> I found the sudo port -d pkg MacPorts command. But that does not use
> my git tree.

We use sudo port pkg MacPorts to create the installer. You can modify
the MacPorts port file to point to your source tree. Instead of

 github.setup macports macports-base v2.4.0
 ...
 distname ${name}-${version}
 github.tarball_from releases
 ...
 checksums ...

use

 fetch.type git
 git.url file:///absolute/path/to/your/working/dir/.git
 git.branch $latest_commit_hash (or just HEAD for testing)

Note that this will only pick up committed changes, so you'll have to
commit things for this to work. Also note that the 'macports' user must
be able to read the path.

Since the installer won't be signed using this method you may have to
open it using right click > open.

-- 
Clemens

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

[Barry Scott]

> On 30 Jan 2017, at 12:44, Barry Scott  wrote:
> 
> When I run the postinstall as me it works are intended for my .bash_profile.
> When I run via sudo it looks at root’s file and states tit does not support 
> the
> “sh” shell. I suspect that the environment that postinstall is running in is a
> strange in some way. (I have seen Mac specific oddities when developing
> python based apps like no LANG env var.)
> 
> I will need to debug the postinstall script and to do that I need to be able 
> to
> created the .pkg file.
> 
> I have cloned macport-base and done:
> 
>   ./standard-config
>   Make
> 
> What is the commands you use to create the .pkg?

I found the sudo port -d pkg MacPorts command. But that does not use my git 
tree.

Barry

> 
> Barry
> 
>> On 29 Jan 2017, at 17:29, Clemens Lang  wrote:
>> 
>> Hi,
>> 
>> On Sun, Jan 29, 2017 at 02:13:12PM +, Barry wrote:
>>> I have been using the .pkg to reinstall MacPorts. I guess that does
>>> not check.
>> 
>> It does. Specifically, the check checks what your user's shell is using
>> 
>> /usr/bin/dscl . -read "/Users/${USER}" shell | awk -F'/' '{print $NF}'
>> 
>> Supported shells are bash and tcsh. For bash, the installer then runs
>> 
>> bash -l -c "/usr/bin/printenv PATH" | grep "/opt/local"
>> 
>> to determine whether your configuration needs adjusting. For some reason
>> this fails in the installer, although we haven't been able to figure out
>> why.
>> 
>> If you'd like to help debug this, that would be very welcome. I've tried
>> adding more checks for the 2.4.0 release (like doing nothing if the
>> config file to be changed contains 'MacPorts Installer addition'), but
>> apparently none of them worked properly in your case.
>> 
>> 
>> -- 
>> Clemens
>> 
> 

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

[Barry Scott]

When I run the postinstall as me it works are intended for my .bash_profile.
When I run via sudo it looks at root’s file and states tit does not support the
“sh” shell. I suspect that the environment that postinstall is running in is a
strange in some way. (I have seen Mac specific oddities when developing
python based apps like no LANG env var.)

I will need to debug the postinstall script and to do that I need to be able to
created the .pkg file.

I have cloned macport-base and done:

./standard-config
Make

What is the commands you use to create the .pkg?

Barry

> On 29 Jan 2017, at 17:29, Clemens Lang  wrote:
> 
> Hi,
> 
> On Sun, Jan 29, 2017 at 02:13:12PM +, Barry wrote:
>> I have been using the .pkg to reinstall MacPorts. I guess that does
>> not check.
> 
> It does. Specifically, the check checks what your user's shell is using
> 
>  /usr/bin/dscl . -read "/Users/${USER}" shell | awk -F'/' '{print $NF}'
> 
> Supported shells are bash and tcsh. For bash, the installer then runs
> 
>  bash -l -c "/usr/bin/printenv PATH" | grep "/opt/local"
> 
> to determine whether your configuration needs adjusting. For some reason
> this fails in the installer, although we haven't been able to figure out
> why.
> 
> If you'd like to help debug this, that would be very welcome. I've tried
> adding more checks for the 2.4.0 release (like doing nothing if the
> config file to be changed contains 'MacPorts Installer addition'), but
> apparently none of them worked properly in your case.
> 
> 
> -- 
> Clemens
> 

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

[Clemens Lang]

Hi,

On Sun, Jan 29, 2017 at 09:33:04PM +, Barry wrote:
> Can I run the .pkg without damaging my current MacPorts setup?

Yes, unless you're at a newer version than the .pkg will install.

> Its taken some effort eo have inkscape etc installed

Ports will be kept as-is. Running the installer is roughly equivalent
with a selfupdate.

-- 
Clemens

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

[Barry]

Can I run the .pkg without damaging my current MacPorts setup?

Its taken some effort eo have inkscape etc installed

Barry


> On 29 Jan 2017, at 17:29, Clemens Lang  wrote:
> 
> Hi,
> 
>> On Sun, Jan 29, 2017 at 02:13:12PM +, Barry wrote:
>> I have been using the .pkg to reinstall MacPorts. I guess that does
>> not check.
> 
> It does. Specifically, the check checks what your user's shell is using
> 
>  /usr/bin/dscl . -read "/Users/${USER}" shell | awk -F'/' '{print $NF}'
> 
> Supported shells are bash and tcsh. For bash, the installer then runs
> 
>  bash -l -c "/usr/bin/printenv PATH" | grep "/opt/local"
> 
> to determine whether your configuration needs adjusting. For some reason
> this fails in the installer, although we haven't been able to figure out
> why.
> 
> If you'd like to help debug this, that would be very welcome. I've tried
> adding more checks for the 2.4.0 release (like doing nothing if the
> config file to be changed contains 'MacPorts Installer addition'), but
> apparently none of them worked properly in your case.
> 
> 
> -- 
> Clemens
> 

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

[Clemens Lang]

Hi,

On Sun, Jan 29, 2017 at 02:13:12PM +, Barry wrote:
> I have been using the .pkg to reinstall MacPorts. I guess that does
> not check.

It does. Specifically, the check checks what your user's shell is using

  /usr/bin/dscl . -read "/Users/${USER}" shell | awk -F'/' '{print $NF}'

Supported shells are bash and tcsh. For bash, the installer then runs

  bash -l -c "/usr/bin/printenv PATH" | grep "/opt/local"

to determine whether your configuration needs adjusting. For some reason
this fails in the installer, although we haven't been able to figure out
why.

If you'd like to help debug this, that would be very welcome. I've tried
adding more checks for the 2.4.0 release (like doing nothing if the
config file to be changed contains 'MacPorts Installer addition'), but
apparently none of them worked properly in your case.


-- 
Clemens

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

[Craig Treleaven]

AIUI, the following script is run to set up the user’s environment after the 
installer copies in all the payload files:

https://github.com/macports/macports-base/blob/master/portmgr/dmg/postflight.in#L90

Craig

> On Jan 29, 2017, at 9:13 AM, Barry  wrote:
> 
> I have been using the .pkg to reinstall MacPorts. I guess that does not check.
> 
> Barry
> 
> Barry
> 
> 
>> On 29 Jan 2017, at 02:52, Daniel J. Luke  wrote:
>> 
>> I think only the pkg installers do that - and they're supposed to not edit 
>> the $PATH if $prefix is already in there.
>> 
>> (ie if you upgrade using `port selfupdate` I don't think you have that 
>> problem).
>> 
>> Or am I mistaken?
>> 
 On Jan 28, 2017, at 4:56 PM, Barry  wrote:
 On 28 Jan 2017, at 16:37, Christopher Jones  
 wrote:
 Hi,
 
 It would be better yet if whatever it is that does this first checks to 
 see in the path it is about to add is already in the users PATH, and does 
 not add it again if already there…
>>> 
>>> That would be an improvement.
>>> 
>>> I would also like a way to say never edit my .bash_profile.
>>> Maybe a comment line specially formated.
>>> 
>>> # MacPorts: no-edit-path
>>> 
>>> Barry
>>> 
 Chris
 
> On 28 Jan 2017, at 4:31 pm, Barry Scott  wrote:
> 
> I want to be able to stop MacPorts Installation from editing my 
> .bash_profile.
> As it happens I already set all the env var that are needed my self.
> 
> Is there a “do-not-edit-bash-profile” settings somewhere?
> 
> So far I have 3 sets of the settings in the same file.
> 
> Barry
>> 
>> -- 
>> Daniel J. Luke
>> 
>> 
>> 
> 

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

[Barry]

I have been using the .pkg to reinstall MacPorts. I guess that does not check.

Barry

Barry


> On 29 Jan 2017, at 02:52, Daniel J. Luke  wrote:
> 
> I think only the pkg installers do that - and they're supposed to not edit 
> the $PATH if $prefix is already in there.
> 
> (ie if you upgrade using `port selfupdate` I don't think you have that 
> problem).
> 
> Or am I mistaken?
> 
>>> On Jan 28, 2017, at 4:56 PM, Barry  wrote:
>>> On 28 Jan 2017, at 16:37, Christopher Jones  
>>> wrote:
>>> Hi,
>>> 
>>> It would be better yet if whatever it is that does this first checks to see 
>>> in the path it is about to add is already in the users PATH, and does not 
>>> add it again if already there…
>> 
>> That would be an improvement.
>> 
>> I would also like a way to say never edit my .bash_profile.
>> Maybe a comment line specially formated.
>> 
>> # MacPorts: no-edit-path
>> 
>> Barry
>> 
>>> Chris
>>> 
 On 28 Jan 2017, at 4:31 pm, Barry Scott  wrote:
 
 I want to be able to stop MacPorts Installation from editing my 
 .bash_profile.
 As it happens I already set all the env var that are needed my self.
 
 Is there a “do-not-edit-bash-profile” settings somewhere?
 
 So far I have 3 sets of the settings in the same file.
 
 Barry
> 
> -- 
> Daniel J. Luke
> 
> 
> 

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

[Daniel J. Luke]

I think only the pkg installers do that - and they're supposed to not edit the 
$PATH if $prefix is already in there.

(ie if you upgrade using `port selfupdate` I don't think you have that problem).

Or am I mistaken?

> On Jan 28, 2017, at 4:56 PM, Barry  wrote:
>> On 28 Jan 2017, at 16:37, Christopher Jones  wrote:
>> Hi,
>> 
>> It would be better yet if whatever it is that does this first checks to see 
>> in the path it is about to add is already in the users PATH, and does not 
>> add it again if already there…
> 
> That would be an improvement.
> 
> I would also like a way to say never edit my .bash_profile.
> Maybe a comment line specially formated.
> 
> # MacPorts: no-edit-path
> 
> Barry
> 
>> Chris
>> 
>>> On 28 Jan 2017, at 4:31 pm, Barry Scott  wrote:
>>> 
>>> I want to be able to stop MacPorts Installation from editing my 
>>> .bash_profile.
>>> As it happens I already set all the env var that are needed my self.
>>> 
>>> Is there a “do-not-edit-bash-profile” settings somewhere?
>>> 
>>> So far I have 3 sets of the settings in the same file.
>>> 
>>> Barry

-- 
Daniel J. Luke