From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: zsh-workers-return-43691-ml=inbox.vuxu.org@zsh.org X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from primenet.com.au (ns1.primenet.com.au [203.24.36.2]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id fccc1e85 for ; Tue, 16 Oct 2018 02:17:02 +0000 (UTC) Received: (qmail 15312 invoked by alias); 16 Oct 2018 02:16:48 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: List-Unsubscribe: X-Seq: 43691 Received: (qmail 28972 invoked by uid 1010); 16 Oct 2018 02:16:48 -0000 X-Qmail-Scanner-Diagnostics: from out3-smtp.messagingengine.com 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(66.111.4.27):SA:0(-2.6/5.0):. Processed in 6.290301 secs); 16 Oct 2018 02:16:48 -0000 X-Envelope-From: d.s@daniel.shahaf.name X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= daniel.shahaf.name; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:subject :references:date; s=fm1; bh=NQFD7Nw5e7/NsMFfEgzbEYZt+hvivQmX50Gk DLCi1gY=; b=fifP+75vUA1iO4ybINSDcMOleNV1LhcTYFa2stsixU+565rmjhCd I/wqHsLYsWrsp/tZdn6zhIeoW+Imj5fFwDf8tcUJHs9zDMJ9LiO87HMuh7mOtgkE Q3NR/wTIGEbirpKuFHYE6lo0hQrMKwBoZHW9nThpp0SlHZJHBD2xmazz8XcDwyxX Ry2TJBUyYQNw7SUWpnc+KqB4x0KdViTYz/IRO3f9fBBCgCa4siURx0/z7cyYzlM7 iPWveqFVe7WSDJJNzjAiB7EGv/tyOQB1JWEGY2qX8kbOfbwRoFuayFQYATKb0yUV M91W8dkvCK7Cxp6upcUCKUc/yCv5Vu76Rg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=NQFD7Nw5e7/NsMFfEgzbEYZt+hvivQmX50GkDLCi1 gY=; b=ytfKDChlAABKdILlowwt2W60Vtrx6llfHXnBX+Tw8s9VW5UqMMkZ1xCtL YT/IPdlyS7sKGuIOqYPmyIkZ3rVEm90vMq24VGrfJ8nLrLAM9fqzJNipngBzxAZi it8226ZkBas8xvKErdrPRbtT02znxgZDxYEOObB6rWul1e52s0Q0LCWlL5PFTPFW JmRt+gAKrrJISv4uBmkUTDPJ5YLkPYSsJv7ebvMAUemBFf6qnbtTUiYwa3MLEmnF i9gSYNBvjJIECuWp46O3jqz5tKRLJa8P6y1D9F26pZsDjYKkUknn2WtvERwAsgFC 1XS859sWYnOyddNkCdJMOBjn0mW9w== X-ME-Sender: X-ME-Proxy: Message-Id: <1539655655.1396893.1543274624.1FAEEE73@webmail.messagingengine.com> From: Daniel Shahaf To: zsh-workers@zsh.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-cc4e8f33 In-Reply-To: Subject: Re: Documentation about Multios is misleading, and perhaps untrue References: <8B27B616-9DDE-4A04-AA05-2EA7234051A0@dana.is> <1539290119.4188692.1539037288.272C51E2@webmail.messagingengine.com> <20181012083056eucas1p1254a57c82328a4e9349c3a6f8997a0e6~cz0JMnlc50925009250eucas1p10@eucas1p1.samsung.com> Date: Tue, 16 Oct 2018 02:07:35 +0000 Tom Boyd wrote on Mon, 15 Oct 2018 20:45 -0400: > I think this section should just breifly describe that the file > descriptors are opened before the command is executed, and that > > command < file1 < file2 > > is *similar* to > > cat file1 file2 | command > > except that the first waits for all files to be opened *before* command > executes and completely fails if any file opening fails, where as cat x y z > | command immediately starts processing files and simply skips ones that > fail. It's really not zsh's job to document cat(1). However, I agree with your overall point, that the statement about "equivalence" in the manual is incorrect. At the same time, I think a different fix would be better: 1. Ensure that it's documented that all redirections (input and output) are opened before the command is even exec'd. This is true for all redirections, not just for MULTIOS syntaxes. 2. In the section that gives analogies to cat(1) and sort(1), simply state that the examples assume that all dirent names are ordinary, readable files. Makes sense? Anybody volunteering to write the patch (not me)? > On a more general philosophical note though, I get that context is > important, but man pages and software references should **never** contain > objectively false statements. It's not ok to say something that factually > incorrect and justify it by assuming the reader will have enough "common > sense" to determine what parts are correct and which arent. These > references are the single souce of truth for a lot of readers. Cheers, Daniel