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=-1.0 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 31766 invoked from network); 8 Jun 2020 14:23:33 -0000 Received: from ns1.primenet.com.au (HELO primenet.com.au) (203.24.36.2) by inbox.vuxu.org with ESMTPUTF8; 8 Jun 2020 14:23:33 -0000 Received: (qmail 29668 invoked by alias); 8 Jun 2020 14:23:20 -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: List-Unsubscribe: X-Seq: 24910 Received: (qmail 8481 invoked by uid 1010); 8 Jun 2020 14:23:20 -0000 X-Qmail-Scanner-Diagnostics: from mail-il1-f177.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.3/25835. spamassassin: 3.4.4. Clear:RC:0(209.85.166.177):SA:0(-2.0/5.0):. Processed in 1.526971 secs); 08 Jun 2020 14:23:20 -0000 X-Envelope-From: pierpaolog@gmail.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.166.177 as permitted sender) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NUAvbE+/Ls12ErB/HFTLvnu38EjoJV0g5WwLV6fGCxI=; b=EXvW+2iNzY7rqEsvkUMobpTgN0ewcc+mQVSmUKIWbhWvwCcCvlmHlFuCJ1UZSMpD2D rzlfxXJou2b3PisTvIjGxBHPUGsWpx2zhPuS3fpQRwVvknuKL6qO6kSWvrJRW4ZyY9R8 wLa7gYJn4gpaM4KMGiny+pH6M9oWTTtk3gccPDo3TSuYcTWvkjnWDW0nsC2aH3gUHavX Z5CFxJYq+Ks3hpk9JF7chkTfQupkV1XPAgCWPB7aSaTgxMxNixoAZzV7Fx5QH+qWD9ce ESA7BQopHUNm+d4cQfar/mqgCtMt0biE1R3g5PUXZsocbW9lj1gIx1KoQMzzROw8NoC9 KdWg== X-Gm-Message-State: AOAM533h5r8ChSSRDF3gINcAvpEljRHKOnm0j2Qeyf43FZph7CgkB3G8 6XNo8Cb5lPJTxF/ZWLcLFIQDOQARsZZH9BM3uwayLrZ9KlQ= X-Google-Smtp-Source: ABdhPJxrpvcvdB50Qx+cVIbA+h3jiqqpgHyGOcVIyfqDLFJ6UTU7L6XQH92el1Zm11budyrJd2atJS7uRBL+V+p/XpY= X-Received: by 2002:a92:4a04:: with SMTP id m4mr23119109ilf.228.1591626165304; Mon, 08 Jun 2020 07:22:45 -0700 (PDT) MIME-Version: 1.0 References: <20200606010018.5d9c4a33@tarpaulin.shahaf.local2> In-Reply-To: From: Pier Paolo Grassi Date: Mon, 8 Jun 2020 16:22:09 +0200 Message-ID: Subject: Re: subprocess To: Bart Schaefer Cc: Daniel Shahaf , Mikael Magnusson , Zsh-Users List Content-Type: multipart/alternative; boundary="00000000000032c72705a79358d6" --00000000000032c72705a79358d6 Content-Type: text/plain; charset="UTF-8" thanks for the debugging technique and the explanation, very interesting. What would be the best way to learn more about these mechanisms without digging in the source code of the shell or the kernel? I am not very comfortable around c regards Il giorno sab 6 giu 2020 alle ore 20:19 Bart Schaefer < schaefer@brasslantern.com> ha scritto: > On Fri, Jun 5, 2020 at 6:01 PM Daniel Shahaf > wrote: > > > On 6/5/20, Pier Paolo Grassi wrote: > > > > efe() cat $1 > > > > efe <(seq 1 10) | wc -l > > > > cat: /proc/self/fd/13: No such file or directory > > > > 0 > > > > > > > > gives error, instead these all works fine: > > > > efe =(seq 1 10)| wc -l > > > > cat <(seq 1 10)| wc -l > > > > And this, > > > > % () { cat $1 } <(seq 1 10) | wc -l > > You can see what's happening if you do it this way: > > % efe() ls -l ${${1:+$1:h}:-/proc/self/fd} > % efe <(seq 1 10) | cat > total 0 > lrwx------ 1 schaefer schaefer 64 Jun 6 10:59 0 -> /dev/pts/0 > l-wx------ 1 schaefer schaefer 64 Jun 6 10:59 1 -> pipe:[1945962] > lrwx------ 1 schaefer schaefer 64 Jun 6 10:59 2 -> /dev/pts/0 > lr-x------ 1 schaefer schaefer 64 Jun 6 10:59 3 -> /proc/5533/fd > % () { ls -l $1:h } <(seq 1 10) | cat > total 0 > lrwx------ 1 schaefer schaefer 64 Jun 6 11:00 0 -> /dev/pts/0 > l-wx------ 1 schaefer schaefer 64 Jun 6 11:00 1 -> pipe:[1945988] > lr-x------ 1 schaefer schaefer 64 Jun 6 11:00 11 -> pipe:[1944505] > lrwx------ 1 schaefer schaefer 64 Jun 6 11:00 2 -> /dev/pts/0 > lr-x------ 1 schaefer schaefer 64 Jun 6 11:00 3 -> /proc/5537/fd > > A named function on the left side of a pipeline becomes its own "job", > where all descriptors above 10 are closed. An anonymous function > stays in the parent shell (which is still a forked subshell, because > of the pipeline) so those descriptors are not closed. > > % efe =(seq 1 10) | cat > total 4 > -rw------- 1 schaefer schaefer 21 Jun 6 11:09 zshkDpnRj > > In that case a real file has been created and is referenced by name, > so the descriptors closing does not matter. > > % efe <<(seq 1 10) | cat > total 0 > lr-x------ 1 schaefer schaefer 64 Jun 6 11:13 0 -> pipe:[1946804] > l-wx------ 1 schaefer schaefer 64 Jun 6 11:13 1 -> pipe:[1946579] > lrwx------ 1 schaefer schaefer 64 Jun 6 11:13 2 -> /dev/pts/0 > lr-x------ 1 schaefer schaefer 64 Jun 6 11:13 3 -> /proc/5599/fd > > For <<(...) no file is created at all, instead the standard input of > the function is changed. > > > Mikael Magnusson wrote on Fri, 05 Jun 2020 12:25 +0200: > > > > > > This also works, > > > % efe <(seq 1 10) > >(wc -l) > > > as does this, > > > % wc -l < <(efe <(seq 1 10)) > > In both of these cases, there is no pipeline, so efe stays in the > parent shell and all the descriptors remain open. > --00000000000032c72705a79358d6--