zsh-users
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: Pier Paolo Grassi <pierpaolog@gmail.com>
Cc: Daniel Shahaf <d.s@daniel.shahaf.name>,
	Mikael Magnusson <mikachu@gmail.com>,
	 Zsh-Users List <zsh-users@zsh.org>
Subject: Re: subprocess
Date: Mon, 8 Jun 2020 14:32:47 -0700	[thread overview]
Message-ID: <CAH+w=7bQyHUME+TUx1VzudHoMOUwDtKBdw_JGHwHZV_VuahpDQ@mail.gmail.com> (raw)
In-Reply-To: <CAP+y1xBLJzx++sV=KJ3LfGsQ=uL+w35AFYc90UEp4qGbk=aP8g@mail.gmail.com>

On Mon, Jun 8, 2020 at 7:22 AM Pier Paolo Grassi <pierpaolog@gmail.com> wrote:
>
> What would be the best way to learn more about these mechanisms without
> digging in the source code of the shell or the kernel?

Hmm.  Digging in the source code probably isn't the best way even if
you were interested.  It's a tough question.

This is all documented, but not in any single coherent place, mostly
because there are just too many possible ways to combine things to
explain all the variations.  For example the closing of all
descriptors >= 10 when starting a new job is long-standing,
standardized shell behavior, so the zsh manual doesn't mention it,
you're just expected to have learned (elsewhere) that is how shells
work.  I'm not sure the "named functions get their own job" part is
explained very clearly anywhere, but it is explained that anonymous
functions do not behave that way.  (E.g., "Redirections may be applied
to the anonymous function in the same manner as to a current-shell
structure enclosed in braces.")  It's explained that <(...) uses a
special file representing a file descriptor ("If the system supports
the /dev/fd mechanism, the command argument is the name of the device
file corresponding to a file descriptor" -- that should probably
mention /proc/self/fd as well) but does not warn that it might
conflict with the "close all descriptors above 10" behavior.

The upshot is that the best way to learn is probably to ask somebody.
I don't think all these sorts of nuances are even covered by most
books on shell programming.

      reply	other threads:[~2020-06-08 21:33 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-05  2:03 subprocess Pier Paolo Grassi
2020-06-05 10:25 ` subprocess Mikael Magnusson
2020-06-06  1:00   ` subprocess Daniel Shahaf
2020-06-06 18:19     ` subprocess Bart Schaefer
2020-06-06 19:53       ` subprocess Peter Stephenson
2020-06-08 19:55         ` subprocess Peter Stephenson
2020-06-08 14:22       ` subprocess Pier Paolo Grassi
2020-06-08 21:32         ` Bart Schaefer [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAH+w=7bQyHUME+TUx1VzudHoMOUwDtKBdw_JGHwHZV_VuahpDQ@mail.gmail.com' \
    --to=schaefer@brasslantern.com \
    --cc=d.s@daniel.shahaf.name \
    --cc=mikachu@gmail.com \
    --cc=pierpaolog@gmail.com \
    --cc=zsh-users@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).