1. 15 May, 2014 1 commit
    • Jeff King's avatar
      run-command: store an optional argv_array · c460c0ec
      Jeff King authored
      All child_process structs need to point to an argv. For
      flexibility, we do not mandate the use of a dynamic
      argv_array. However, because the child_process does not own
      the memory, this can make memory management with a
      separate argv_array difficult.
      For example, if a function calls start_command but not
      finish_command, the argv memory must persist. The code needs
      to arrange to clean up the argv_array separately after
      finish_command runs. As a result, some of our code in this
      situation just leaks the memory.
      To help such cases, this patch adds a built-in argv_array to
      the child_process, which gets cleaned up automatically (both
      in finish_command and when start_command fails).  Callers
      may use it if they choose, but can continue to use the raw
      argv if they wish.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  2. 18 Mar, 2014 2 commits
  3. 19 Jul, 2013 1 commit
  4. 10 Jul, 2013 1 commit
  5. 14 Jan, 2013 1 commit
    • Aaron Schrab's avatar
      hooks: Add function to check if a hook exists · 5a7da2dc
      Aaron Schrab authored
      Create find_hook() function to determine if a given hook exists and is
      executable.  If it is, the path to the script will be returned,
      otherwise NULL is returned.
      This encapsulates the tests that are used to check for the existence of
      a hook in one place, making it easier to modify those checks if that is
      found to be necessary.  This also makes it simple for places that can
      use a hook to check if a hook exists before doing, possibly lengthy,
      setup work which would be pointless if no such hook is present.
      The returned value is left as a static value from get_pathname() rather
      than a duplicate because it is anticipated that the return value will
      either be used as a boolean, immediately added to an argv_array list
      which would result in it being duplicated at that point, or used to
      actually run the command without much intervening work.  Callers which
      need to hold onto the returned value for a longer time are expected to
      duplicate the return value themselves.
      Signed-off-by: Aaron Schrab's avatarAaron Schrab <aaron@schrab.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  6. 05 Jun, 2012 1 commit
    • Jeff King's avatar
      pager: drop "wait for output to run less" hack · e8320f35
      Jeff King authored
      Commit 35ce8622 (pager: Work around window resizing bug in
      'less', 2007-01-24) causes git's pager sub-process to wait
      to receive input after forking but before exec-ing the
      pager. To handle this, run-command had to grow a "pre-exec
      callback" feature. Unfortunately, this feature does not work
      at all on Windows (where we do not fork), and interacts
      poorly with run-command's parent notification system. Its
      use should be discouraged.
      The bug in less was fixed in version 406, which was released
      in June 2007. It is probably safe at this point to remove
      our workaround. That lets us rip out the preexec_cb feature
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  7. 08 Jan, 2012 2 commits
    • Clemens Buchacher's avatar
      dashed externals: kill children on exit · 10c6cddd
      Clemens Buchacher authored
      Several git commands are so-called dashed externals, that is commands
      executed as a child process of the git wrapper command. If the git
      wrapper is killed by a signal, the child process will continue to run.
      This is different from internal commands, which always die with the git
      wrapper command.
      Enable the recently introduced cleanup mechanism for child processes in
      order to make dashed externals act more in line with internal commands.
      Signed-off-by: default avatarClemens Buchacher <drizzd@aon.at>
      Acked-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Jeff King's avatar
      run-command: optionally kill children on exit · afe19ff7
      Jeff King authored
      When we spawn a helper process, it should generally be done
      and finish_command called before we exit. However, if we
      exit abnormally due to an early return or a signal, the
      helper may continue to run in our absence.
      In the best case, this may simply be wasted CPU cycles or a
      few stray messages on a terminal. But it could also mean a
      process that the user thought was aborted continues to run
      to completion (e.g., a push's pack-objects helper will
      complete the push, even though you killed the push process).
      This patch provides infrastructure for run-command to keep
      track of PIDs to be killed, and clean them on signal
      reception or input, just as we do with tempfiles. PIDs can
      be added in two ways:
        1. If NO_PTHREADS is defined, async helper processes are
           automatically marked. By definition this code must be
           ready to die when the parent dies, since it may be
           implemented as a thread of the parent process.
        2. If the run-command caller specifies the "clean_on_exit"
           option. This is not the default, as there are cases
           where it is OK for the child to outlive us (e.g., when
           spawning a pager).
      PIDs are cleared from the kill-list automatically during
      wait_or_whine, which is called from finish_command and
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarClemens Buchacher <drizzd@aon.at>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  8. 10 Mar, 2010 1 commit
  9. 07 Mar, 2010 1 commit
    • Johannes Sixt's avatar
      Reimplement async procedures using pthreads · 200a76b7
      Johannes Sixt authored
      On Windows, async procedures have always been run in threads, and the
      implementation used Windows specific APIs. Rewrite the code to use pthreads.
      A new configuration option is introduced so that the threaded implementation
      can also be used on POSIX systems. Since this option is intended only as
      playground on POSIX, but is mandatory on Windows, the option is not
      One detail is that on POSIX it is necessary to set FD_CLOEXEC on the pipe
      handles. On Windows, this is not needed because pipe handles are not
      inherited to child processes, and the new calls to set_cloexec() are
      effectively no-ops.
      Signed-off-by: default avatarJohannes Sixt <j6t@kdbg.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  10. 06 Feb, 2010 2 commits
  11. 02 Jan, 2010 1 commit
    • Jeff King's avatar
      run-command: add "use shell" option · 8dba1e63
      Jeff King authored
      Many callsites run "sh -c $CMD" to run $CMD. We can make it
      a little simpler for them by factoring out the munging of
      For simple cases with no arguments, this doesn't help much, but:
        1. For cases with arguments, we save the caller from
           having to build the appropriate shell snippet.
        2. We can later optimize to avoid the shell when
           there are no metacharacters in the program.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  12. 19 Sep, 2009 1 commit
  13. 06 Jul, 2009 2 commits
    • Johannes Sixt's avatar
      run_command: report failure to execute the program, but optionally don't · c024beb5
      Johannes Sixt authored
      In the case where a program was not found, it was still the task of the
      caller to report an error to the user. Usually, this is an interesting case
      but only few callers actually reported a specific error (though many call
      sites report a generic error message regardless of the cause).
      With this change the error is reported by run_command, but since there is
      one call site in git.c that does not want that, an option is added to
      struct child_process, which is used to turn the error off.
      Signed-off-by: default avatarJohannes Sixt <j6t@kdbg.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Johannes Sixt's avatar
      run_command: report system call errors instead of returning error codes · 0ac77ec3
      Johannes Sixt authored
      The motivation for this change is that system call failures are serious
      errors that should be reported to the user, but only few callers took the
      burden to decode the error codes that the functions returned into error
      If at all, then only an unspecific error message was given. A prominent
      example is this:
         $ git upload-pack . | :
         fatal: unable to run 'git-upload-pack'
      In this example, git-upload-pack, the external command invoked through the
      git wrapper, dies due to SIGPIPE, but the git wrapper does not bother to
      report the real cause. In fact, this very error message is copied to the
      syslog if git-daemon's client aborts the connection early.
      With this change, system call failures are reported immediately after the
      failure and only a generic failure code is returned to the caller. In the
      above example the error is now to the point:
         $ git upload-pack . | :
         error: git-upload-pack died of signal
      Note that there is no error report if the invoked program terminated with
      a non-zero exit code, because it is reasonable to expect that the invoked
      program has already reported an error. (But many run_command call sites
      nevertheless write a generic error message.)
      There was one special return code that was used to identify the case where
      run_command failed because the requested program could not be exec'd. This
      special case is now treated like a system call failure with errno set to
      ENOENT. No error is reported in this case, because the call site in git.c
      expects this as a normal result. Therefore, the callers that carefully
      decoded the return value still check for this condition.
      Signed-off-by: default avatarJohannes Sixt <j6t@kdbg.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  14. 05 Jul, 2009 1 commit
    • Johannes Sixt's avatar
      run_command: return exit code as positive value · 5709e036
      Johannes Sixt authored
      As a general guideline, functions in git's code return zero to indicate
      success and negative values to indicate failure. The run_command family of
      functions followed this guideline. But there are actually two different
      kinds of failure:
      - failures of system calls;
      - non-zero exit code of the program that was run.
      Usually, a non-zero exit code of the program is a failure and means a
      failure to the caller. Except that sometimes it does not. For example, the
      exit code of merge programs (e.g. external merge drivers) conveys
      information about how the merge failed, and not all exit calls are
      actually failures.
      Furthermore, the return value of run_command is sometimes used as exit
      code by the caller.
      This change arranges that the exit code of the program is returned as a
      positive value, which can now be regarded as the "result" of the function.
      System call failures continue to be reported as negative values.
      Signed-off-by: default avatarJohannes Sixt <j6t@kdbg.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  15. 01 Apr, 2009 1 commit
  16. 28 Jan, 2009 1 commit
  17. 18 Jan, 2009 1 commit
  18. 03 Oct, 2008 1 commit
  19. 26 Jul, 2008 1 commit
    • Jeff King's avatar
      run-command: add pre-exec callback · ccf08bc3
      Jeff King authored
      This is a function provided by the caller which is called
      _after_ the process is forked, but before the spawned
      program is executed. On platforms (like mingw) where
      subprocesses are forked and executed in a single call, the
      preexec callback is simply ignored.
      This will be used in the following patch to do some setup
      for 'less' that must happen in the forked child.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  20. 26 Jun, 2008 1 commit
  21. 23 Feb, 2008 2 commits
    • Johannes Sixt's avatar
      start_command(), if .in/.out > 0, closes file descriptors, not the callers · c20181e3
      Johannes Sixt authored
      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.
      Note that earlier run_gpg_verify() of git-verify-tag set .out = 1, which
      worked because start_command() treated this as a special case, but now
      this is incorrect because it closes the descriptor. The intent here is to
      inherit stdout to the child, which is achieved by .out = 0.
      Signed-off-by: default avatarJohannes Sixt <johannes.sixt@telecom.at>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Johannes Sixt's avatar
      start_command(), .in/.out/.err = -1: Callers must close the file descriptor · e72ae288
      Johannes Sixt authored
      By setting .in, .out, or .err members of struct child_process to -1, the
      callers of start_command() can request that a pipe is allocated that talks
      to the child process and one end is returned by replacing -1 with the
      file descriptor.
      Previously, a flag was set (for .in and .out, but not .err) to signal
      finish_command() to close the pipe end that start_command() had handed out,
      so it was optional for callers to close the pipe, and many already do so.
      Now we make it mandatory to close the pipe.
      Signed-off-by: default avatarJohannes Sixt <johannes.sixt@telecom.at>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  22. 12 Nov, 2007 1 commit
  23. 21 Oct, 2007 2 commits
  24. 24 May, 2007 3 commits
  25. 13 Mar, 2007 2 commits
  26. 12 Mar, 2007 4 commits
  27. 31 Dec, 2006 2 commits
    • Shawn O. Pearce's avatar
      Use /dev/null for update hook stdin. · 95d3c4f5
      Shawn O. Pearce authored
      Currently the update hook invoked by receive-pack has its stdin
      connected to the pushing client.  The hook shouldn't attempt to
      read from this stream, and doing so may consume data that was
      meant for receive-pack.  Instead we should give the update hook
      /dev/null as its stdin, ensuring that it always receives EOF and
      doesn't disrupt the protocol if it attempts to read any data.
      The post-update hook is similar, as it gets invoked with /dev/null
      on stdin to prevent the hook from reading data from the client.
      Previously we had invoked it with stdout also connected to /dev/null,
      throwing away anything on stdout, to prevent client protocol errors.
      Instead we should redirect stdout to stderr, like we do with the
      update hook.
      Signed-off-by: default avatarShawn O. Pearce <spearce@spearce.org>
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
    • Shawn O. Pearce's avatar
      Redirect update hook stdout to stderr. · cd83c74c
      Shawn O. Pearce authored
      If an update hook outputs to stdout then that output will be sent
      back over the wire to the push client as though it were part of
      the git protocol.  This tends to cause protocol errors on the
      client end of the connection, as the hook output is not expected
      in that context.  Most hook developers work around this by making
      sure their hook outputs everything to stderr.
      But hooks shouldn't need to perform such special behavior.  Instead
      we can just dup stderr to stdout prior to invoking the update hook.
      Signed-off-by: default avatarShawn O. Pearce <spearce@spearce.org>
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>