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
_______________________________________________
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
