summaryrefslogtreecommitdiff
path: root/run-command.h
AgeCommit message (Collapse)AuthorFilesLines
2009-01-17Move run_hook() from builtin-commit.c into run-command.c (libgit)Libravatar Stephan Beyer1-0/+2
A function that runs a hook is used in several Git commands. builtin-commit.c has the one that is most general for cases without piping. The one in builtin-gc.c prints some useful warnings. This patch moves a merged version of these variants into libgit and lets the other builtins use this libified run_hook(). The run_hook() function used in receive-pack.c feeds the standard input of the pre-receive or post-receive hooks. This function is renamed to run_receive_hook() because the libified run_hook() cannot handle this. Mentored-by: Daniel Barkalow <barkalow@iabervon.org> Mentored-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-10-02run-command.c: remove run_command_v_opt_cd()Libravatar Nanako Shiraishi1-1/+0
This function is not used anywhere. Johannes Sixt <johannes.sixt@telecom.at>: > Future callers can use run_command_v_opt_cd_env() instead. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-07-25run-command: add pre-exec callbackLibravatar Jeff King1-0/+1
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: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-26Windows: Implement asynchronous functions as threads.Libravatar Johannes Sixt1-0/+5
In upload-pack we must explicitly close the output channel of rev-list. (On Unix, the channel is closed automatically because process that runs rev-list terminates.) Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
2008-02-23start_command(), if .in/.out > 0, closes file descriptors, not the callersLibravatar Johannes Sixt1-0/+18
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: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-23start_command(), .in/.out/.err = -1: Callers must close the file descriptorLibravatar Johannes Sixt1-2/+0
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: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-11run-command: Support sending stderr to /dev/nullLibravatar Shawn O. Pearce1-0/+1
Some callers may wish to redirect stderr to /dev/null in some contexts, such as if they are executing a command only to get the exit status and don't want users to see whatever output it may produce as a side-effect of computing that exit status. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-10-21Add infrastructure to run a function asynchronously.Libravatar Johannes Sixt1-0/+22
This adds start_async() and finish_async(), which runs a function asynchronously. Communication with the caller happens only via pipes. For this reason, this implementation forks off a child process that runs the function. [sp: Style nit fixed by removing unnecessary block on if condition inside of start_async()] Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-10-21Have start_command() create a pipe to read the stderr of the child.Libravatar Johannes Sixt1-0/+1
This adds another stanza that allocates a pipe that is connected to the child's stderr and that the caller can read from. In order to request this pipe, the caller sets cmd->err to -1. The implementation is not exactly modeled after the stdout case: For stdout the caller can supply an existing file descriptor, but this facility is nowhere needed in the stderr case. Additionally, the caller is required to close cmd->err. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-05-23Allow environment variables to be unset in the processes started by run_commandLibravatar Alex Riesen1-0/+5
To unset a variable, just specify its name, without "=". For example: const char *env[] = {"GIT_DIR=.git", "PWD", NULL}; const char *argv[] = {"git-ls-files", "-s", NULL}; int err = run_command_v_opt_cd_env(argv, RUN_GIT_CMD, ".", env); The PWD will be unset before executing git-ls-files. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-23Add ability to specify environment extension to run_commandLibravatar Alex Riesen1-0/+2
There is no way to specify and override for the environment: there'd be no user for it yet. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-23Add run_command_v_opt_cd: chdir into a directory before execLibravatar Alex Riesen1-0/+2
It can make code simplier (no need to preserve cwd) and safer (no chance the cwd of the current process is accidentally forgotten). Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-12Teach run-command to redirect stdout to /dev/nullLibravatar Shawn O. Pearce1-0/+1
Some run-command callers may wish to just discard any data that is sent to stdout from the child. This is a lot like our existing no_stdin support, we just open /dev/null and duplicate the descriptor into position. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-12Teach run-command about stdout redirectionLibravatar Shawn O. Pearce1-0/+2
Some potential callers of the run_command family of functions need to control not only the stdin redirection of the child, but also the stdout redirection of the child. This can now be setup much like the already existing stdin redirection. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-11Teach run_command how to setup a stdin pipeLibravatar Shawn O. Pearce1-0/+3
Sometimes callers trying to use run_command to execute a child process will want to setup a pipe or file descriptor to redirect into the child's stdin. This idea is completely stolen from builtin-bundle's fork_with_pipe, written by Johannes Schindelin. All credit (and blame) should lie with Dscho. ;-) Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-11Split run_command into two halves (start/finish)Libravatar Shawn O. Pearce1-0/+3
If the calling process wants to send data to stdin of a child process it will need to arrange for a pipe and get the child process running, feed data to it, then wait for the child process to finish. So we split the run function into two halves, allowing callers to first start the child then later finish it. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-11Start defining a more sophisticated run_commandLibravatar Shawn O. Pearce1-0/+9
There are a number of places where we do some variation of fork()+exec() but we also need to setup redirection in the process, much like what run_command does for us already with its option flags. It would be nice to reuse more of the run_command logic, especially as that non-fork API helps us to port to odd platforms like Win32. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-11Remove unused run_command variantsLibravatar Shawn O. Pearce1-4/+0
We don't actually use these va_list based variants of run_command anymore. I'm removing them before I make further improvements. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-30Use /dev/null for update hook stdin.Libravatar Shawn O. Pearce1-1/+1
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: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-30Redirect update hook stdout to stderr.Libravatar Shawn O. Pearce1-0/+2
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: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-30Remove unnecessary argc parameter from run_command_v.Libravatar Shawn O. Pearce1-2/+2
The argc parameter is never used by the run_command_v family of functions. Instead they require that the passed argv[] be NULL terminated so they can rely on the operating system's execvp function to correctly pass the arguments to the new process. Making the caller pass the argc is just confusing, as the caller could be mislead into believing that the argc might take precendece over the argv, or that the argv does not need to be NULL terminated. So goodbye argc. Don't come back. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-05Const tightening.Libravatar Junio C Hamano1-2/+2
Mark Wooding noticed there was a type mismatch warning in git.c; this patch does things slightly differently (mostly tightening const) and was what I was holding onto, waiting for the setup-revisions change to be merged into the master branch. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-13Exec git programs without using PATH.Libravatar Michal Ostrowski1-1/+1
The git suite may not be in PATH (and thus programs such as git-send-pack could not exec git-rev-list). Thus there is a need for logic that will locate these programs. Modifying PATH is not desirable as it result in behavior differing from the user's intentions, as we may end up prepending "/usr/bin" to PATH. - git C programs will use exec*_git_cmd() APIs to exec sub-commands. - exec*_git_cmd() will execute a git program by searching for it in the following directories: 1. --exec-path (as used by "git") 2. The GIT_EXEC_PATH environment variable. 3. $(gitexecdir) as set in Makefile (default value $(bindir)). - git wrapper will modify PATH as before to enable shell scripts to invoke "git-foo" commands. Ideally, shell scripts should use the git wrapper to become independent of PATH, and then modifying PATH will not be necessary. [jc: with minor updates after a brief review.] Signed-off-by: Michal Ostrowski <mostrows@watson.ibm.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-07Clean up file descriptors when calling hooks.Libravatar Daniel Barkalow1-0/+3
When calling post-update hook, don't leave stdin and stdout connected to the pushing connection. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-02receive-pack hooks updates.Libravatar Junio C Hamano1-0/+1
The earlier one conflated update and post-update hooks for no good reason. Correct that ugly hack. Now post-update hooks will take the list of successfully updated refs. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-07-31[PATCH] Added hook in git-receive-packLibravatar Josef Weidendorfer1-0/+16
Just before updating a ref, $GIT_DIR/hooks/update refname old-sha1 new-sha1 is called if executable. The hook can decline the ref to be updated by exiting with a non-zero status, or allow it to be updated by exiting with a zero status. The mechanism also allows e.g sending of a mail with pushed commits on the remote repository. Documentation update with an example hook is included. jc: The credits of the basic idea and initial implementation go to Josef, but I ended up rewriting major parts of his patch, so bugs are all mine. Also I changed the semantics for the hook from his original version (which were post-update hook) so that the hook can optionally decline to update the ref, and also can be used to implement the overall cleanups. The latter was primarily to implement a suggestion from Linus that calling update-server-info should be made optional. Signed-off-by: Junio C Hamano <junkio@cox.net>