From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8494 invoked by alias); 19 Dec 2016 16:56:54 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 22241 Received: (qmail 8264 invoked from network); 19 Dec 2016 16:56:54 -0000 X-Qmail-Scanner-Diagnostics: from mta04.eastlink.ca by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(24.224.136.10):SA:0(-3.8/5.0):. Processed in 1.030555 secs); 19 Dec 2016 16:56:54 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-3.8 required=5.0 tests=RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,RP_MATCHES_RCVD,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: rayandrews@eastlink.ca X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _spf.eastlink.ca designates 24.224.136.10 as permitted sender) X-Authority-Analysis: v=2.2 cv=HKaBLclv c=1 sm=1 tr=0 a=28Ntk8jg+Dho8ABWn/CRtA==:117 a=28Ntk8jg+Dho8ABWn/CRtA==:17 a=N659UExz7-8A:10 a=MKmxFTzhTxOn53nBChoA:9 a=pILNOxqGKmIA:10 X-EL-IP-NOAUTH: 24.207.16.108 Subject: Re: trapped in bash To: zsh-users@zsh.org References: <58540944.3030706@eastlink.ca> <20161216215117.GF2023@pug.qqx.org> <58546D36.5050908@eastlink.ca> <161216150556.ZM4016@torch.brasslantern.com> <58559FC0.3080501@eastlink.ca> <161217124354.ZM7815@torch.brasslantern.com> <5855BEF2.6090208__18199.534857604$1482015164$gmane$org@eastlink.ca> <20161218150628.GB9158@fujitsu.shahaf.local2> <5856B133.9010602@eastlink.ca> <20161219003219.GA21509@fujitsu.shahaf.local2> <161218183056.ZM5304@torch.brasslantern.com> <9da2ae82-ac3f-6ee3-5452-5a008cf129e7@eastlink.ca> <161218214811.ZM5814@torch.brasslantern.com> From: Ray Andrews Message-id: Date: Mon, 19 Dec 2016 08:26:43 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0 MIME-version: 1.0 In-reply-to: <161218214811.ZM5814@torch.brasslantern.com> Content-type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: 7bit On 18/12/16 09:48 PM, Bart Schaefer wrote: > On Dec 18, 8:29pm, Ray Andrews wrote: > } > } Not for me to say, but it seems to me that the simple fact that a file > } exists or does not exist is simple enough to determine > > Well, yes. > > The shell finds the file, because it's responsible for path search. Exactly, I'd expect zsh to handle that with an appropriately helpful message, but past that point I quite understand that it's not the shell's affair. Mind, even subsequent error messages might be preceded by 'execve()' reports: ...' or something like that, it would just make further diagnosis a bit faster. In my situation I'd be angling for something like: "Error: binary file '/aa/bb/xxx' is not executable. execve() reports error #54321: "file not found". > > It then forks, and the child process passes the full path to execve(), > which replaces the child shell with the kernel code that is supposed > to start up the new executable. > > That kernel code then fails for whatever reason -- in this case, it's > because the 32-bit library is not found -- and returns a nonzero > numeric exit code to the parent shell. > > The parent shell prints the message associated with that error code. > It isn't responsible for guessing what caused the error; there could > for example have been additional rounds of finding and exec'ing other > paths of which the parent has no knowledge, before a final exit. >