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

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

Reply via email to