On Jan 18, 2009, at 20:18, Doctor Who wrote:

On Sun, Jan 18, 2009 at 9:01 PM, Ryan Schmidt wrote:

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,

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

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

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

Not to be a pain, but I'm pretty new to MacPorts and I don't want to
mess my system up more.  Would you please outline the steps I should
take one by one to (hopefully) restore my system back to 'normal'?

I'm not certain, as I haven't encountered this problem before.

But my suggestion is exactly as I outlined above.

1. Edit /opt/local/etc/macports/macports.conf and change this line:

#binpath /opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/ sbin:/usr/X11R6/bin

Remove the hash at the beginning and change the order so that it reads:

binpath /bin:/sbin:/usr/bin:/usr/sbin:/opt/local/bin:/opt/local/ sbin:/usr/X11R6/bin

2. Deactivate your old gettext:

sudo port deactivate gettext @0.17_3

3. Activate your new gettext:

sudo port activate gettext @0.17_4

4. Uninstall coreutils because it is not a good idea to override the default Mac OS X file utilities:

sudo port uninstall coreutils

5. Edit /opt/local/etc/macports/macporst.conf and put the binpath line back the way it was before, including the order of the paths and the hash at the beginning of the line.

macports-users mailing list

Reply via email to