[MacPorts] #20524: base-1.7.1 Neater PATH change process for Postflight
#20524: base-1.7.1 Neater PATH change process for Postflight -------------------------------------+-------------------------------------- Reporter: alex@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: MacPorts Future Component: base | Version: 1.7.1 Keywords: PATH profile postflight | Port: -------------------------------------+-------------------------------------- In a basic install of MacPorts 1.7.1 on clean Leopard, my .profile didn't get updated with the required PATH adjustments for /opt/local - so I decided to do it myself. In looking through the various 'profile' files in /etc - for all the different shells (csh, bash, tcsh, zsh, etc.) - they all have code in them to run /usr/libexec/path_helper. This is a script that reads two files in /etc - /etc/paths and /etc/manpaths which are simple text files containing a list of paths to be added to $PATH when the shell environment is set up. Instead of the extra code in the postflight script to determine what shell is used etc. to add the MacPorts paths to $PATH, wouldn't it be just much neater to add the two paths to the /etc/paths file? Then you'd always have access to the MacPorts apps regardless of what shell you use in OS X, because Apple have ensured that this /usr/libexec/path_helper is run across all shells. This may be Leopard-only, and if you don't consider a global $PATH modification appropriate then feel free to cancel this ticket, but I feel it'd be a useful solution for many MacPorts users, and certainly would simplify the postflight. I still get occasional non-editing of .profile when running the current package. I prepended the two paths /opt/local/bin and /opt/local/sbin to the /etc/paths file, and on opening a Terminal window (regardless of shell - I tried bash, zsh, tcsh and sh), the MacPorts folders were in the $PATH variable and I could run MacPorts code. Nice and easy and more elegant than hacking .profile files, which may already be extensively hacked by the users themselves. Just a suggestion, and I'm a complete newbie to this bug tracker system so apologies if this is in the wrong place. Please allocate to the right location! cheers, Alex -- Ticket URL: <http://trac.macports.org/ticket/20524> MacPorts <http://www.macports.org/> Ports system for Mac OS
#20524: base-1.7.1 Neater PATH change process for Postflight ---------------------------------+------------------------------------------ Reporter: alex@… | Owner: macports-tickets@… Type: enhancement | Status: closed Priority: Normal | Milestone: MacPorts Future Component: base | Version: 1.7.1 Resolution: wontfix | Keywords: PATH profile postflight Port: | ---------------------------------+------------------------------------------ Changes (by ryandesign@…): * cc: ryandesign@… (added) * status: new => closed * resolution: => wontfix Comment: We originally had code to do this, but removed it again because it was Leopard only, and because it did not do the same thing to the paths as what we have now: What we have now puts the MacPorts prefix FIRST in the path, whereas using /etc/paths and /etc/manpaths puts the MacPorts prefix LAST in the path, which is not what we want. -- Ticket URL: <http://trac.macports.org/ticket/20524#comment:1> MacPorts <http://www.macports.org/> Ports system for Mac OS
#20524: base-1.7.1 Neater PATH change process for Postflight ---------------------------------+------------------------------------------ Reporter: alex@… | Owner: macports-tickets@… Type: enhancement | Status: closed Priority: Normal | Milestone: MacPorts Future Component: base | Version: 1.7.1 Resolution: wontfix | Keywords: PATH profile postflight Port: | ---------------------------------+------------------------------------------ Comment(by alex@…): Fair enough, it was just an idea. I've just checked my system out and even though I've ensured that the MacPorts paths are at the beginning of the /etc/paths file, they're still not first in the $PATH variable even though the path_helper script ought to process them in order, so you're right, it'd need more tweaking and perhaps be just as much work as the current method. Interestingly, though my /etc/paths file contains the two MacPorts paths *first*, then the defaults, then /usr/local/bin (it looks like this): /opt/local/bin /opt/local/sbin /usr/bin /bin /usr/sbin /sbin /usr/local/bin - the process output from /usr/libexec/path_helper -c is: setenv PATH "/usr/bin:/bin:/usr/sbin:/sbin:/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/X11/bin"; setenv MANPATH "/opt/local/share/man:/usr/share/man:/usr/local/share/man:/usr/X11/man"; which is weird since I've put the MacPorts paths first, but it's skipped those, put the default paths in first, then the MacPorts paths, and then the /usr/local/bin at the end - before it started processing anything in the /etc/paths.d folder. I'll see if I can work out how this is working, as it's not immediately clear from the path_helper script. Thanks for the quick response and consideration though. Best regards, Alex -- Ticket URL: <http://trac.macports.org/ticket/20524#comment:2> MacPorts <http://www.macports.org/> Ports system for Mac OS
participants (1)
-
MacPorts