From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 14777 invoked from network); 2 Jan 2024 18:17:33 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 2 Jan 2024 18:17:33 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20210803; t=1704219453; b=D1SIco5HQraaMVrzk4VagLfjFXHq59P9TTkftj2RDvjxxv8GvuimMWS2xNDuo/MrHj1dB9+J/5 Or81hnniaC7awFO9Q6srCC2V5vecsQ/hATwu2ICxn7YF97Ci++/XPUWTYfsn1HpZ8nJDTaLIVr 1n6qHMnUrDK7Mu0WnwIUn19XACEjQ+opYEzbXzHoau/QHk+Zsk7M6xdaF3fE02MgVCV13N00YL ZE/ynXqVADPZL8n6JhWhkk28NJ0/qj1J8dYtGHySDYXspYHVpOxIPh5YdEZ56nIyBaaQ5Cuxqc 1Mqp/gOGJvib3+F1Xe39ce5ROBgPUFZia623lG1YT+J/HQ==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (mta01.eastlink.ca) smtp.remote-ip=24.224.136.30; dmarc=none header.from=eastlink.ca; arc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=zsh.org; s=rsa-20210803; t=1704219453; bh=i1umXqqvx6TTUR96bF1s6+0USgjGVCZVedwXO/9s92E=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:In-Reply-To:From:References:To:Subject:MIME-Version:Date: Message-ID:Content-Type:DKIM-Signature; b=Fov/1cqcoj2qVc2Idz6/vlTDV01ll/lcc1UiO2/KhmA8nKU8VMY7fvHNY3hudnQC5pgXN2Odjs lauvkXOG2PG0KlDxs+wC+nWB1ZLnvr2NfnC2y2nQyNrq25tpvPghbJaM12XV8AMKCuzxOr4OsN z8VTTYSrnBlF17mh65t8DmmnF1G7lM2FdIx0MEfh1ss8OnenGdke5BEJxtbvipb1qe6sn4r8rB z0tjofWGWHPPDgl+YsQ+y2lrFYWuoCD++HvYsBRDrAnJ3n0iDjJI91CLSpNDLf/iEKlFf7v8yy uYDx4ChocjEnq7KtSb/M+yLwp3ps579YvrPFYax4hoMOSQ==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20210803; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:In-reply-to:From:References:To: Subject:MIME-version:Date:Message-id:Content-type:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=ykSGBuMr5fVvXQEj2FDaYn0fYu8aWxHWJT6KdMFESs4=; b=LX/xSL4VUsPP6wNDfEdxoyvwAS bnwEfhYEM5srkIE69KlvbyxfpyCDlhMTqA5wM38/AgeFOVEVNWUoqS8VkTnp6PaJr4gQv1aEyTLis ay2Ho77ubX+EG4JwyeHWXvK7d4I5S+9qzI47ntDsW9/gRy688PRFCB/MC5V3Vn4KxbP6bXEk5/eGf dZH8M99sM0TSjZMMOFeuyXvMJO0AimS8zgY8KZuMiIntM54kzjou92Ewn2v+GSovMYgZeygTpIJmC TkxS2owXd8bPH0vh8T+MhUkjQHCk8vTjxq1MKqIsb3qgrD4Mk6i3akCUAG5V0/TFXVuM5A8c198Sd +7bEaq6A==; Received: by zero.zsh.org with local id 1rKjKW-000J5Q-11; Tue, 02 Jan 2024 18:17:32 +0000 Authentication-Results: zsh.org; iprev=pass (mta01.eastlink.ca) smtp.remote-ip=24.224.136.30; dmarc=none header.from=eastlink.ca; arc=none Received: from mta01.eastlink.ca ([24.224.136.30]:59865) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) id 1rKjJl-000IKz-JP; Tue, 02 Jan 2024 18:16:48 +0000 Received: from csp02.eastlink.ca ([71.7.199.167]) by mta01.eastlink.ca ([24.224.136.30]) with ESMTPS id <0S6N001DNBM7EW60@mta01.eastlink.ca> for zsh-users@zsh.org; Tue, 02 Jan 2024 14:16:44 -0400 (AST) Received: from [192.168.0.11] (host-24-207-19-13.public.eastlink.ca [24.207.19.13]) by csp02.eastlink.ca ([71.7.199.167]) with ESMTPSA id KjJjrvz6tW7C8KjJkr4HqM (version=TLSv1_2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256); Tue, 02 Jan 2024 14:16:44 -0400 X-Authority-Analysis: v=2.4 cv=CpB5MF0D c=1 sm=1 tr=0 ts=6594530c a=e7T7DzMKK1R988ZCg0wLyw==:117 a=e7T7DzMKK1R988ZCg0wLyw==:17 a=r77TgQKjGQsHNAKrUKIA:9 a=ZkvPBPLQAAAA:8 a=fg08nNF1BwqfbDyxfgcA:9 a=QEXdDO2ut3YA:10 a=Yj-e3bdoa9sA:10 a=pGLkceISAAAA:8 a=a2sWrJy5LiOZYgZwsmEA:9 a=G7JsxDJYIE7PYUeH:21 a=_W_S_7VecoQA:10 a=SFr2u9Cu4sbnRqnMvguH:22 X-Vade-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdegfedggedvucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecugfetuffvnffkpffmpdfqfgfvnecuuegrihhlohhuthemuceftddtnecunecujfgurheptgfkffggfgfuvfhfhfgjsegrtderredtvdejnecuhfhrohhmpeftrgihucetnhgurhgvfihsuceorhgrhigrnhgurhgvfihssegvrghsthhlihhnkhdrtggrqeenucggtffrrghtthgvrhhnpeffgfffkedujeejgfduieekudeiudffuefhfeduieeuvedtveefheekhefhkedujeenucffohhmrghinhepshhouhhrtggvfhhorhhgvgdrihhonecukfhppedvgedrvddtjedrudelrddufeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpedvgedrvddtjedrudelrddufedphhgvlhhopegludelvddrudeikedrtddruddungdpmhgrihhlfhhrohhmpehrrgihrghnughrvgifshesvggrshhtlhhinhhkrdgtrgdpnhgspghrtghpthhtohepvddprhgtphhtthhopeerredprhgtphhtthhopeiishhhqdhushgvrhhsseiishhhrdhorhhgpdhgvghtqdgkihhprfgrshhsfigupehtrhhuvg X-Vade-Score: 0 X-Vade-State: 0 X-EL-AUTH: rayandrews@eastlink.ca Content-type: multipart/alternative; boundary="------------hRzRyjRJH0cXEt4Mu9Jj5HGm" Message-id: <30a2a6d7-5125-4d9d-a95d-9f110bd736f0@eastlink.ca> Date: Tue, 2 Jan 2024 10:16:43 -0800 MIME-version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: zmv exits from function Content-language: en-US To: zsh-users@zsh.org References: <69024621-9e60-474f-9c32-4edaecc3ff68@eastlink.ca> <1760392789.1738022.1704196204791@mail.virginmedia.com> <4350097c-ee24-42c5-8b12-c0cccb2f6542@eastlink.ca> From: Ray Andrews In-reply-to: X-Seq: 29403 Archived-At: X-Loop: zsh-users@zsh.org Errors-To: zsh-users-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-users-request@zsh.org X-no-archive: yes List-Id: List-Help: , List-Subscribe: , List-Unsubscribe: , List-Post: List-Owner: List-Archive: This is a multi-part message in MIME format. --------------hRzRyjRJH0cXEt4Mu9Jj5HGm Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2024-01-02 09:47, Mark J. Reed wrote: > > > https://zsh.sourceforge.io/Doc/Release/Shell-Grammar.html#Complex-Commands > Thanks.  Man, I wish there were more examples :( > Well, no.  It runs the code on the left, and then when it finishes it > runs the code on the right. That's the extent of the `always` > functionality. What makes it special is that the code on the right > runs even if the code on the left blows up somehow. Yeah, I think I get it.  But the 'memo' has to be there -- zmv must ... or maybe not ... when zmv returns, if the 'always' keyword (sorta) it there, then it knows to not crash but to execute the following code.  So, yeah, it could be seen as 'linear'. > > It's similar to a feature called the "finally block" in other > languages, where it's usually attached to the exception-handling > mechanism; something like `try { start here } catch (ErrorType) { do > this if the previous block failed this particular way } finally { run > this no matter what }`.  Because of that similarity, the code on the > left of the `always` is called the "try block" or "try list", even > though zsh doesn't use the keyword "try". The code on the right is > called the "always block" or "always list". That's interesting.  So this isn't some desperate hack -- that kind of functionality is standard to some degree.  Ok, good to know. But as I said, it sure looks strange the first time you see it.  Reading a bit more, I see it's got other uses than preventing meltdowns. Cool. > > If you want the world not to be blown up, you can set TRY_BLOCK_ERROR > to 0, and then zsh will forget that anything went wrong and continue > about its business. I myself hardly ever want Ragnarok, so next time I run into this sort of issue, I've got that to defuse it.  Thanks Mark.  Hey, I wonder if that could be an option? NO_MELTDOWNS=on --------------hRzRyjRJH0cXEt4Mu9Jj5HGm Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


On 2024-01-02 09:47, Mark J. Reed wrote:

Thanks.  Man, I wish there were more examples :(


Well, no.  It runs the code on the left, and then when it finishes it runs the code on the right. That's the extent of the `always` functionality. What makes it special is that the code on the right runs even if the code on the left blows up somehow.
Yeah, I think I get it.  But the 'memo' has to be there -- zmv must ... or maybe not ... when zmv returns, if the 'always' keyword (sorta) it there, then it knows to not crash but to execute the following code.  So, yeah, it could be seen as 'linear'. 

It's similar to a feature called the "finally block" in other languages, where it's usually attached to the exception-handling mechanism; something like `try { start here } catch (ErrorType) { do this if the previous block failed this particular way } finally { run this no matter what }`.  Because of that similarity, the code on the left of the `always` is called the "try block" or "try list", even though zsh doesn't use the keyword "try". The code on the right is called the "always block" or "always list".
That's interesting.  So this isn't some desperate hack -- that kind of functionality is standard to some degree.  Ok, good to know. But as I said, it sure looks strange the first time you see it.  Reading a bit more, I see it's got other uses than preventing meltdowns.  Cool.

If you want the world not to be blown up, you can set TRY_BLOCK_ERROR to 0, and then zsh will forget that anything went wrong and continue about its business.

I myself hardly ever want Ragnarok, so next time I run into this sort of issue, I've got that to defuse it.  Thanks Mark.  Hey, I wonder if that could be an option? NO_MELTDOWNS=on


--------------hRzRyjRJH0cXEt4Mu9Jj5HGm--