I have installed multiple versions of git for windows, but every version I have tried so far acts the same. If I have a bunch of output lines in the terminal, scroll up to see some of the earlier outputs, the window will automatically take me back to the bottom at the prompt. It seems to be happening on an interval about 5 seconds apart. I tried replicating the issue with CMD and powershell, but it only happens in git bash. Even just running bash.exe inside the bin folder doesn't produce the auto scrolling, just git-bash.exe. Any ideas why this is happening or how to stop it?
Edit1: It seems as though it is automatically executing a page down command. If I use the less command, it automatically goes page by page. I thought maybe it was a keyboard issue but this is the only application that seems to be doing this.
Edit2: I wrote a quick bash script that logs input to a file.
while true; do
read -s -n 1 input
echo $input >> file.txt
done
I printed the contents of the file using od -c file.txt. The output after a few seconds is below.
0000000 \n \n 177 \n \n 177 \n \n 177 \n \n 177 \n \n \n 177
0000020 \n \n 177 \n \n 177 \n \n
0000030
Does anyone know how to stop it? Does this look like a keyboard issue?
In Git Bash:
Options ► Mouse ► uncheck "Copy on select"
In order to make up for not having the copy on select functionality:
Options ► Keys ► Ctl+Shift+letter shortcut
Should allow you to use Ctl+Shift+C for copying.
Obviously this is just a workaround. I was in the process of searching to see if a bug has been created for this issue when I found this post.
Edit: For completeness, I'm using git version 2.10.1.windows.1
I have noted this behavior from Git Bash when the window size is smaller than some multiple of the font height. Making the window taller or the font smaller seems to fix it.
Related
TL;DR?
How can I change every instance of one character (e.g. 'E') in a terminal window to another string of characters (e.g. '~E'), moving all other characters along in the window in the process? So:
abcdEfghij
becomes:
abcd~Efghij
This should work in the gnome-terminal and work with whatever output is on that terminal, from whatever program. Ideally it will be a script or other program I can run within that terminal emulator.
The context
I am using a Braille display (the Canute 360) with a Braille screen-reader (brltty), which at present does not support capital letters. They show up in Braille the same as lower-case letters. Until this is developed for BRLTTY I sometimes need to be able to force showing which letters are capitalised in order for me to, for example, write code.
The proposed solution
N.B. The below proposed solution is not intended to be elegant; it is a quick and dirty way of letting me and other Braille-using developers continue to program with this display for our work until the proper solution is forthcoming in the screen-reader proper.
I am trying to essentially 'wrap' the output of the terminal emulator (in this case gnome-terminal to force a certain character in front of every capital letter so on the Braille display it can be identified. I am going to assume that character is tilde (~). I am not concerned about this breaking vertical alignment, or forcing the line off the edge of the display. I am assuming a 40 character wide terminal (width of the Canute).
So this normal output:
$ echo ${string}
A Quick Brown Fox
Jumps over the lazy
Dog. Etc.
$
Becomes this:
$ echo ${string}
~A ~Quick ~Brown ~Fox
~Jumps over the lazy
~Dog. ~Etc.
$
That would then be viewable on the Canute (in US Computer Braille) as this:
$ echo ${string}
~a ~quick ~brown ~fox
~jumps over the lazy
~dog. ~etc.
$
It is fine for this to be a command that has to be called first, like screen. So:
$ caps-hack
$ nano
[doing my thing, then quit nano]
$
[ctrl-x to quit caps-hack]
$
Or alternatively it could launch a new terminal window, or it could be tied to specific TUI applications (like nano). I will primarily be using it for working inside vi, nano, micro and other editors, so if it cannot capture all terminal output the solution is still valuable.
Example use case: Micro/nano text editor
When I need to see capitals whilst editing text using micro or nano I would first launch caps-hack, then I could use the TUI editor, exit it, be back on the terminal, then cancel caps-hack if I wanted to revert to usual behaviour.
This is what nano normally looks like:
GNU nano 4.8 New Buffer Modified
This is a nonsense file for
Stackoverflow.
^G Get Hel^O Write O^W Where I^K Cut Tex
^X Exit ^R Read Fi^\ Replace^U Paste T
I'm looking for a solution that would then make it look like this:
~G~N~U nano 4.8 ~New ~Buffer ~Modi
~This is a nonsense file for
~Stackoverflow.
^~G Get ~Hel^~O ~Write ~O^~W ~Where ~I^~
^~X ~Exit ^~R ~Read ~Fi^\ ~Replace^~U
(Note that I have cut it off at 40 characters.)
The effect would be the same (inserting tildes, cutting off at 40 characters) whether I was in the terminal itself, in mc, or watching a ping stream.
This active use case means that so far as I can see I cannot simply pipe the output of programs to a bash script (like the one below), as that wouldn't work with a TUI. So I cannot do: $ nano myfile.txt | caps-hack
What I have tried so far
I have not worked out how to essentially capture the output, modify it and write it back to the terminal window. However I have the following shell snippet which I believe could be used for it, if I know where to put it.
# Repeat for all visible lines in the terminal
moddedline1=$( echo ${originalLine1} | sed -E -e 's/\([A-Z]\)/~\1/g' )
moddedline1="${moddedline1:0:40}"
tput cup 1 0 && printf "${moddedline1}"
I am currently writing a small game in gawk and i am using a Raspberry Pi with gawk installed.
After saving my code on a windows editor to move the file to my raspberry, i encountered some problems with the encoding (had to remove some pesky ^M chars). The file is saved in UTF-8 ('locale' tells me the LANG=en_GB.UTF-8). :set encoding? in vim is telling me im using UTF-8 too (same goes for :set fileencoding? ).
When i try to execute my code, which is saved as a .sh script, the interpreter stops at the first OR sign "|"
while ((FieldSize !~ /^[[:digit:]]+$/) || (FieldSize < 4))
The error message is: invalid char 'squarishlooking char' in expression.
I have tried several fixes, i also viewed the file in the hexview and both |-chars are correctly identified as '7C', the hexvalue of | in the ascii-chart.
The error only happens when i use the combination AltGr-7 to input the character into vim. The error wont happen if i enter the INSERT-mode of vim and use Ctrl-V 124 (which is the dez-value of | in the ascii chart). If i view either of the 2 options in a hexview, the chars are correctly nested between a space-char (hex: 20) on either side --> 20 7c 7c 20.
I am now also highlighting nonascii-chars in my vim with
syntax match nonascii "[^\x00-\x7F]"
highlight nonascii guibg=Red ctermbg=2
and the pipe-char only gets highlighted when i use altGr-7.
Always using ctrl-V xxx isnt really a desriable solution in my humble opinion.
I want my script to work when i use AltGr-7 for putting in a "|". Is there any soltution to this apart from the workaround with ctrl-V 124?
squarishlooking char means it isn't a normal pipe. It is something your terminal doesn't have a character for. If you can't see that with xxd then you likely aren't looking at the right file/place.
This is not a shell script, but an awk script. You see the shell complaining that it does not understand what to do with two pipes right after each other. This would be the standalone version:
#!/usr/bin/gawk -f
# your code here
Then, your OS will figure out automatically from the HashBang (#!) to run gawk with it.
Alternatively, this would also work, by running first a new shell, which calls an awk command:
#!/usr/bin/env sh
awk 'your awk code here'
I have an Executable which shows progress bar on terminal. when i redirect the output to a file in th ebelow manner
the below command is embedded in a script file
usr/bin/exec >> log.txt
this is terminal out put
Progress [====================================> ] 58%
But the log.txt looks some thing like this
Progress [=> ] 0
Progress [====> ] 5
Progress [========> ] 10
can i redirect the output in same way as it is shown on terminal.
A related answer on a different site, suggests the col command.
To suppress overwritten output on standard out prior to writing to the file:
usr/bin/exec | col -b >> log.txt
To view the contents of a file while suppressing overwritten characters:
col -b < log.txt | less
Your progress bar probably works by using a carriage return to signal that the current line should be overwritten. The col utility buffers the output so that it can print only the last character for each position.
There's no way to answer this with certainty without knowing exactly what your progress-bar program is doing, but...
The way such a progress bar is typically done is by outputting the current progress update, but then putting an ascii CR (carriage return) at the end of the line without an LF (line feed). This resets the display cursor to the beginning of the line without moving the cursor down to the next line so that each subsequent progress update overwrites the previous one. So probably, if you're redirecting that to a file, you'll have the same content in the file.
If you were to view such a file with vi, you'll actually see the embedded CRs, indicated as "^M" (but note that LF characters are simply interpreted as end-of-line and aren't actually displayed). If you view the file with another editor, it might interpret CR characters as a valid end-of-line indicator and show you each line as a separate line with or without LF characters.
You don't say how you're displaying the log.txt file. I would expect that if the program were using the embedded CR method, then using "cat log.txt" would show the same output as in interactive use: that is, each progress update "line" would overwrite the previous one and only the last one would be visible at the end.
It's also possible that the program outputting the progress bar is sensitive to whether it's displaying to a terminal device or not: i.e. it might be calling isatty() and modifying its output accordingly.
It might be instructive to run this command on your final log.txt file to see the actual binary content:
od -tx1z log.txt
A CR (aka ^M) will show up as "0d". An LF (aka ^J) will show up as 0a.
I have cygwin installed on my Windows 7 box and I have been running into a problem where when I type a command it will occasionally be wrapped back onto the same line, deleting the bash prompt. Here is an example:
The command in question is command "201" (4 lines from the bottom). I included the others for context.
The text of the command I was typing was
git commit -m "Forced LF line endings."
(Note: I am posting this with mostly git commands, but the problem occurs with any command. I have not noticed a pattern yet.)
It jumped to the start of the line and started to overwrite my prompt.
When I push the up arrow (to view the history) the result is even weirder:
(Note the cursor is many characters past the end of the command.)
When I try to backspace the cursor from that position, I can only go back this far:
Then when I go up into the history from that backspaced line, I get this:
The command starts from the end of the text that is displayed. (This is consistent for the entire history) But when I go up in the history to the faulty git commit ... it displays as it did before with the overwritten text but when I go past it, it deletes a line of the prompt and displays the previous entry in the history the same way it was doing it before (a la image 2).
When I was creating my PS1 variable I has odd output like this, but I have since closed my brackets and things and don't think that is causing the issue. However if you would like to see my .bash_profile (that sets the PS1) feel free to see it on GitHub. It is really short.
I have tried searching for the issue and can only find a few cygwin email archives about the line wrapping in xterm, but no solutions.
PS: As I was pushing the latest .bash_profile, in order to link it, I ran into the problem again when I typed git add .bash_profile and hit enter, it ran the command but returned the cursor to the start of the same command instead of printing a new prompt.
Then when I as writing another commit line, it did the same as the first image, but it blacked out the rest of the line (It wrapped the line, but overwrote the entire line and not just the first few chars.)
See http://manpages.ubuntu.com/manpages/lucid/man1/bash.1.html#contenttoc26:
\[
begin a sequence of non-printing characters, which could be used to embed a terminal control sequence into the prompt
\]
end a sequence of non-printing characters
If you don't enclose non-printing characters (e.g. color sequences) in your prompt with these their length is counted as part of the prompt's length, eventually resulting in the symptoms that you describe.
It doesn't occur frequently to me. When it does, I just type in 'kill -WINCH $$' into the cygwin terminal and it fixes the problem. link to source
I'd like to have a blank line after my bash prompt and before the output on my Mac. It should look like this would:
echo; ls
Can I add a newline to my bash prompt and then go back up one line to wait for user input? Is there something obvious I'm missing?
I know this is old but for someone like me who came across this while googling for it. This is how you do this...
It's actually pretty simple!
Check out this link --> Cursor Movement
Basically to move up N number of lines:
echo -e "\033[<N>A HELLO WORLD\n"
Just change the "< N >" to however many lines you want to go back...
For instance, to move up 5 lines it would be "/033[5A"
To my knowledge this is not possible unless you delve into more low-level stuff like full-screen emulators like curses.
This is a bit of a stab in the dark, but you may be able to use VT102 terminal codes to control the cursor without having to use Curses. The relevant VT102 commands that you'd be interested in all consist of sending ESC, then [, then the specific command parameters.
For instance, to move the cursor up one line, one needs to output:
ESC [ 1 A
0x1B 0x5B 0x31 0x41
Be warned that the VT102 documentation generally uses octal, so keep an ascii table handy if you're using hex.
All of this advice is given without having tested it -- I don't know if VT102 commands can be embedded into your bash prompt, but I thought it might be worth a shot.
Edit: Yeah -- looks like a lot of people use VT102 formatting codes in their bash prompts. To translate my above example into something Bash would recognize, putting:
\e[1A
into your prompt should move the cursor up one line.
This is very possible. If your bash has C-v set as the readline quoted-insert command, you can simply add the following to your ~/.inputrc:
RETURN: "\C-e\C-v\n\C-v\n\n"
This wil make bash (readline, actually) insert two verbatim newlines before a regular interpreted newline. By default, only one is inserted, which is what causes output to start on the line after the prompt.
You can test if C-v is set to quoted-insert by typing it in bash (that's Ctrl+V) followed by e.g. an up arrow. This should print ^[[A or something similar. If it doesn't, you can bind it in ~/.inputrc too:
C-v: quoted-insert
RETURN: "\C-e\C-v\n\C-v\n\n"
~/.inputrc can be created if it doesn't exist. The changes will not take effect in running bashes unless you issue a readline re-read-init-file command (by default on C-x C-r). Be careful though. If you do something wrong, enter will no longer issue commands, and fixing your mistake could prove to be difficult. If you should do something wrong, C-o will by default also accept the line.
Adding a newline followed by moving the cursor back to the regular prompt (like you described) is possible, but will not have the effect you intend. The newline you inserted would simply be overwritten by the application output, since you moved the cursor back in front of it.
This works:
trap echo DEBUG
It doesn't add an extra newline if you hit return at an empty prompt.
The command above will cause a newline to be output for every member of a pipeline or multi-command line such as:
$ echo foo; echo bar
\n
foo
\n
bar
To prevent that so that only one extra newline is output before all command output:
PROMPT_COMMAND='_nl=true'; trap -- '$_nl && [[ $BASH_COMMAND != $PROMPT_COMMAND ]] && echo; _nl=false' DEBUG
The DEBUG trap is performed before each command so before the first command it checks to see if the flag is true and, if so, outputs a newline. Then it sets the flag to false so each command afterwards on the line doesn't trigger an extra newline.
The contents of $PROMPT_COMMAND are executed before the prompt is output so the flag is set to true - ready for the next cycle.
Because pressing enter on an empty command line still triggers the execution of the contents of $PROMPT_COMMAND the test in the trap also checks for those contents as the current command and doesn't perform the echo if they match.
I believe (but haven't tried) if you put '\n\b' in the prompt string it would do that.
In general, if you want to find out the codes to do anything a terminal can do, read the terminfo man page.
In this case, the cursor up one line code can be determined by:
tput cuu1
If you redirect the tput output to a file, you can see what control characters are used.
Bash also supports the PROMPT_COMMAND variable, allowing you to run arbitrary commands before each prompt is issued.