James Y Knight (fuhm) wrote,
James Y Knight

How not to deprecate

I'd like to tell you a story today. (Okay, maybe that's a lie. It's really more of a rant.)

Perhaps you're familiar with the program "find". You can (ahem) find it on pretty much any unix system since the dawn of time. This story is about one particular "find" implementation: GNU find, and in particular, two of the predicates it supports: -path, and -ipath.

Sometime in 1993, GNU find 3.8 was released. This release had a few new interesting command line arguments, including "-path" and "-ipath".

On Dec 30, 1993 NetBSD got -path (with comment: "Merged our bugfixes with the 4.4BSD find from uunet")

On May 27, 1994, the history for find in FreeBSD's cvs repository starts. It had -path, but not -ipath.

On Feb 23, 2001, FreeBSD find added -ipath (amongst others)

Okay, now on to the fun part

On Aug 8, 2004, GNU find deprecates -path and -ipath at the request of Richard Stallman, and at the same time, adds two new names for the same functionality: -wholename and -iwholename. Why? Because he didn't like the names(!). The maintainer of find went along with the request. Furthermore, he states "Use of the predicate -ipath generates a warning about the deprecated status of -ipath. Use of the predicate -path does not, since -path is also implemented by the HP-UX operating system." The deprecation and new predicates make it into GNU find 4.2.0.

Okay...so, let me get this straight: it's considered important, in 2004 to keep compatibility with HP/UX, a dead commercial unix, and thus find doesn't print a warning for the now-deprecated "-path" predicate. But apparently nobody cares about keeping compatibility with 10 years worth of GNU find syntax (and, not coincidentally, 3 years of history in FreeBSD find), so it's okay to print annoying warnings about -ipath? Wow, just Wow. Nice priorities there. Cause, you know, there's nobody who'd ever want to write any script which works on GNU find 4.1 and GNU find 4.2 at the same time.

Oh, but it gets even better, now.

On Aug 17, 2007, a bug is reported against find:

The next revision of POSIX (at least, as of draft 3 of POSIX 200x, freely available to Austin group members), will mandate the addition of the -path expression.

Right now, GNU find has -path == -wholename, and -ipath == -iwholename. Of these four expressions, only -path is (going to be) POSIX-mandated, while only -ipath causes a deprecation warning. Perhaps it is time to reverse this, and make both -path and -ipath be warning-free, and instead make -wholename and -iwholename issue deprecation warnings (-wholename because the same thing can be achieved via a POSIX-mandated alternative, similar to how -d is deprecated in favor of POSIX-mandated -depth; and -iwholename for consistency with -wholename).

The patch was applied on 22 August 2007, to be released in GNU find 4.3.9.

On Sep 18, 2007, I installed Debian etch on a system, which has GNU find 4.2.28 rather than 4.1.20, and it starts printing loads of warnings: "find: warning: the predicate -ipath is deprecated; please use -iwholename instead.". I investigated the reason why the change was made, and get even more irritated. I then find that GNU find 4.3.9 reverses the change and get even more again irritated.

And finally, one last gem: GNU find 4.2 also introduced new extensions: "-warn" and "-nowarn" to "Turn warning messages on or off. The default behaviour corresponds to -warn if standard input is a tty, and to -nowarn otherwise." Wow, that almost sounds sensible. So all I have to do is use find < /dev/null to get rid of the warning in a compatible way. No, of course not, that would be way too easy. I'll give you one guess as to what warning message -nowarn doesn't suppress. Very funny, eh?

Please, if you write fundamental software that I depend on, try not to screw up like this. If you're going to make a change that has negative value to begin with, at least have the decency to do it right.

  • RCN redeems themselves to me

    RCN never replied to the email I sent them over a week ago. Seeing little other choice, I called them to cancel my Cable TV service last thursday. I…

  • RCN "Crushes" their customers

    Well, as foretold by my last posting, RCN has started encrypting all their digital channels in the Boston area now. I called tech support to find…

  • Sucks to be a RCN customer (soon)

    It seems like it's the beginning of the end for RCN transmitting in-the-clear digital channels. Starting last month in Chicago, they have turned off…

  • Post a new comment


    default userpic
    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.