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