Error after trying to upgrade installed

[Ryan Schmidt]

On Jan 18, 2009, at 19:10, Rainer Müller wrote:

> Doctor Who wrote:
>
>> Well, I hope there is some way to fix/recover from this.  I cannot
>> even list files on my file system in Terminal.app (as evidenced by  
>> the
>> attempt at the ls command above).
>
> It is trying to use /opt/local/bin/ls which is broken. You can  
> still use
> /bin/ls.
>
> You can now either always type the full path /bin/ls, remove
> /opt/local/bin from your PATH or deactivate the broken coreutils:
>   sudo port deactivate coreutils
>
> Then you should at least have working ls/cp/mv etc. again.

Yes, fixing the PATH in ~/.profile or ~/.bash_profile or just  
temporarily in the Terminal would allow you to now type "ls" or  
"touch" in the Terminal, however:


> Now to fix the gettext issue, please try if this works now:
>   sudo port deactivate gettext
>   sudo port activate gettext
>
> registry1.0 uses calls like 'system "rm -rf ${receipt_file}"' to work
> with receipt files, so it was unable to operate with the broken
> coreutils in PATH.

Note that the user's PATH is not used by MacPorts, so this will still  
fail until you also change the PATH that MacPorts uses while running,  
which is set in the variable binpath in the file /opt/local/etc/ 
macports/macports.conf

You could change the binpath so that /bin and /usr/bin precede /opt/ 
local/bin. Then MacPorts will use the system's file manipulation  
utilities (ln, touch, etc.) you will hopefully be able to deactivate  
the old gettext and activate the new one, at which point your  
coreutils versions of ln and touch will work again and you can (and  
should) revert binpath in macports.conf and PATH in .profile  
or .bash_profile to what they were.

Then, you should probably uninstall coreutils +with_default_names  
because it's probably not good to override those default Mac OS X  
utilities.

We could consider removing the +with_default_names capability from  
the coreutils port.

We should also consider forcing MacPorts base to always use vital  
utilities like ln and touch via their absolute paths in /bin or /usr/ 
bin and not allow a MacPorts version to interfere. We might consider  
the same for tar, gzip, bzip2, etc, to avoid the occasional problem  
with the MacPorts versions of those utilities, e.g. the thread "error  
apache2 from macports 1.70" earlier today:

http://lists.macosforge.org/pipermail/macports-users/2009-January/ 
013335.html