On Sun, Jan 18, 2009 at 9:01 PM, Ryan Schmidt <ryandes...@macports.org> 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'?

macports-users mailing list

Reply via email to