summaryrefslogtreecommitdiff
path: root/pager.c
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch 'jc/am-i-v-fix'Junio C Hamano2016-02-241-8/+11
|\ | | | | | | | | | | | | | | | | | | The "v(iew)" subcommand of the interactive "git am -i" command was broken in 2.6.0 timeframe when the command was rewritten in C. * jc/am-i-v-fix: am -i: fix "v"iew pager: factor out a helper to prepare a child process to run the pager pager: lose a separate argv[]
| * pager: factor out a helper to prepare a child process to run the pagerJunio C Hamano2016-02-171-6/+11
| | | | | | | | | | | | | | | | | | | | When running a pager, we need to run the program git_pager() gave us, but we need to make sure we spawn it via the shell (i.e. it is valid to say PAGER='less -S', for example) and give default values to $LESS and $LV environment variables. Factor out these details to a separate helper function. Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * pager: lose a separate argv[]Junio C Hamano2016-02-161-3/+1
| | | | | | | | | | | | | | These days, using the embedded args array in the child_process structure is the norm. Follow that practice. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'ti/glibc-stdio-mutex-from-signal-handler'Junio C Hamano2015-10-071-6/+16
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allocation related functions and stdio are unsafe things to call inside a signal handler, and indeed killing the pager can cause glibc to deadlock waiting on allocation mutex as our signal handler tries to free() some data structures in wait_for_pager(). Reduce these unsafe calls. * ti/glibc-stdio-mutex-from-signal-handler: pager: don't use unsafe functions in signal handlers
| * | pager: don't use unsafe functions in signal handlersti/glibc-stdio-mutex-from-signal-handlerTakashi Iwai2015-09-041-6/+16
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since the commit a3da8821208d (pager: do wait_for_pager on signal death), we call wait_for_pager() in the pager's signal handler. The recent bug report revealed that this causes a deadlock in glibc at aborting "git log" [*1*]. When this happens, git process is left unterminated, and it can't be killed by SIGTERM but only by SIGKILL. The problem is that wait_for_pager() function does more than waiting for pager process's termination, but it does cleanups and printing errors. Unfortunately, the functions that may be used in a signal handler are very limited [*2*]. Particularly, malloc(), free() and the variants can't be used in a signal handler because they take a mutex internally in glibc. This was the cause of the deadlock above. Other than the direct calls of malloc/free, many functions calling malloc/free can't be used. strerror() is such one, either. Also the usage of fflush() and printf() in a signal handler is bad, although it seems working so far. In a safer side, we should avoid them, too. This patch tries to reduce the calls of such functions in signal handlers. wait_for_signal() takes a flag and avoids the unsafe calls. Also, finish_command_in_signal() is introduced for the same reason. There the free() calls are removed, and only waits for the children without whining at errors. [*1*] https://bugzilla.opensuse.org/show_bug.cgi?id=942297 [*2*] http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04_03 Signed-off-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'jk/fix-alias-pager-config-key-warnings'Junio C Hamano2015-08-311-1/+2
|\ \ | |/ |/| | | | | | | | | | | | | | | | | Because the configuration system does not allow "alias.0foo" and "pager.0foo" as the configuration key, the user cannot use '0foo' as a custom command name anyway, but "git 0foo" tried to look these keys up and emitted useless warnings before saying '0foo is not a git command'. These warning messages have been squelched. * jk/fix-alias-pager-config-key-warnings: config: silence warnings for command names with invalid keys
| * config: silence warnings for command names with invalid keysjk/fix-alias-pager-config-key-warningsJeff King2015-08-241-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we are running the git command "foo", we may have to look up the config keys "pager.foo" and "alias.foo". These config schemes are mis-designed, as the command names can be anything, but the config syntax has some restrictions. For example: $ git foo_bar error: invalid key: pager.foo_bar error: invalid key: alias.foo_bar git: 'foo_bar' is not a git command. See 'git --help'. You cannot name an alias with an underscore. And if you have an external command with one, you cannot configure its pager. In the long run, we may develop a different config scheme for these features. But in the near term (and because we'll need to support the existing scheme indefinitely), we should at least squelch the error messages shown above. These errors come from git_config_parse_key. Ideally we would pass a "quiet" flag to the config machinery, but there are many layers between the pager code and the key parsing. Passing a flag through all of those would be an invasive change. Instead, let's provide a config function to report on whether a key is syntactically valid, and have the pager and alias code skip lookup for bogus keys. We can build this easily around the existing git_config_parse_key, with two minor modifications: 1. We now handle a NULL store_key, to validate but not write out the normalized key. 2. We accept a "quiet" flag to avoid writing to stderr. This doesn't need to be a full-blown public "flags" field, because we can make the existing implementation a static helper function, keeping the mess contained inside config.c. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'jc/unexport-git-pager-in-use-in-pager'Junio C Hamano2015-07-131-0/+1
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When you say "!<ENTER>" while running say "git log", you'd confuse yourself in the resulting shell, that may look as if you took control back to the original shell you spawned "git log" from but that isn't what is happening. To that new shell, we leaked GIT_PAGER_IN_USE environment variable that was meant as a local communication between the original "Git" and subprocesses that was spawned by it after we launched the pager, which caused many "interesting" things to happen, e.g. "git diff | cat" still paints its output in color by default. Stop leaking that environment variable to the pager's half of the fork; we only need it on "Git" side when we spawn the pager. * jc/unexport-git-pager-in-use-in-pager: pager: do not leak "GIT_PAGER_IN_USE" to the pager
| * | pager: do not leak "GIT_PAGER_IN_USE" to the pagerjc/unexport-git-pager-in-use-in-pagerJunio C Hamano2015-07-031-0/+1
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since 2e6c012e (setup_pager: set GIT_PAGER_IN_USE, 2011-08-17), we export GIT_PAGER_IN_USE so that a process that becomes the upstream of the spawned pager can still tell that we have spawned the pager and decide to do colored output even when its output no longer goes to a terminal (i.e. isatty(1)). But we forgot to clear it from the enviornment of the spawned pager. This is not a problem in a sane world, but if you have a handful of thousands Git users in your organization, somebody is bound to do strange things, e.g. typing "!<ENTER>" instead of 'q' to get control back from $LESS. GIT_PAGER_IN_USE is still set in that subshell spawned by "less", and all sorts of interesting things starts happening, e.g. "git diff | cat" starts coloring its output. We can clear the environment variable in the half of the fork that runs the pager to avoid the confusion. Signed-off-by: Junio C Hamano <gitster@pobox.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'jk/decimal-width-for-uintmax'Junio C Hamano2015-02-181-4/+4
|\ \ | |/ |/| | | | | | | | | | | We didn't format an integer that wouldn't fit in "int" but in "uintmax_t" correctly. * jk/decimal-width-for-uintmax: decimal_width: avoid integer overflow
| * decimal_width: avoid integer overflowjk/decimal-width-for-uintmaxJeff King2015-02-051-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The decimal_width function originally appeared in blame.c as "lineno_width", and was designed for calculating the print-width of small-ish integer values (line numbers in text files). In ec7ff5b, it was made into a reusable function, and in dc801e7, we started using it to align diffstats. Binary files in a diffstat show byte counts rather than line numbers, meaning they can be quite large (e.g., consider adding or removing a 2GB file). decimal_width is not up to the challenge for two reasons: 1. It takes the value as an "int", whereas large files may easily surpass this. The value may be truncated, in which case we will produce an incorrect value. 2. It counts "up" by repeatedly multiplying another integer by 10 until it surpasses the value. This can cause an infinite loop when the value is close to the largest representable integer. For example, consider using a 32-bit signed integer, and a value of 2,140,000,000 (just shy of 2^31-1). We will count up and eventually see that 1,000,000,000 is smaller than our value. The next step would be to multiply by 10 and see that 10,000,000,000 is too large, ending the loop. But we can't represent that value, and we have signed overflow. This is technically undefined behavior, but a common behavior is to lose the high bits, in which case our iterator will certainly be less than the number. So we'll keep multiplying, overflow again, and so on. This patch changes the argument to a uintmax_t (the same type we use to store the diffstat information for binary filese), and counts "down" by repeatedly dividing our value by 10. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | use env_array member of struct child_processrs/run-command-env-arrayRené Scharfe2014-10-191-11/+4
| | | | | | | | | | | | | | | | | | | | | | Convert users of struct child_process to using the managed env_array for specifying environment variables instead of supplying an array on the stack or bringing their own argv_array. This shortens and simplifies the code and ensures automatically that the allocated memory is freed after use. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'rs/child-process-init'Junio C Hamano2014-09-111-1/+1
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | Code clean-up. * rs/child-process-init: run-command: inline prepare_run_command_v_opt() run-command: call run_command_v_opt_cd_env() instead of duplicating it run-command: introduce child_process_init() run-command: introduce CHILD_PROCESS_INIT
| * | run-command: introduce CHILD_PROCESS_INITRené Scharfe2014-08-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Most struct child_process variables are cleared using memset first after declaration. Provide a macro, CHILD_PROCESS_INIT, that can be used to initialize them statically instead. That's shorter, doesn't require a function call and is slightly more readable (especially given that we already have STRBUF_INIT, ARGV_ARRAY_INIT etc.). Helped-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | pager.c: replace `git_config()` with `git_config_get_value()`Tanay Abhra2014-08-071-27/+13
|/ / | | | | | | | | | | | | | | | | Use `git_config_get_value()` instead of `git_config()` to take advantage of the config-set API which provides a cleaner control flow. Signed-off-by: Tanay Abhra <tanayabh@gmail.com> Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'je/pager-do-not-recurse'Junio C Hamano2014-06-061-1/+1
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | We used to unconditionally disable the pager in the pager process we spawn to feed out output, but that prevented people who want to run "less" within "less" from doing so. * je/pager-do-not-recurse: pager: do allow spawning pager recursively
| * | pager: do allow spawning pager recursivelyjn/pager-do-not-recurseje/pager-do-not-recurseJörn Engel2014-04-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 88e8f908f2b0c56f9ccf8134d8ff9f689af9cc84, which tried to allow GIT_PAGER="git -p column --mode='dense color'" git -p branch and still wanted to avoid "git -p column" to invoke itself. However, this falls into "don't do that -p then" category. In particular, inside "git log", with results going through less, a potentially interesting commit may be found and from there inside "less", the user may want to execute "git show <commit>". Before the commit being reverted, this used to show the patch in less but it no longer does. Signed-off-by: Jörn Engel <joern@logfs.org> Reviewed-by: Jeff King <peff@peff.net> Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr> Acked-by: Duy Nguyen <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | pager: remove 'S' from $LESS by defaultmm/pager-less-sans-SMatthieu Moy2014-05-071-1/+1
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | By default, Git used to set $LESS to -FRSX if $LESS was not set by the user. The FRX flags actually make sense for Git (F and X because sometimes the output Git pipes to less is short, and R because Git pipes colored output). The S flag (chop long lines), on the other hand, is not related to Git and is a matter of user preference. Git should not decide for the user to change LESS's default. More specifically, the S flag harms users who review untrusted code within a pager, since a patch looking like: -old code; +new good code; [... lots of tabs ...] malicious code; would appear identical to: -old code; +new good code; Users who prefer the old behavior can still set the $LESS environment variable to -FRSX explicitly, or set core.pager to 'less -S'. The documentation in config.txt is made a bit longer to keep both an example setting the 'S' flag (needed to recover the old behavior) and an example showing how to unset a flag set by Git. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'jn/pager-lv-default-env'Junio C Hamano2014-01-131-2/+9
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | Just like we give a reasonable default for "less" via the LESS environment variable, specify a reasonable default for "lv" via the "LV" environment variable when spawning the pager. * jn/pager-lv-default-env: pager: set LV=-c alongside LESS=FRSX
| * | pager: set LV=-c alongside LESS=FRSXJonathan Nieder2014-01-071-2/+9
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On systems with lv configured as the preferred pager (i.e., DEFAULT_PAGER=lv at build time, or PAGER=lv exported in the environment) git commands that use color show control codes instead of color in the pager: $ git diff ^[[1mdiff --git a/.mailfilter b/.mailfilter^[[m ^[[1mindex aa4f0b2..17e113e 100644^[[m ^[[1m--- a/.mailfilter^[[m ^[[1m+++ b/.mailfilter^[[m ^[[36m@@ -1,11 +1,58 @@^[[m "less" avoids this problem because git uses the LESS environment variable to pass the -R option ('output ANSI color escapes in raw form') by default. Use the LV environment variable to pass 'lv' the -c option ('allow ANSI escape sequences for text decoration / color') to fix it for lv, too. Noticed when the default value for color.ui flipped to 'auto' in v1.8.4-rc0~36^2~1 (2013-06-10). Reported-by: Olaf Meeuwissen <olaf.meeuwissen@avasys.jp> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | replace {pre,suf}fixcmp() with {starts,ends}_with()cc/starts-n-ends-withChristian Couder2013-12-051-1/+1
|/ | | | | | | | | | | | | | | | | | | | | | | Leaving only the function definitions and declarations so that any new topic in flight can still make use of the old functions, replace existing uses of the prefixcmp() and suffixcmp() with new API functions. The change can be recreated by mechanically applying this: $ git grep -l -e prefixcmp -e suffixcmp -- \*.c | grep -v strbuf\\.c | xargs perl -pi -e ' s|!prefixcmp\(|starts_with\(|g; s|prefixcmp\(|!starts_with\(|g; s|!suffixcmp\(|ends_with\(|g; s|suffixcmp\(|!ends_with\(|g; ' on the result of preparatory changes in this series. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* pager: turn on "cat" optimization for DEFAULT_PAGERjk/pager-bypass-cat-for-default-pagerJeff King2013-09-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the user specifies a pager of "cat" (or the empty string), whether it is in the environment or from config, we automagically optimize it out to mean "no pager" and avoid forking at all. We treat an empty pager variable similary. However, we did not apply this optimization when DEFAULT_PAGER was set to "cat" (or the empty string). There is no reason to treat DEFAULT_PAGER any differently. The optimization should not be user-visible (unless the user has a bizarre "cat" in their PATH). And even if it is, we are better off behaving consistently between the compile-time default and the environment and config settings. The stray "else" we are removing from this code was introduced by 402461a (pager: do not fork a pager if PAGER is set to empty., 2006-04-16). At that time, the line directly above used: if (!pager) pager = "less"; as a fallback, meaning that it could not possibly trigger the optimization. Later, a3d023d (Provide a build time default-pager setting, 2009-10-30) turned that constant into a build-time setting which could be anything, but didn't loosen the "else" to let DEFAULT_PAGER use the optimization. Noticed-by: Dale R. Worley <worley@alum.mit.edu> Suggested-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Move setup_diff_pager to libgit.aNguyễn Thái Ngọc Duy2012-10-291-0/+34
| | | | | | | | | | | | This is used by diff-no-index.c, part of libgit.a while it stays in builtin/diff.c. Move it to diff.c so that we won't get undefined reference if a program that uses libgit.a happens to pull it in. While at it, move check_pager from git.c to pager.c. It makes more sense there and pager.c is also part of libgit.a Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Jeff King <peff@peff.net>
* pager: drop "wait for output to run less" hackJeff King2012-06-051-18/+0
| | | | | | | | | | | | | | | | | | | Commit 35ce862 (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 entirely. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Stop starting pager recursivelyNguyễn Thái Ngọc Duy2012-04-271-1/+1
| | | | | | | | | | | | | | | | | git-column can be used as a pager for other git commands, something like this: GIT_PAGER="git -p column --mode='dense color'" git -p branch The problem with this is that "git -p column" also has $GIT_PAGER set so the pager runs itself again as another pager. The end result is an infinite loop of forking. Other git commands have the same problem if being abused this way. Check if $GIT_PAGER is already set and stop launching another pager. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'zj/decimal-width'Junio C Hamano2012-02-201-0/+12
|\ | | | | | | | | | | | | | | | | * zj/decimal-width: make lineno_width() from blame reusable for others Conflicts: cache.h pager.c
| * make lineno_width() from blame reusable for otherszj/decimal-widthZbigniew Jędrzejewski-Szmek2012-02-141-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | builtin/blame.c has a helper function to compute how many columns we need to show a line-number, whose implementation is reusable as a more generic helper function to count the number of columns necessary to show any cardinal number. Rename it to decimal_width(), move it to pager.c and export it for use by future callers. Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | pager: find out the terminal width before spawning the pagerzj/term-columnsZbigniew Jędrzejewski-Szmek2012-02-131-0/+37
|/ | | | | | | | | | | | | | | | term_columns() checks for terminal width via ioctl(2) on the standard output, but we spawn the pager too early for this check to be useful. The effect of this buglet can be observed by opening a wide terminal and running "git -p help --all", which still shows 80-column output, while "git help --all" uses the full terminal width. Run the check before we spawn the pager to fix this. While at it, move term_columns() to pager.c and export it from cache.h so that callers other than the help subsystem can use it. Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* setup_pager: set GIT_PAGER_IN_USEJeff King2011-08-181-7/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | We have always set a global "spawned_pager" variable when we start the pager. This lets us make the auto-color decision later in the program as as "we are outputting to a terminal, or to a pager which can handle colors". Commit 6e9af86 added support for the GIT_PAGER_IN_USE environment variable. An external program calling git (e.g., git-svn) could set this variable to indicate that it had already started the pager, and that the decision about auto-coloring should take that into account. However, 6e9af86 failed to do the reverse, which is to tell external programs when git itself has started the pager. Thus a git command implemented as an external script that has the pager turned on (e.g., "git -p stash show") would not realize it was going to a pager, and would suppress colors. This patch remedies that; we always set GIT_PAGER_IN_USE when we start the pager, and the value is respected by both this program and any spawned children. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Make 'git var GIT_PAGER' always print the configured pagerJonathan Nieder2010-02-141-3/+3
| | | | | | | | | | | | | | | | | | | | | | Scripted commands that want to use git’s configured pager know better than ‘git var’ does whether stdout is going to be a tty at the appropriate time. Checking isatty(1) as git_pager() does now won’t cut it, since the output of git var itself is almost never a terminal. The symptom is that when used by humans, ‘git var GIT_PAGER’ behaves as it should, but when used by scripts, it always returns ‘cat’! So avoid tricks with isatty() and just always print the configured pager. This does not fix the callers to check isatty(1) themselves yet. Nevertheless, this patch alone is enough to fix 'am --interactive'. Thanks to Sebastian Celis for the report and Jeff King for the analysis. Reported-by: Sebastian Celis <sebastian@sebastiancelis.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* run-command: convert simple callsites to use_shellJeff King2010-01-051-2/+3
| | | | | | | | Now that we have the use_shell feature, these callsites can all be converted with small changes. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Provide a build time default-pager settingJunio C Hamano2009-11-131-1/+5
| | | | | | | | | | | | | | | | | | | | | | | Provide a DEFAULT_PAGER knob so packagers can set the fallback pager to something appropriate during the build. Examples: On (old) solaris systems, /usr/bin/less (typically the first less found) doesn't understand the default arguments (FXRS), which forces users to alter their environment (PATH, GIT_PAGER, LESS, etc) or have a local or global gitconfig before paging works as expected. On Debian systems, by policy packages must fall back to the 'pager' command, so that changing the target of the /usr/bin/pager symlink changes the default pager for all packages at once. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Teach git var about GIT_PAGERJonathan Nieder2009-11-131-3/+15
| | | | | | | | | Expose the command found by setup_pager() for scripts to use. Scripts can use this to avoid repeating the logic to look for a proper pager in each command. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Test for WIN32 instead of __MINGW32_Frank Li2009-09-181-2/+2
| | | | | | | | | | | | | | | The code which is conditional on MinGW32 is actually conditional on Windows. Use the WIN32 symbol, which is defined by the MINGW32 and MSVC environments, but not by Cygwin. Define SNPRINTF_SIZE_CORR=1 for MSVC too, as its vsnprintf function does not add NUL at the end of the buffer if the result fits the buffer size exactly. Signed-off-by: Frank Li <lznuaa@gmail.com> Signed-off-by: Marius Storm-Olsen <mstormo@gmail.com> Acked-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* pager: set LESS=FRSX also on WindowsJohannes Sixt2009-09-111-2/+4
| | | | | | | | | | | | | | Previously, this environment variable was set in the pager_preexec callback, which is conditionally-compiled only on Unix, because it is not, and cannot be, called on Windows. With this patch the env member of struct child_process is used to set the environment variable, which also works on Windows. Noticed by Alexey Borzenkov. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* pager: do wait_for_pager on signal deathJeff King2009-01-211-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | Since ea27a18 (spawn pager via run_command interface), the original git process actually does git work, and the pager is a child process (actually, on Windows it has always been that way, since Windows lacks fork). After spawning the pager, we register an atexit() handler that waits for the pager to finish. Unfortunately, that handler does not always run. In particular, if git is killed by a signal, then we exit immediately. The calling shell then thinks that git is done; however, the pager is still trying to run and impact the terminal. The result can be seen by running a long git process with a pager (e.g., "git log -p") and hitting ^C. Depending on your config, you should see the shell prompt, but pressing a key causes the pager to do any terminal de-initialization sequence. This patch just intercepts any death-dealing signals and waits for the pager before dying. Under typical less configuration, that means hitting ^C will cause git to stop generating output, but the pager will keep running. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'maint'Junio C Hamano2008-12-151-1/+2
|\ | | | | | | | | | | | | * maint: fast-import: close pack before unlinking it pager: do not dup2 stderr if it is already redirected git-show: do not segfault when showing a bad tag
| * pager: do not dup2 stderr if it is already redirectedJunio C Hamano2008-12-151-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An earlier commit 61b8050 (sending errors to stdout under $PAGER, 2008-02-16) avoided losing the error messages that are sent to the standard error when $PAGER is in effect by dup2'ing fd 2 to the pager. his way, showing a tag object that points to a bad object: $ git show tag-foo would give the error message to the pager. However, it was not quite right if the user did: $ git show 2>error.log tag-foo i.e. use the pager but store the errors in a separate file. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | spawn pager via run_command interfaceJeff King2008-07-251-44/+11
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This has two important effects: 1. The pager is now the _child_ process, instead of the parent. This means that whatever spawned git (e.g., the shell) will see the exit code of the git process, and not the pager. 2. The mingw and regular code are now unified, which makes the setup_pager function much simpler. There are two caveats: 1. We used to call execlp directly on the pager, followed by trying to exec it via the shall. We now just use the shell (which is what mingw has always done). This may have different results for pager names which contain shell metacharacters. It is also slightly less efficient because we unnecessarily run the shell; however, pager spawning is by definition an interactive task, so it shouldn't be a huge problem. 2. The git process will remain in memory while the user looks through the pager. This is potentially wasteful. We could get around this by turning the parent into a meta-process which spawns _both_ git and the pager, collects the exit status from git, waits for both to end, and then exits with git's exit code. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Windows: Make the pager work.Johannes Sixt2008-06-261-2/+38
| | | | | | | Since we have neither fork() nor exec(), we have to spawn the pager and feed it with the program's output. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
* Provide git_config with a callback-data parameterJohannes Schindelin2008-05-141-1/+1
| | | | | | | | | | | | git_config() only had a function parameter, but no callback data parameter. This assumes that all callback functions only modify global variables. With this patch, every callback gets a void * parameter, and it is hoped that this will help the libification effort. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* sending errors to stdout under $PAGERJunio C Hamano2008-02-171-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If you do this (and you are not an Emacs user who uses PAGER=cat in your *shell* buffer): $ git init Initialized empty Git repository in .git/ $ echo hello world >foo $ H=$(git hash-object -w foo) $ git tag -a foo-tag -m "Tags $H" $H $ echo $H 3b18e512dba79e4c8300dd08aeb37f8e728b8dad $ rm -f .git/objects/3b/18e5* $ git show foo-tag tag foo-tag Tagger: Junio C Hamano <gitster@pobox.com> Date: Sat Feb 16 10:43:23 2008 -0800 Tags 3b18e512dba79e4c8300dd08aeb37f8e728b8dad you do not get any indication of error. If you are careful, you would notice that no contents from the tagged object is displayed, but that is about it. If you run the "show" command without pager, however, you will see the error: $ git --no-pager show foo-tag tag foo-tag Tagger: Junio C Hamano <gitster@pobox.com> Date: Sat Feb 16 10:43:23 2008 -0800 Tags 3b18e512dba79e4c8300dd08aeb37f8e728b8dad error: Could not read object 3b18e512dba79e4c8300dd08aeb37f8e728b8dad Because we spawn the pager as the foreground process and feed its input via pipe from the real command, we cannot affect the exit status the shell sees from git command when the pager is in use (I think there is not much gain we can have by working it around, though). But at least it may make sense to show the error message to the user sitting in front of the pager. [jc: Edgar Toernig suggested a much nicer implementation than what I originally posted, which I took.] Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Support GIT_PAGER_IN_USE environment variableJeff King2007-12-111-1/+14
| | | | | | | | | | | | | | | | | | | When deciding whether or not to turn on automatic color support, git_config_colorbool checks whether stdout is a tty. However, because we run a pager, if stdout is not a tty, we must check whether it is because we started the pager. This used to be done by checking the pager_in_use variable. This variable was set only when the git program being run started the pager; there was no way for an external program running git indicate that it had already started a pager. This patch allows a program to set GIT_PAGER_IN_USE to a true value to indicate that even though stdout is not a tty, it is because a pager is being used. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Move #include <sys/select.h> and <sys/ioctl.h> to git-compat-util.h.Johannes Sixt2007-11-141-2/+0
| | | | | | | ... since all system headers are pulled in via git-compat-util.h Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* pager: find out pager setting from configurationJunio C Hamano2007-08-061-1/+4
| | | | | | | | | | | | | | | | | | | | | It was very unfortunate that we added core.pager setting to the configuration file; even when the underlying command does not care if there is no git repository is involved (think "git diff --no-index"), the user would now rightfully want the configuration setting to be honored, which means we would need to read the configuration file before we launch the pager. This is a minimum change in the sense that it restores the old behaviour of not even reading config in setup_git_directory(), but have the core.pager honored when we know it matters. Note that this does not cover "git -p --git-dir where command"; the -p option immediately trigger the pager settings before we even see --git-dir to learn where the configuration file is, so we will end up reading the configuration from the place where we would _normally_ find the git repository. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Add core.pager config variable.Brian Gernhardt2007-07-041-0/+2
| | | | | | | | | This adds a configuration variable that performs the same function as, but is overridden by, GIT_PAGER. Signed-off-by: Brian Gernhardt <benji@silverinsanity.com> Acked-by: Johannes E. Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* pager: Work around window resizing bug in 'less'Linus Torvalds2007-02-051-0/+12
| | | | | | | | | | | | | | | | | | | | If you resize the terminal while less is waiting for input, less will exit entirely without even showing the output. This is very noticeable if you do something like "git diff" on a big and cold-cache tree and git takes a few seconds to think, and then you resize the window while it's preparing. Boom. No output AT ALL. The way to reproduce the problem is to do some pager operation that takes a while in git, and resizing the window while git is thinking about the output. Try git diff --stat v2.6.12.. in the kernel tree to do something where it takes a while for git to start outputting information. Signed-off-by: Junio C Hamano <junkio@cox.net>
* pager: default to LESS=FRSX not LESS=FRSJunio C Hamano2006-10-221-1/+1
| | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
* pager: default to LESS=FRSJunio C Hamano2006-10-201-1/+1
| | | | | | | | Recent change to paginate "git diff" by default is often irritating when you do not have any change (or very small change) in your working tree. Signed-off-by: Junio C Hamano <junkio@cox.net>
* pager: environment variable GIT_PAGER to override PAGERMatthias Lederhofer2006-07-311-1/+3
| | | | | Signed-off-by: Matthias Lederhofer <matled@gmx.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
View Lorry Controller Status