RFC: coreutils uses program-prefix=g by default
Hi list, I've just installed coreutils and found that all files in coreutils have "g" prefix. "port cat corefiles" show that this is because coreutils' portfile set configure.args to "program-prefix=g". The reason why I installed coreutils was to run shell script that uses seq but for the "g" prefix, the shell script had to be modified to have "g" in front of the name. This was very annoying for me. Yes, I can easily avoid this by "port edit corefiles" and drop "program-prefix" but I thought if most of the MacPorts users wouldn't want "g", it might be better to fix this portfile. So let me ask this, "Do you like to have gls, guniq in your /opt/local/bin? Is there any case that removing "g" prefix causes any problems? Any input will be appreciated. Thanks.
js wrote: [...]
Yes, I can easily avoid this by "port edit corefiles" and drop "program-prefix" but I thought if most of the MacPorts users wouldn't want "g", it might be better to fix this portfile.
No need to edit it manually, use port install coreutils +with_default_names This will install the binaries with the default names, i.e. without the prefix "g".
So let me ask this, "Do you like to have gls, guniq in your /opt/local/bin? Is there any case that removing "g" prefix causes any problems?
I think they are by default off because you expect ls from BSD and not from GNU on Mac OS X by default. It might break other shell scripts. Rainer
Hi Rainer. Thanks for your quick reply. On Dec 22, 2007 9:41 PM, Rainer Müller <raimue@macports.org> wrote:
js wrote: [...]
Yes, I can easily avoid this by "port edit corefiles" and drop "program-prefix" but I thought if most of the MacPorts users wouldn't want "g", it might be better to fix this portfile.
No need to edit it manually, use port install coreutils +with_default_names This will install the binaries with the default names, i.e. without the prefix "g".
didn't notice that... Good to know, thanks!
So let me ask this, "Do you like to have gls, guniq in your /opt/local/bin? Is there any case that removing "g" prefix causes any problems?
I think they are by default off because you expect ls from BSD and not from GNU on Mac OS X by default. It might break other shell scripts.
I doubt it. I think almost all scripts starts with "#!/bin/bla" or "#!/usr/bin/bla" so installing GNUs in /opt/local/bin will not break anything, if you don't run a script like "sh somescript.sh" or "awk -f somescript.awk"
js wrote:
On Dec 22, 2007 9:41 PM, Rainer Müller <raimue@macports.org> wrote:
js wrote:
So let me ask this, "Do you like to have gls, guniq in your /opt/local/bin? Is there any case that removing "g" prefix causes any problems? I think they are by default off because you expect ls from BSD and not from GNU on Mac OS X by default. It might break other shell scripts.
I doubt it. I think almost all scripts starts with "#!/bin/bla" or "#!/usr/bin/bla" so installing GNUs in /opt/local/bin will not break anything, if you don't run a script like "sh somescript.sh" or "awk -f somescript.awk"
Imagine a bash script using ls, but it is expecting BSD ls, not GNU ls. It may fail because the options of these programs are different (except the POSIX subset of arguments). Rainer
On Dec 22, 2007 10:13 PM, Rainer Müller <raimue@macports.org> wrote:
js wrote:
On Dec 22, 2007 9:41 PM, Rainer Müller <raimue@macports.org> wrote:
js wrote:
So let me ask this, "Do you like to have gls, guniq in your /opt/local/bin? Is there any case that removing "g" prefix causes any problems? I think they are by default off because you expect ls from BSD and not from GNU on Mac OS X by default. It might break other shell scripts.
I doubt it. I think almost all scripts starts with "#!/bin/bla" or "#!/usr/bin/bla" so installing GNUs in /opt/local/bin will not break anything, if you don't run a script like "sh somescript.sh" or "awk -f somescript.awk"
Imagine a bash script using ls, but it is expecting BSD ls, not GNU ls. It may fail because the options of these programs are different (except the POSIX subset of arguments).
That makes sense, but in that case, shell scripter should specify exact bin path like LS=/bin/ls # BSD ls $LS -bsdoption something" instead. And you can easily force scripts to which ls to use like below. $ PATH=/usr/bin:/bin:/usr/sbin:/sbin somescript.sh In default case (g prefix), there's no easy way to fix this other than renaming bins in script or re-installing coreutils with "with_default_names" just as you suggested me.
But it have no doubt having "g" prefix is safer than installing bins without it. On Dec 22, 2007 10:30 PM, js <ebgssth@gmail.com> wrote:
On Dec 22, 2007 10:13 PM, Rainer Müller <raimue@macports.org> wrote:
js wrote:
On Dec 22, 2007 9:41 PM, Rainer Müller <raimue@macports.org> wrote:
js wrote:
So let me ask this, "Do you like to have gls, guniq in your /opt/local/bin? Is there any case that removing "g" prefix causes any problems? I think they are by default off because you expect ls from BSD and not from GNU on Mac OS X by default. It might break other shell scripts.
I doubt it. I think almost all scripts starts with "#!/bin/bla" or "#!/usr/bin/bla" so installing GNUs in /opt/local/bin will not break anything, if you don't run a script like "sh somescript.sh" or "awk -f somescript.awk"
Imagine a bash script using ls, but it is expecting BSD ls, not GNU ls. It may fail because the options of these programs are different (except the POSIX subset of arguments).
That makes sense, but in that case, shell scripter should specify exact bin path like
LS=/bin/ls # BSD ls $LS -bsdoption something" instead.
And you can easily force scripts to which ls to use like below.
$ PATH=/usr/bin:/bin:/usr/sbin:/sbin somescript.sh
In default case (g prefix), there's no easy way to fix this other than renaming bins in script or re-installing coreutils with "with_default_names" just as you suggested me.
On Dec 22, 2007, at 2:30 PM, js wrote:
On Dec 22, 2007 10:13 PM, Rainer Müller <raimue@macports.org> wrote:
js wrote:
On Dec 22, 2007 9:41 PM, Rainer Müller <raimue@macports.org> wrote:
js wrote:
So let me ask this, "Do you like to have gls, guniq in your /opt/ local/bin? Is there any case that removing "g" prefix causes any problems? I think they are by default off because you expect ls from BSD and not from GNU on Mac OS X by default. It might break other shell scripts.
I doubt it. I think almost all scripts starts with "#!/bin/bla" or "#!/usr/bin/ bla" so installing GNUs in /opt/local/bin will not break anything, if you don't run a script like "sh somescript.sh" or "awk -f somescript.awk"
Imagine a bash script using ls, but it is expecting BSD ls, not GNU ls. It may fail because the options of these programs are different (except the POSIX subset of arguments).
That makes sense, but in that case, shell scripter should specify exact bin path like
LS=/bin/ls # BSD ls $LS -bsdoption something" instead.
And you can easily force scripts to which ls to use like below.
$ PATH=/usr/bin:/bin:/usr/sbin:/sbin somescript.sh
In default case (g prefix), there's no easy way to fix this other than renaming bins in script or re-installing coreutils with "with_default_names" just as you suggested me.
Well, in a perfect world everything "should be" like it isn't in the real world. In a perfect world your shell script would have been prepared for 'seq' to not exist, too. ;) There are quite a few things that start to break if you use e.g. coreutils without the "g" prefix. Search the bug tracker if you are interested in what exactly breaks; I had tickets where the "install" program of coreutils behaved different and lead to errors in my ports -- very nasty to track down. If you want or have to GNU-ify your system, I'd recommend to either add aliases for the gnu tools (alias install='ginstall') or to symlink the gnutools to a new "bin" directory with the names you want them to have. Perhaps we could add this as a feature to the ports: Have a directory $prefix/gnu/[s]bin where the GNU tools would appear with their original name. Then the GNU fans could add those two directories to their path (before the standard macport directories). Regards, -Markus -- Dipl. Inf. (FH) Markus W. Weissmann http://www.macports.org/ http://www.mweissmann.de/
participants (3)
-
js
-
Markus Weissmann
-
Rainer Müller