git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Ping Yin" <pkufranky@gmail.com>
To: "Junio C Hamano" <junio@pobox.com>
Cc: git@vger.kernel.org, "Johannes Sixt" <johannes.sixt@telecom.at>
Subject: Re: [PATCH v2 2/3] builtin-status: submodule summary support
Date: Sat, 12 Apr 2008 22:47:25 +0800	[thread overview]
Message-ID: <46dff0320804120747j424d459oc0987beb27fce1c6@mail.gmail.com> (raw)
In-Reply-To: <7vtzi8owf9.fsf@gitster.siamese.dyndns.org>

On Sat, Apr 12, 2008 at 6:31 AM, Junio C Hamano <junio@pobox.com> wrote:
>  > +static void wt_status_print_submodule_summary(struct wt_status *s)
>  > +{
>  > ...
>
> > +     memset(&sm_summary, 0, sizeof(sm_summary));
>  > +     sm_summary.argv = argv;
>  > +     sm_summary.env = env;
>  > +     sm_summary.git_cmd = 1;
>  > +     sm_summary.no_stdin = 1;
>  > +     fflush(s->fp);
>  > +     sm_summary.out = dup(fileno(s->fp));    /* run_command closes it */
>  > +     run_command(&sm_summary);
>
>  I recall we had some clean-up on how file descriptors are inherited and
>  duped around when run_command() runs a subprocess.  Hannes, is this dup()
>  consistent with how the things ought to be these days?

I think dup is needed, as commit c20181e3a3 says, run_command still
will close passed in positive descripors.

    start_command(), if .in/.out > 0, closes file descriptors, not the callers

    Callers of start_command() can set the members .in and .out of struct
    child_process to a value > 0 to specify that this descriptor is used as
    the stdin or stdout of the child process.

    Previously, if start_command() was successful, this descriptor was closed
    upon return. Here we now make sure that the descriptor is also closed in
    case of failures. All callers are updated not to close the file descriptor
    themselves after start_command() was called.


-- 
Ping Yin

  parent reply	other threads:[~2008-04-12 14:48 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-10 15:35 [PATCH v2] builtin-status: submodule summary support Ping Yin
2008-04-10 15:35 ` [PATCH v2 1/3] git-submodule summary: --for-status option Ping Yin
2008-04-10 15:35   ` [PATCH v2 2/3] builtin-status: submodule summary support Ping Yin
2008-04-10 15:35     ` [PATCH v2 3/3] buitin-status: Add tests for submodule summary Ping Yin
2008-04-11 22:31     ` [PATCH v2 2/3] builtin-status: submodule summary support Junio C Hamano
2008-04-12  5:28       ` Ping Yin
2008-04-12 14:47       ` Ping Yin [this message]
2008-04-12 16:13       ` Johannes Sixt
  -- strict thread matches above, loose matches on Subject: below --
2008-04-10 15:50 [PATCH/RFC] submodule: fallback to .gitmodules and multiple level module definition Ping Yin
2008-04-10 15:50 ` [PATCH/RFC 1/7] git-submodule: Extract functions module_info and module_url Ping Yin
2008-04-10 15:50   ` [PATCH v2 1/3] git-submodule summary: --for-status option Ping Yin
2008-04-10 15:50     ` [PATCH v2 2/3] builtin-status: submodule summary support Ping Yin

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=46dff0320804120747j424d459oc0987beb27fce1c6@mail.gmail.com \
    --to=pkufranky@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=johannes.sixt@telecom.at \
    --cc=junio@pobox.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 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).