From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29838 invoked by alias); 6 Feb 2016 14:29:23 -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 29805 invoked by uid 89); 6 Feb 2016 14:29:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=signs, bash, Sadly, f X-HELO: limerock04.mail.cornell.edu Received: from limerock04.mail.cornell.edu (HELO limerock04.mail.cornell.edu) (128.84.13.244) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 06 Feb 2016 14:29:17 +0000 X-CornellRouted: This message has been Routed already. Received: from authusersmtp.mail.cornell.edu (granite4.serverfarm.cornell.edu [10.16.197.9]) by limerock04.mail.cornell.edu (8.14.4/8.14.4_cu) with ESMTP id u16ETF70027879 for ; Sat, 6 Feb 2016 09:29:15 -0500 Received: from [10.13.22.4] (50-192-26-105-static.hfc.comcastbusiness.net [50.192.26.105]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.14.4/8.12.10) with ESMTP id u16ETDDw018708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sat, 6 Feb 2016 09:29:14 -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> <56AB7CD7.5000101@cornell.edu> From: Ken Brown Message-ID: <56B6033C.3050407@cornell.edu> Date: Sat, 06 Feb 2016 14:29: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: <56AB7CD7.5000101@cornell.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-02/txt/msg00001.txt.bz2 On 1/29/2016 9:53 AM, Ken Brown wrote: > 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. Jon, any further thoughts about this? texinfo-6.1 has just been released, so I can go ahead with adding the postinstall script as soon as we decide what it should do in the case of a missing START-INFO-DIR-ENTRY/END-INFO-DIR-ENTRY block. Kenb