From: Jilles Tjoelker <jilles@stack.nl>
To: Parke <parke.nexus@gmail.com>
Cc: "dash@vger.kernel.org" <dash@vger.kernel.org>
Subject: Re: why does dash save, dup, and restore redirected descriptor in the parent, rather than redirect in the child?
Date: Fri, 3 Feb 2017 23:37:55 +0100 [thread overview]
Message-ID: <20170203223755.GA69960@stack.nl> (raw)
In-Reply-To: <CAPxz1+au53RAak7Goisz7QKrzUSvtZidLFZ4b7sgV1QR_JeK5Q@mail.gmail.com>
On Tue, Jan 31, 2017 at 06:27:00PM -0800, Parke wrote:
> On Tue, Jan 31, 2017 at 12:00 PM, Mark Galeck <mark_galeck@pacbell.net> wrote:
> > This is strange. Why save, dup and dup again to restore, descriptors
> > in the parent, when it would be much simpler to just dup in the
> > child, and not have to save and restore. This is simpler and I
> > checked it works the same:
> > I am sure there must be a good reason and I am not understanding
> > something deeper. What is it?
> I am not a dash developer, but one reason to make system calls in the
> parent is that it is much simpler to handle errors in the parent.
> In your example:
> > if (!fork()) {
> > fd = open64("foobar.txt", O_WRONLY|O_CREAT);
> > dup2(fd, 1);
> > execl("/bin/date", "date", (char *)NULL);
> > }
> What happens if open64 fails? How should the child inform the parent
> of this specific error?
In general, you are right, but in the shell's case there is no
difficulty. The error is reported via an error message to stderr and a
non-zero exit status of the command, and the child process can easily do
those things.
--
Jilles Tjoelker
next prev parent reply other threads:[~2017-02-03 22:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <2132582962.805179.1485892834849.ref@mail.yahoo.com>
2017-01-31 20:00 ` why does dash save, dup, and restore redirected descriptor in the parent, rather than redirect in the child? Mark Galeck
2017-01-31 20:30 ` Harald van Dijk
2017-02-01 2:27 ` Parke
2017-02-03 22:37 ` Jilles Tjoelker [this message]
2017-02-02 18:17 ` Mark Galeck
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=20170203223755.GA69960@stack.nl \
--to=jilles@stack.nl \
--cc=dash@vger.kernel.org \
--cc=parke.nexus@gmail.com \
/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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.