Perl Regex Removed From Grep in Mountain Lion(dirtdon.com)
dirtdon.com
Perl Regex Removed From Grep in Mountain Lion
http://www.dirtdon.com/?p=1452
62 comments
Since the introduction of the GPL3, there's been a steady purge of GNU software from OS X. This is why Apple's GCC, bash, etc. are stuck at old versions lacking a variety of useful features.
I'm kind of curious what they'll do about Emacs. It doesn't have a BSD-licensed counterpart like everything else they've removed... Maybe they'll just leave it out.
I'm kind of curious what they'll do about Emacs. It doesn't have a BSD-licensed counterpart like everything else they've removed... Maybe they'll just leave it out.
The built in Emacs is languishing along side the built-in bash. It's GNU Emacs 22.1 from "2007 April 13" (according to the man page) which is going on 5 years old at this point. The current release of Emacs is 24.2. You can get a binary of it here: http://www.emacsformacosx.com/
I already do this, even though I rarely use Emacs. Presumably those who work with it every day are far more hampered than me by a five-year-old installation. So my actual (rhetorical) question for Apple is whether there's a point to keeping around a version of Emacs so out of date that anyone using it would install their own copy anyway.
Since the introduction of the GPL3, there's been a steady purge of GNU software from OS X.
Is it all GNU software that's being purged, or just the GPLv3 licensed stuff? If the latter, I can't say I blame them. The former case can go either way but I guess it's good to future-proof early.
Is it all GNU software that's being purged, or just the GPLv3 licensed stuff? If the latter, I can't say I blame them. The former case can go either way but I guess it's good to future-proof early.
As far as I know, all GNU software went to GPLv3. Literally all of it. Even things with no substantial updates since 2007.
Isn't (one of) the points of the GPL that you cannot change the licensing of the software?
The copyright holder can do anything they want with the license of the software, including change it. What has been released under older versions of the license cannot be taken back, as millions of people received the software under the old license...so if you received a version of Emacs under GPL v2, you have every right to continue to distribute it under the terms of that license, and you have no ability to alter those terms (since you are not the copyright holder). But, the GNU foundation (who holds the copyright for Emacs and all GNU software) has every right to alter what license they distribute new versions of the software under.
A lot of people have a lot of weird superstitions about the GPL. It's probably useful to read the license sometime. It may also be useful to acquire a basic understanding of copyright law, if you are a software developer.
A lot of people have a lot of weird superstitions about the GPL. It's probably useful to read the license sometime. It may also be useful to acquire a basic understanding of copyright law, if you are a software developer.
Short answer: Not quite.
Long answer: One of the conditions for contributing code to the GNU project is assigning copyright to the FSF. That means they're legally the sole copyright holders for all software they distribute. The official reason for this is so they can pursue GPL violations in court without involving the actual authors of the code. It also permits them to change the license on any of their software. Finally, there are various reasons they might be able to do this anyway even if they didn't have the copyright assignment rule, so long as the new restrictions didn't conflict with whatever license the original software was distributed under.
Long answer: One of the conditions for contributing code to the GNU project is assigning copyright to the FSF. That means they're legally the sole copyright holders for all software they distribute. The official reason for this is so they can pursue GPL violations in court without involving the actual authors of the code. It also permits them to change the license on any of their software. Finally, there are various reasons they might be able to do this anyway even if they didn't have the copyright assignment rule, so long as the new restrictions didn't conflict with whatever license the original software was distributed under.
So, in theory, FSF can overnight change the license of all GNU softwares to shareware and sell them?
That's really fucked up. (I trust they won't do such a thing, but I didn't think such a thing could be possible)
That's really fucked up. (I trust they won't do such a thing, but I didn't think such a thing could be possible)
They can change how they license it from this moment on - but any copies they've already licensed continue to be licensed the way they were.
So if they licensed it to you as GPL, and then say "From now on, shareware is the way forward!" then you can continue to share yours as GPL, fork it, etc.
So if they licensed it to you as GPL, and then say "From now on, shareware is the way forward!" then you can continue to share yours as GPL, fork it, etc.
Well it's more likely than you might think over a span of a couple decades...
But, I think if they were to go rogue it would be a matter of forking a GPL-licensed version of the software and continuing development on that under an open license.
But, I think if they were to go rogue it would be a matter of forking a GPL-licensed version of the software and continuing development on that under an open license.
I don't think it is likely at all even in decades, and if they did they would be sued by loads of contributors for violating their binding promise to adhere with free software spirit in future licenses. You get some guarantees when you assign your copyright to the FSF.
And all this is ignoring that most GNU programs are licensed under a GPL variant and any future version, so they would not need the copyright to upgrade the license anyway.
And all this is ignoring that most GNU programs are licensed under a GPL variant and any future version, so they would not need the copyright to upgrade the license anyway.
I'm not saying it's a thing that's going to happen, just that you shouldn't have some blind faith that it won't ("I trust they won't do such a thing"). I'm pretty sure RMS would agree with the sentiment.
If you hold the copyright, new versions can be under whatever license you want. Old versions cannot have their license changed.
Basically all FSF-curated projects ask for contributors to assign copyright to the FSF. Which means the FSF ends up owning the rights to all the code, and can (as the copyright holder) switch to a different license for new versions.
We think that stinks and is unfair to contributors. We can understand giving a license to use, but complete ownership is unfair and unreasonable.
I very much blame them for their effort to ensure they can prevent users from modifying Free Software utilities on their own machines. What else would be the purpose of avoiding GPLv3? And breaking compatibility with user scripts and removing features in the process... Glad my macbook pro can still boot linux.
Doubt there was anyone at Apple concerned or willing enough to take the time/effort to port -P into bsdgrep.
Yeah, just use pcregrep
something i'm curious about - for linux fans who have made the switch, is osx an "acceptable unix"? people keep trumpeting the fact that it combines the best of both worlds, a seamless gui experience atop a full-fledged posix core complete with a bash prompt you can drop down to as easily as you can in linux, but philosophically it seems that for the little things like package management, command line utilities, etc., the experience is closer to cygwin than it is to linux proper - you can do it, sure, but it will involve falling back to a third-party ecosystem.
Oh, no, the experience is way better than Cygwin. Cygwin feels exactly like what it is a: bolt-on trying to emulate features and filesystem structures of a completely alien OS. It feels clunky, what you see when you do 'ls' at the 'root' of your filesystem is completely different to what you see when you 'dir' (or use the Windows Explorer.)
OS X is a completely different story. If you ever used BSD before, you know how it feels 'almost' like linux, barring a few differences. It's the same with OS X. Besides package management (which is greatly alleviated by Homebrew) and so-so integration of X applications, I can't say I miss my Ubuntu laptop at all.
OS X is a completely different story. If you ever used BSD before, you know how it feels 'almost' like linux, barring a few differences. It's the same with OS X. Besides package management (which is greatly alleviated by Homebrew) and so-so integration of X applications, I can't say I miss my Ubuntu laptop at all.
My Cygwin experience has been quite authentic actually.
But I was cheating, I'd use it for SSH and rxvt in combination with xming to establish a forwarded X session. (And x-mouse and alt-drag for that nearly authentic mouse behaviour.) Desperate times, desperate measures.
But I was cheating, I'd use it for SSH and rxvt in combination with xming to establish a forwarded X session. (And x-mouse and alt-drag for that nearly authentic mouse behaviour.) Desperate times, desperate measures.
I may be a Linux fan, but there you go: Mac OS X as Unix is inferior to Linux. Package management in Ubuntu is second to none, I have newer version of everything, sane terminal colors and fonts out of the box, I don't have to download monstrosity that is Xcode just to get a damn compiler, compiling some non-mainstream sources may not work out of the box.
> I don't have to download monstrosity that is Xcode just to get a damn compiler.
They fixed that. On newer OS X versions you can download the Command Line Tools (just 110mb) from Apple's website. You just need a free account: https://developer.apple.com/downloads
They fixed that. On newer OS X versions you can download the Command Line Tools (just 110mb) from Apple's website. You just need a free account: https://developer.apple.com/downloads
Why do I need a free account? What is the purpose of that?
I get a compiler from BSD, which is the source of Apple's code, without needing any account. Apple didn't need an account to get that code from BSD. Apple seems to do a disservice to the notion of the BSD license, which is not to impose restrictions on people (e.g. making them get a developer "account").
I get a compiler from BSD, which is the source of Apple's code, without needing any account. Apple didn't need an account to get that code from BSD. Apple seems to do a disservice to the notion of the BSD license, which is not to impose restrictions on people (e.g. making them get a developer "account").
It sounds like you need a reminder that OS X is not based on BSD, it's a different operating system that had a lot of BSD stuff grafted on to the side of it - like Windows, but moreso. Also, BSD doesn't provide a compiler - they use GNU's compiler, and are switching to Apple's compiler.
Yes, I did need that reminder. Memory is failing today. But... does it change my question? GNU gives me a compiler without making me sign up for an "account".
OSX is not BSD, but there's no way it could even think about calling itself "UNIX" and getting certified as such without all the BSD code they took.
What else is OS X? It's a kernel from CMU. And whiz bang graphics. And lots of annoyances.
OSX is not BSD, but there's no way it could even think about calling itself "UNIX" and getting certified as such without all the BSD code they took.
What else is OS X? It's a kernel from CMU. And whiz bang graphics. And lots of annoyances.
> GNU gives me a compiler without making me sign up for an "account".
What an outrageous thing... They force you to create a free account that wastes quite literally 6 minutes of your time... It's unacceptable, how dare they??!!1 (<-- sarcasm)
What an outrageous thing... They force you to create a free account that wastes quite literally 6 minutes of your time... It's unacceptable, how dare they??!!1 (<-- sarcasm)
Apple's current C compiler, clang, did not originate in the BSD project, but is primarily developed by Apple itself.
This is a good point. Although that word "primarily" is interesting.
Is Clang BSD-licensed?
Is Clang BSD-licensed?
"primarily", because the LLVM / clang project had its origins in academia (before the project and its team got acqui-hired by Apple), and because the project is open source, and thus still gets some amount of community contributions (probably not a huge proportion of the overall effort, though).
It's UIUC's license, which looks similar to BSD to me. They also have some MIT licensed code.
http://llvm.org/docs/DeveloperPolicy.html#license
Essentially, yes. It's NCSA-OSL which is based on MIT, which is based on BSD: http://en.wikipedia.org/wiki/Clang
Many projects use Clang/LLVM for their OpenCL implementations.
Many projects use Clang/LLVM for their OpenCL implementations.
Haven't you heard? If you have nothing to hide, you have nothing to fear from a surveillance state in which even your use of a compiler is closely monitored and tagged.
And if I may add, I hate the fact that I have to put credit card information on this free account.
Package management in Ubuntu is not second to none, it is second to Debian. Dont get me wrong Ubuntu has done a lot of wonderful things, but lets give credit where credit is due...
I'd actually disagree on this point.
Ubuntu has introduced a number of refinements to the dpkg world that have been pretty good.
Most useful, in my mind, is their set of tools for working with PPAs. They're much simpler to run than setting up an entire new repository of packages.
Ubuntu has introduced a number of refinements to the dpkg world that have been pretty good.
Most useful, in my mind, is their set of tools for working with PPAs. They're much simpler to run than setting up an entire new repository of packages.
Seriously? You think that PPAs and your other unnamed improvements tower over the apt package management system? Without PPAs apt-get would be yet another kludgy package management system? Sure apt-add-repository is a nice time saver but how hard is:
echo deb http://repo.net/ unstable main >> /etc/apt/sources.list
With respect to PPAs, I'm not speaking from a user perspective, but from that of a sysadmin having to maintain mirrors. PPAs are just easier than setting up all the key signing and mirror infrastructure.
Yeah, apt and dpkg are great compared to what else was available a decade ago. But that doesn't mean that Ubuntu's additions, however incremental, are worthless or somehow inferior to Debian. Incremental gains are still gains.
Yeah, apt and dpkg are great compared to what else was available a decade ago. But that doesn't mean that Ubuntu's additions, however incremental, are worthless or somehow inferior to Debian. Incremental gains are still gains.
I'm confused about PPAs and setting up a mirror infrastructure. What mirror infrastructure? What key signing is involved in a mirror that is not involved in signing packages for a PPA?
Ubuntu's additions are nice. But they are minor improvements to apt/dpkg. Without them apt and dpkg would still be phenomenal.
Ubuntu's additions are nice. But they are minor improvements to apt/dpkg. Without them apt and dpkg would still be phenomenal.
I administer a small number of systems and deploy custom packages to all of those.
Running a custom mirror, signing packages, managing keyrings on the mirror, and getting them on all systems is nontrivially harder than using a PPA and associated scripts.
Now, I run a mix of Ubuntu and Debian systems. I don't use PPAs that much, but when I do they're just plain easier.
Yes, it's an incremental gain, but that's a gain. It makes them better. They weren't first, but they're innovating. Sometimes, the "innovations" aren't fantastic especially some of the more harebrained stuff on desktop (PulseAudio, avahi). But no longer is Ubuntu just a Debian rip-off: They're producing new and useful additions.
The relative merits are debatable, and so I'm not going to continue that thread. In the end, it boils down to X + epsilon > X, for any epsilon > 0.
Running a custom mirror, signing packages, managing keyrings on the mirror, and getting them on all systems is nontrivially harder than using a PPA and associated scripts.
Now, I run a mix of Ubuntu and Debian systems. I don't use PPAs that much, but when I do they're just plain easier.
Yes, it's an incremental gain, but that's a gain. It makes them better. They weren't first, but they're innovating. Sometimes, the "innovations" aren't fantastic especially some of the more harebrained stuff on desktop (PulseAudio, avahi). But no longer is Ubuntu just a Debian rip-off: They're producing new and useful additions.
The relative merits are debatable, and so I'm not going to continue that thread. In the end, it boils down to X + epsilon > X, for any epsilon > 0.
Doesn't Ubuntu have apt as well though? Ubuntu's package management may have come from Debian, but that doesn't make it inferior.
It sounds to me like you're trying to make a different argument: that Debian's package management was a bigger deal, in some sense, than Ubuntu's incremental improvements on it.
It sounds to me like you're trying to make a different argument: that Debian's package management was a bigger deal, in some sense, than Ubuntu's incremental improvements on it.
Ubuntu's package management system is apt and dpkg. Apt and dpkg were Debian projects long before ubuntu was even a whisper. Ubuntu uses Debian's pakage management system, it does not have it's own system.
Yes, that's what I thought. Ubuntu uses Debian's system with minor changes. If you want to say Ubuntu's package management is second (inferior) to Debian's, you need to show the changes are bad, not minor.
Ubuntu does not have a package manager of its own. It uses Debian's. Ubuntu was the second guest to arrive at the apt party.
So what? Ubuntu has package management. It is a superior experience to the package management in Debian. (Or so I assume, since you have not disputed it.) Therefore it is not true that package management in Ubuntu is second to Debian.
I'm probably going to tap out here, because this doesn't seem like it's going to become productive.
I'm probably going to tap out here, because this doesn't seem like it's going to become productive.
Well, second to none of the operating systems I am using (also includes Mac OS X and couple of Windows versions). The point being is that package management on OS X is not on the level of Ubuntu (or Debian for that matter).
Its not close to GNU tools but its very true to Unix tools. Many of the tools have the same options (if not the same man pages) as their Free/Open/NetBSD versions.
ah - that's an interesting distinction. i guess linux has gotten me subconsciously used to thinking of the gnu tools as the current unix standard.
but (by recursive definition) GNU is Not Unix
I write a lot if code targeting Linux on OSX. Mostly Java (with some JNI) and C. Sure there are some bits that have to be different. Perhaps 5%? But once that is abstracted away I can do almost all work in OSX then build on Linux.
Of course a decade of writing portable C across BSD and Linux systems might make this a bit easier for me than others. And it's worth it to me to avoid the Linux desktop experience (which I did use as my primary desktop from 1996 til about 2 years ago).
Of course a decade of writing portable C across BSD and Linux systems might make this a bit easier for me than others. And it's worth it to me to avoid the Linux desktop experience (which I did use as my primary desktop from 1996 til about 2 years ago).
These sorts of issues (primarily related to auxiliary functions in grep, sed, etc) can cause portability issues when developing locally for linux systems, but no worse thanks, say, writing for fedora on an Ubuntu box. Brew is okay but a bit sparse. For me I mostly miss Gnome
I think it's clear it's going to get a lot worse with Apple purging GNU utils.
It is worse. Fedora is Linux. OS X is BSD.
This contradicts a clear historical trend in which Perl regex syntax and POSIX regex syntax (not the same) are being more widely adopted as time passes. It's a definite step backward.
This wasn't a deliberate decision on Apple's part to remove this particular functionality. Rather, they switched to a different implementation of grep (BSD instead of GNU) and it leaves out PCRE support by default. If word of this gets back to whoever made the change, it should be a simple matter to reenable it for future versions of OS X.
This bit me in our "golden file" checking portion of our product's test suite. I moved the golden file checking regex to a Perl script. Apple's obsession with removing GNU utilities has been annoying but I suppose the test suite should have taken grep portability problems into account.
Yes it should have. You could still run into problems as PCRE regexes are not quite the same as Perl regexes. Why not just check for and use pcregrep?
[deleted]
BSD grep has been imported to 9.0-CURRENT on July 22, 2010. It has been obtained from the OpenBSD and the FreeGrep projects to make it appropriate for our needs to provide GNU compatibility and let ports build without problems. GNU compatibility is almost 100%, the only missing feature is -P (--perl-regex), which is not possible to support without having PCRE in base system and anyway, it was disabled in GNU grep for the same reason.
Somewhat ironic as OS X includes PCRE. Not sure why Apple didn't stay with GNUgrep.