bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] git-version-gen: include command name in one more diagnostic


From: Eric Blake
Subject: Re: [PATCH] git-version-gen: include command name in one more diagnostic
Date: Mon, 03 Jan 2011 17:13:56 -0700
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.7

On 01/03/2011 04:58 PM, Bruce Korb wrote:
> On 01/03/11 11:29, Jim Meyering wrote:
>>> Does that "git diff-index" really need to be run in a separate
>>> shell invocation?
>>>> dirty=`sh -c 'git diff-index --name-only HEAD' 2>/dev/null` || dirty=
>>
>> Yes.  As I recall, that was required in order to ensure that even when
>> the shell fails to find a "git" program, the stderr output
>> is redirected.
> 
> I do find that confusing since:
>    dirty=`git diff-index --name-only HEAD` 2>/dev/null
> really ought to be sufficient with any sane shell, but
> I'm no expert on weirdo stuff...

dirty=`sh -c 'git' 2>/dev/null` was overkill, but there are real shells
out there in common use where the current dirty=`(git) 2>/dev/null` is a
necessity.  For example, on FreeBSD 8.1:

$ /bin/sh -c 'v=`nonesuch` 2>/dev/null'
nonesuch: not found
$ /bin/sh -c 'v=`(nonesuch) 2>/dev/null`'
$

(Arguably, this should be pointed out as a bug to the BSD shell
implementers, because it's rather annoying behavior, but it is already
well-documented in the autoconf manual that you must be aware of this
portability pitfall whether or not it gets fixed in the future).

>> gnulib-tool and configure scripts do the same thing, but don't
>> try as hard as init.sh does to find the shell features I now require.

Very basic use of shell functions are more or less portable these days.
 Configure scripts happen to rely on more than basic features, and
therefore include some probes for various shell function pitfalls, such
as whether $1 gets corrupted after a function exits.  But it is still
rather easy to write scripts that don't trigger those pitfalls, and thus
easy enough to blindly use shell functions without having to do any
feature probing.  In other words, shell functions aren't the show
stopper, rather it is other basic POSIX features, such as $() instead of
``, where Solaris /bin/sh is such a major annoyance (generally, Solaris
/bin/sh tends to be the worst when it comes to compliance issues,
although I have been surprised from time to time with issues that
Solaris agrees with POSIX when BSD sh does not).  The autoconf manual
tries to document which shell function pitfalls are worth worrying about
in both a global sense, and from within an autoconf script where the
worst offenders are filtered out; if that documentation can be improved,
let us know.

-- 
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]