coreutils ls color (was: another question...)

[Rodolfo Aramayo]

On Tue, May 10, 2011 at 11:39, Ryan Schmidt <ryandesign at macports.org> wrote:

> On May 10, 2011, at 10:04, Rodolfo Aramayo wrote:
>
> > On Tue, May 10, 2011 at 09:47, Ryan Schmidt <ryandesign at macports.org>
> wrote:
> >
> >> MacPorts used to optionally allow users to install GNU programs without
> their "g" prefix, thus making them override the BSD versions provided by Mac
> OS X. This caused many problems within MacPorts so we removed this
> possibility and changed it to install the unprefixed versions in a separate
> directory. Users are now welcome to add that unprefixed directory to their
> PATH if they wish, which at least means that software built using MacPorts
> will not be affected (because MacPorts does not use your PATH). You can read
> more about the problem here if you're interested:
> >>
> >> https://trac.macports.org/ticket/20748
> >
> > I agree and you are right GNU and BSD can be very different
> >
> > Now if MacPorts does not use my PATH certainly Apple will not either, so
> the problem will be restricted to programs not installed by either Apple or
> MacPorts, which is a minority..??
>
> I would say that by putting GNU versions of programs in your PATH, you
> could cause problems for some software that you compile by hand (i.e. not
> using MacPorts).
>
> > Interestingly I was not aware of that you guys had run into problems
> before...which begs the question: why did you? you just told me that
> MacPorts does not use my  paths so why was MacPorts software compilation
> affected by the PATH set by the user??
>
> MacPorts uses its own definition of PATH, which includes /opt/local/bin
> first. The problem was that we let users install unprefixed GNU versions of
> programs into /opt/local/bin. The user wasn't modifying their PATH; the
> programs were being installed into a location that was already in the user's
> (and MacPorts') PATH. This could therefore cause problems for any other
> program installed using MacPorts.
>

Well it looks to me that in that case the user in question did not know what
was doing. I would never purposely install anything inside MacPorts exactly
because of the reasons outlined above. And it even makes me nervous when
Perl scripts get installed by default inside MacPorts (I am using Ports Perl
as my primary Perl...), but I can understand why this is required...

But I am also using the Bash distributed by MacPorts and so far that has
proven to work very well with the resident MacOSX system. So I do not
understand well why adding instructions to control Bash/coreutils behavior
is dangerous...when I thought things were designed to be kept them
separated, which begs the following question:

Does MacPorts use the programs provided by coreutils or not? I think the
answer is NO. Right?

If that is the case then installing coreutils in "/opt/local/bin" should not
affect MacPorts compilation at all.  Nor should it affect Apple BSD
compilation. In fact it should not affect any compilation because all those
programs are just utilities used by the terminal and/or Bash/Sh. Telling
Bash how to behave should not affect anything but Bash itself, right?

Otherwise what are we doing releasing newer non-Apple-approved versions of
Bash and other programs through Ports? If we cannot use anything not
Apple-approved what is the point on having a machine and a chip that can use
the latest versions of GNU programs when those programs are NOT interfering
with the Apple-approved BSD software and utilities..or ARE THEY??

I think that this is the core of this discussion...are we or are we not
affecting the core of Apple system by using MacPorts ported software. I
thought the answer was NO!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-users/attachments/20110510/ea61381c/attachment.html>