From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 114596 invoked by alias); 29 Jan 2016 14:53:18 -0000 Mailing-List: contact cygwin-apps-help@cygwin.com; run by ezmlm Precedence: bulk Sender: cygwin-apps-owner@cygwin.com List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps@cygwin.com Received: (qmail 114571 invoked by uid 89); 29 Jan 2016 14:53:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=Crazy, f, UD:info, dollar X-HELO: limerock02.mail.cornell.edu Received: from limerock02.mail.cornell.edu (HELO limerock02.mail.cornell.edu) (128.84.13.242) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 29 Jan 2016 14:53:16 +0000 X-CornellRouted: This message has been Routed already. Received: from authusersmtp.mail.cornell.edu (granite3.serverfarm.cornell.edu [10.16.197.8]) by limerock02.mail.cornell.edu (8.14.4/8.14.4_cu) with ESMTP id u0TErDaS029653 for ; Fri, 29 Jan 2016 09:53:14 -0500 Received: from [10.13.22.4] (65-112-130-194.dia.static.qwest.net [65.112.130.194]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.14.4/8.12.10) with ESMTP id u0TErCGu014501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 29 Jan 2016 09:53:13 -0500 Subject: Re: [PATCH setup 0/3] Setup replacement for incver_ifdep To: cygwin-apps@cygwin.com References: <87lhb8htrh.fsf@Rainer.invalid> <561FA783.900@dronecode.org.uk> <87oag0qad3.fsf@Rainer.invalid> <20151019154100.GB18989@calimero.vinschen.de> <87io62hiz6.fsf@Rainer.invalid> <20151020102150.GF5319@calimero.vinschen.de> <56532D34.4090102@dronecode.org.uk> <87bnakmtqc.fsf@Rainer.invalid> <56549774.2090008@dronecode.org.uk> <87ziy3utip.fsf@Rainer.invalid> <20151126101120.GA6674@calimero.vinschen.de> <56AA50E4.2040105@dronecode.org.uk> <56AA6128.8030700@cornell.edu> <56AA74BE.4010208@redhat.com> <56AA7755.8060801@cornell.edu> <56AA787A.9080503@redhat.com> <56AB75A4.6060101@dronecode.org.uk> From: Ken Brown Message-ID: <56AB7CD7.5000101@cornell.edu> Date: Fri, 29 Jan 2016 14:53:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56AB75A4.6060101@dronecode.org.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-01/txt/msg00053.txt.bz2 On 1/29/2016 9:22 AM, Jon Turney wrote: > On 28/01/2016 20:22, Eric Blake wrote: >> On 01/28/2016 01:17 PM, Ken Brown wrote: >>>>> install-info $f /usr/share/info/dir || >>>>> install-info --entry="* $$f ($f): $$f" $$f /usr/share/info/dir >>>>> >>>>> First, what do those double dollar signs mean? >>>> >>>> If this is from a Makefile snippet, it says that $f is a make variable, >>>> while $$ turns into a literal $f for the shell that make invokes >>> >>> It's not a Makefile snippet; it's a snippet from a bash shell >>> script. Here's more context: >>> >>> for f in /usr/share/info/*; do >>> case "$f" in >>> *\**) >>> ;; >>> */dir|*/dir.info*) >>> ;; >>> *-[0123456789]*) >>> ;; >>> *) >>> install-info $f /usr/share/info/dir || >>> install-info --entry="* $$f ($f): $$f" $$f >>> /usr/share/info/dir >>> ;; >>> esac >>> done >>> >>> It looks to me like all those double dollar signs will just get >>> expanded to the PID of the bash process, so that the second >>> install-info command is nonsense. But maybe I'm missing something. >> >> Oooh, scary. Yeah, it looks like utter nonsense, as that would indeed >> give the PID of bash followed by a literal f, but who wants to look up >> info of '1234f'? I wonder if someone writing the script copied >> incorrectly from a Makefile? > > Crazy. I didn't add this part, so I guess it's been there for a long time. > >>> Second, why is the second line needed, i.e., under what circumstances >>> would it be expected to succeed after the first install-info command >>> failed? >> >> Sadly, I don't know install-info enough to answer that one. > > I think the first install-info command would fail if the .info file is > missing a START-INFO-DIR-ENTRY/END-INFO-DIR-ENTRY block, in which case > install-info should fail with a 'install-info: warning: no info dir > entry in `xxx.info'' > > Since such a .info file is apparently valid (although I don't think we > have any instances of such), I guess the nonsense after the || should be > fixed to use '$f' correctly. I have a few instances of those files on my system: install-info: warning: no info dir entry in `/usr/share/info/automake-history.info.gz' install-info: warning: no info dir entry in `/usr/share/info/automake-history1.12.info.gz' install-info: warning: no info dir entry in `/usr/share/info/automake-history1.13.info.gz' install-info: warning: no info dir entry in `/usr/share/info/texdraw.info.gz' But I'm not convinced that we need to worry about them. It could be that they're intended to be cited from other info files but not to be listed in the top level directory. I would say that if an info file lacks a START-INFO-DIR-ENTRY/END-INFO-DIR-ENTRY block, we should assume that its author didn't want it listed in the directory. Ken