From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id D0AA4431FAF for ; Sun, 4 Nov 2012 21:27:07 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] autolearn=disabled Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZBn+WYr7JpI for ; Sun, 4 Nov 2012 21:27:07 -0800 (PST) Received: from foo.net (70-36-235-136.dsl.static.sonic.net [70.36.235.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by olra.theworths.org (Postfix) with ESMTPS id 1733D431FAE for ; Sun, 4 Nov 2012 21:27:07 -0800 (PST) Received: from foo.net (localhost [127.0.0.1]) by foo.net (8.14.5+Sun/8.14.5) with ESMTP id qA55R4m9013730; Sun, 4 Nov 2012 21:27:04 -0800 (PST) To: Jani Nikula Subject: =?UTF-8?B?UmU6IFtQQVRDSCAwNS8xMF0gaW5zdGFsbDogY2hlY2sgZm9yIG5v?= =?UTF-8?B?bi1TeXNWIHZlcnNpb24gKFNvbGFyaXMgc3VwcG9ydCkg?= In-Reply-To: Your message of "Sun, 04 Nov 2012 23:31:02 +0200." <87d2ztf42x.fsf@nikula.org> Date: Sun, 04 Nov 2012 21:27:04 -0800 Message-ID: <13729.1352093224@foo.net> From: Blake Jones X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (foo.net [127.0.0.1]); Sun, 04 Nov 2012 21:27:04 -0800 (PST) Cc: notmuch@notmuchmail.org X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 05:27:08 -0000 > > +INSTALL="install" > > +printf "Checking for working \"install\" program... " > > +mkdir _tmp_ > > This doesn't feel like a hot idea. Out of curiosity, why not? An "install" that behaves as expected is one of the first things that an autoconf-generated "configure" looks for. Now, autoconf-configure implements that check using some assumptions about where things are on different operating systems, but that sort of check runs the risk of becoming stale (see below). > Don't tell me you'd need to create a compatibility script for using > mktemp --tmpdir too... Yes I would, if it were used; not all the world's a GNU. But in the case of mktemp, the widely available "-p" and "-t" options seem to get you most of the way there. The SVR4 "install" in Solaris' /usr/sbin is different enough from the BSD/GNU versions that I wouldn't want to try to emulate it with a wrapper. > Or how about just always using ginstall on Solaris? I'd rather not do that. With the old UCB tools having been EOL'ed [1], /usr/ucb/install (which would have worked) will be going away. There is an open bug in the Sun bug tracking system about moving GNU install to /usr/bin/install, specifically motivated by this change. So while I don't know if/when that bug will be fixed, I would guess [2] that a future release of Solaris may have a BSD/GNU-compatible version of "install" in the default $PATH. Blake [1] http://www.oracle.com/technetwork/systems/end-of-notices/eonsolaris11-392732.html [2] Caveat: I work for Oracle in the Solaris kernel group, but I am not speaking for my employer.