IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
UNIX terminals, e.g. vt100, send escape sequences for many special
key combinations. Entering the history search mode assigned a specific
meaning to the ESC character and disabled the processing of escape
sequences, thus accidentally printing some characters that are part
of a CSI.
As a workaround, avoid changing the meaning of ESC; users can still
use the well-known `ESC ESC` sequence (or any other editor command,
e.g. move left/right) to exit the history search mode.
This change only affects UNIX terminals.
Closes issue #10209.
These commands, bound respectively to `ESC l` and `ESC u`, should {lower,upper}case
the next word; however, only the first character was changed.
Fixes#10136.
This editor command (usually binded to Ctrl+T), transposes the character located
at the cursor and the one to its left.
However, its behavior was incorrect if the cursor was at end of the line,
invoking `std::string::operator[]()` passing an index that is out of bounds.
In that case, as per GNU Readline behavior, it should swap the two last
characters.
Closes#10133.
This change is equivalent to the popular GNU Readline keybinding
```
"\e[3;5~": kill-word
```
As a requirement, the `[3;5~` CSI was added in StreamReaderUnix.cpp. No
additional changes required to StreamReaderWin.cpp.
Writes the `\033[2J\033[H` sequence to clear the visible part of the screen.
For Windows, this requires to temporarily enable processing of VT control
sequences.
Enable fast word movement à la Xterm (using Ctrl+Left and Ctrl+Right). Most
users coming from a GUI (GTK+, Win32, etc.) will find this convenient, but also
Archlinux users, given that the default `inputrc` file for GNU Readline providesthese bindings (see https://wiki.archlinux.org/title/Readline#Fast_word_movement).
Pressing ctrl-r when no ~/.root_hist file is present or possibly
when it contains 0 lines used to cause a segfault. The culprit
if an out-of-bound access in History::GetLine, as the case in which
the history has zero entries was not taken into account.
With this patch, Histoy::GetLine returns an empty string instead.
This fixes ROOT-10917.
Co-authored-by: Axel Naumann <Axel.Naumann@cern.ch>
Fix output redirection (`.> blah.txt`) which is curently freezing the console input on Windows
When a file (or console) has been created without the `FILE_SHARE_READ | FILE_SHARE_WRITE` flags, there is no way to change this, but by closing it and re-opening it (or a new one) . And I suspect that a standard console doesn't have those flags, so when redirecting the output to a file with `.> blah.txt`, all the output is going to the file, without any echo on the console, and when typing `.>` to suppress the redirection, the file contains this kind of errors:
```
Error 6 in textinput::TerminalDisplayWin attaching to console output: The handle is invalid.
Error 6 in textinput::TerminalDisplayWin attaching / getting console info: The handle is invalid.
Error 6 in textinput::TerminalDisplayWin writing to output: The handle is invalid.
```
This patch solves those issues, even if I'm not sure if it is the root of the problem (it might be something else deep in the `MetaSema::actOnRedirectCommand` function).
NB I don't know if this can have any side effect, but I didn't see any so far...
And for info, one could Enable Console Virtual Terminal Sequences (ANSI escape code) that can control cursor movement, color/font mode, and other operations when written to the output stream by adding the ENABLE_VIRTUAL_TERMINAL_PROCESSING flag, but then it breaks the WRAP_AT_EOL_OUTPUT. With this feature, the escape sequences like `\033[39m` would work in the Windows 10 command prompt as well.
This is a known issue, see https://github.com/microsoft/terminal/issues/349
This situation can happen if stdout is redirected and back. stdout's FILE* has
now changed, and the prompt and stdout end up on different buffers, meaning that
stdout is not flushed before the next prompt.
Decouple redirection state from MetaProcessor and MaybeRedirectOutputRAII.
Only suspend redirection when writing to the prompt.
Allow user to redirect to files named 1, 2, &1, &2.
Allow stderr and stdout to be redirected to one another.
Don't create _IO_2_1_stdout_ file.
