summaryrefslogtreecommitdiff
path: root/t/test-terminal.perl
AgeCommit message (Collapse)AuthorFilesLines
2020-09-21t/test-terminal: avoid non-inclusive languageLibravatar Johannes Schindelin1-16/+16
In the ongoing effort to make the Git project a more inclusive place, let's try to avoid names like "master" where possible. In this instance, the use of the term `slave` is unfortunately enshrined in IO::Pty's API. We simply cannot avoid using that word here. But at least we can get rid of the usage of the word `master` and hope that IO::Pty will be eventually adjusted, too. Guessing that IO::Pty might follow Python's lead, we replace the name `master` by `parent` (hoping that IO::Pty will adopt the parent/child nomenclature, too). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-04test-terminal: set TERM=vt100Libravatar Jeff King1-0/+1
The point of the test-terminal script is to simulate in the test scripts an environment where output is going to a real terminal. But since test-lib.sh also sets TERM=dumb, the simulation isn't very realistic. The color code will skip auto-coloring for TERM=dumb, leading to us liberally sprinkling test_terminal env TERM=vt100 git ... through the test suite to convince the tests to actually generate colors. Let's set TERM for programs run under test_terminal, which is one less thing for test-writers to remember. In most cases the callers can be simplified, but note there is one interesting case in t4202. It uses test_terminal to check the auto-enabling of --decorate, but the expected output _doesn't_ contain colors (because TERM=dumb suppresses them). Using TERM=vt100 is closer to what the real world looks like; adjust the expected output to match. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-12test_terminal: redirect child process' stdin to a ptyLibravatar Paul Tan1-4/+28
When resuming, git-am detects if we are trying to feed it patches or not by checking if stdin is a TTY. However, the test library redirects stdin to /dev/null. This makes it difficult, for instance, to test the behavior of "git am -3" when resuming, as git-am will think we are trying to feed it patches and error out. Support this use case by extending test-terminal.perl to create a pseudo-tty for the child process' standard input as well. Note that due to the way the code is structured, the child's stdin pseudo-tty will be closed when we finish reading from our stdin. This means that in the common case, where our stdin is attached to /dev/null, the child's stdin pseudo-tty will be closed immediately. Some operations like isatty(), which git-am uses, require the file descriptor to be open, and hence if the success of the command depends on such functions, test_terminal's stdin should be redirected to a source with large amount of data to ensure that the child's stdin is not closed, e.g. test_terminal git am --3way </dev/zero Cc: Jonathan Nieder <jrnieder@gmail.com> Cc: Jeff King <peff@peff.net> Signed-off-by: Paul Tan <pyokagan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-06run-command: encode signal death as a positive integerLibravatar Jeff King1-1/+1
When a sub-command dies due to a signal, we encode the signal number into the numeric exit status as "signal - 128". This is easy to identify (versus a regular positive error code), and when cast to an unsigned integer (e.g., by feeding it to exit), matches what a POSIX shell would return when reporting a signal death in $? or through its own exit code. So we have a negative value inside the code, but once it passes across an exit() barrier, it looks positive (and any code we receive from a sub-shell will have the positive form). E.g., death by SIGPIPE (signal 13) will look like -115 to us in inside git, but will end up as 141 when we call exit() with it. And a program killed by SIGPIPE but run via the shell will come to us with an exit code of 141. Unfortunately, this means that when the "use_shell" option is set, we need to be on the lookout for _both_ forms. We might or might not have actually invoked the shell (because we optimize out some useless shell calls). If we didn't invoke the shell, we will will see the sub-process's signal death directly, and run-command converts it into a negative value. But if we did invoke the shell, we will see the shell's 128+signal exit status. To be thorough, we would need to check both, or cast the value to an unsigned char (after checking that it is not -1, which is a magic error value). Fortunately, most callsites do not care at all whether the exit was from a code or from a signal; they merely check for a non-zero status, and sometimes propagate the error via exit(). But for the callers that do care, we can make life slightly easier by just using the consistent positive form. This actually fixes two minor bugs: 1. In launch_editor, we check whether the editor died from SIGINT or SIGQUIT. But we checked only the negative form, meaning that we would fail to notice a signal death exit code which was propagated through the shell. 2. In handle_alias, we assume that a negative return value from run_command means that errno tells us something interesting (like a fork failure, or ENOENT). Otherwise, we simply propagate the exit code. Negative signal death codes confuse us, and we print a useless "unable to run alias 'foo': Success" message. By encoding signal deaths using the positive form, the existing code just propagates it as it would a normal non-zero exit code. The downside is that callers of run_command can no longer differentiate between a signal received directly by the sub-process, and one propagated. However, no caller currently cares, and since we already optimize out some calls to the shell under the hood, that distinction is not something that should be relied upon by callers. Fix the same logic in t/test-terminal.perl for consistency [jc: raised by Jonathan in the discussion]. Signed-off-by: Jeff King <peff@peff.net> Acked-by: Johannes Sixt <j6t@kdbg.org> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-19test-terminal: set output terminals to raw modeLibravatar Thomas Rast1-0/+4
Not setting them to raw mode causes funny things to happen, such as \n -> \r\n translation: ./test-terminal.perl echo foo | xxd 0000000: 666f 6f0d 0a foo.. (Notice the added 0d.) To avoid this, set the (pseudo)terminal to raw mode. Note that the IO::Pty docs recommend doing it on both master and slave. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Acked-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-17Merge branch 'jk/push-progress'Libravatar Junio C Hamano1-0/+76
* jk/push-progress: push: pass --progress down to git-pack-objects t5523-push-upstream: test progress messages t5523-push-upstream: add function to ensure fresh upstream repo test_terminal: ensure redirections work reliably test_terminal: catch use without TTY prerequisite test-lib: allow test code to check the list of declared prerequisites tests: test terminal output to both stdout and stderr tests: factor out terminal handling from t7006
2010-10-18tests: test terminal output to both stdout and stderrLibravatar Jeff King1-7/+24
Some outputs (like the pager) care whether stdout is a terminal. Others (like progress meters) care about stderr. This patch sets up both. Technically speaking, we could go further and set up just one (because either the other goes to a terminal, or because our tests are only interested in one). This patch does both to keep the interface to lib-terminal simple. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-18tests: factor out terminal handling from t7006Libravatar Jeff King1-0/+58
Other tests besides the pager ones may want to check how we handle output to a terminal. This patch makes the code reusable. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>