I'm trying to pipe logs to fzf so that I'll be able to filter them live, as my program spits a lot of logs out.
However, I've noticed the long lines get truncated and I have no way to show the whole lines, except to press ENTER, at which point the line will be displayed in it's entirety but the logs will be deleted from the screen and the program will crash with the error failed printing to stdout: Broken pipe (os error 32)'
It seems fzf supports this feature, as it has a --no-hscroll: Disable horizontal scroll flag, implying horizontal scroll is available by default, but arrow keys don't work, at least not alone or with the usual modifiers.
I've also tried using less -S for this, but doesn't work on live logs as it doesn't resume following after the first interrupt and F command.
As an alternative, I've noticed fzf supports a preview window feature, it would be neat to have the whole line display there so that the logs are still visible and scrolling while following the lines.
I could append logs to a file and try working from there, but is that necessary? Or can these tools also work properly on live stdout logs?
Related
I am using IntelliJ Idea for developing scala and Java programs. I am also a screen reader user.
One of the most useful features that IDEs provide is code linting and displaying error and warnings in your code, along with descriptions. I understand if you are a sighted user, you can just hover your mouse over an erroneous line of code and you get a tooltip with the description.
I haven't been able to figure out how to access this description as a screen reader users. So far, to review errors/warnings I would just build the program and look at the command line output, however this is pretty inefficient compared to just hovering over line of code.
Could someone share a better way of reviewing errors/warnings in IntelliJ using a screen reader? Ideally how to access the error tooltip, or how to access a better UI for reviewing them instead of looking at raw command line output.
I'm not sure about warnings however errors can be accessed in two ways:
Firstly when the caret is moved into a line with error the error text is written into the status bar - the problem with this approach is that for JAB applications screen readers are generally unable to find it, so in case of NVDA object navigation has to be used.
The second way requires your caret to be exactly at the point with error - generally it would be set in the proper place if you've navigated to the line with F2. After that you need to press CTRL+f1 - focus moves to the unnamed pane and the error text is its first descendant so once again you need to employ object navigation. I haven't found any reasonable way to access error texts with JAWS sadly.
Importantly, make sure to turn on screen reader support:
settings (ctrl + alt + S) > appearance and behaviour > Appearance > Support screen readers (requires restart)
Then when your caret is on an error/warning, you can press ctrl + F1 and a dialogue will pop up with the description. Press escape to close it.
If you want to make sure the caret is on an error/warning, use F2 to jump to next error/warning.
As noted by lukaszgo1 in his answer, the description is also printed to status bar, but NVDA cant find it using its normal command, because JAB GUI applications are lacklustre in their implementation of accessibility, however if you want to access the status bar of IntelliJ to read the description you can use an NVDA addon which I developed, that adds a command for reading IntelliJ status bar and fixes list items not being labelled properly.
I actually forgot I asked this until I got an answer recently.
Thanks to lukaszgo1 for his answer.
I'm having issues when connecting to our google cloud containers.
The terminal gets restricted to a certain size and it is behaving odd, when using vim for example the application hangs for 10-20 sec if you press Page-Down, but that's something i'm able to work around, the real issue is the following.
When typing a command and the width goes over the width-length of the prefixed size of the terminal, you suddenly don't know where your cursor is.
The same is for editing a file in vim and you start to scroll down or write a shellscript for example and the last line of the document gets updated, only the last line of the file gets updated and the scrolling behavior is suddenly very broken.
This is what the pre-set size of the terminal looks like when editing
a file.
Setting the TERM enviroment variable to "xterm", "xterm-color" makes the colors and the "clear" function work but does not solve these issues.
If anyone else has experienced these issues and know how to fix them, sharing that knowledge would make life worth living again!
Updating your glcoud components to the latest version solved this problem, now i'm able to run fullscreen vim and life is wonderful!
gcloud components update
I'm configuring GNU screen in a cygwin environment. Re-configuring actually--it always just worked before, and when I upgraded to cygwin-64 the same config files give me unexpected behavior.
What happens is that whenever I do something in the terminal that overflows a full screen the terminal does not scroll. Instead, each new line "overwrites" the last one on the bottom row of the window. Even when the process is through, if I CTRL+l, there's a bunch of garbage left on the last three lines of the terminal. Also, when I use a program that takes up the entire screen, such as vim or irssi, the "caption" line disappears.
I suspect that there's some discrepancy between my xterm settings and screen's 'term' setting, but I'm a little at sea here and, as I said, all the same configuration files worked fine (and do work fine on other machines--both cygwin and native linux). Can anyone recommend a way to get my beloved screen to behave again?
Here's my .screenrc:
shell /bin/bash
screen -t bash 0
select 0
escape ^Zz # Instead of Control-a, make the escape/command character be Control-z
autodetach on # Autodetach session on hangup instead of terminating screen completely
startup_message off # Turn off the splash screen
defscrollback 30000 # Use a 30000-line scrollback buffer
nethack on
# Misc h4x to make scrollback work
terminfo * te#:ti#
termcapinfo xterm|xterms|xs|rxvt ti=\E7\E[?47l
# Bells are annoying
bell_msg ''
vbell off
caption always '%{= kG}[ %{G}%H %{g}][%= %{= kw}%?%-Lw%?%{r}(%{W}%n*%f%t%?(%u)%?%{r})%{w}%?%+Lw%?%?%= %{g}][%{B} %d/%m %{W}%c %{g}]'
You're running screen under xterm (something I do all the time myself). The screen process "knows" how big the terminal is, but that information can be out of sync with reality. I find this happens a lot when I run screen -dr from a different window.
Resizing the xterm windows causes it to send a SIGWINCH signal to the process running under it, which typically causes that process to re-query the tty settings.
Click the maximize button twice. If you're already maximized, that will restore it to a normal window and then re-maximize it; if it's not already maximized, it will do the opposite. In either case, it should cause screen to recompute the window size.
I encountered the same problem today. Thank everyone for the heads-up. The final solution I found out is that to set the mintty term type to: vt220. There must be something not right about the "xterm". After that, everything is good.
I'm answering my own question here because, while #Keith Thompson's answer does resolve the symptom of the problem, it didn't keep the symptom from occurring. He did set me on the right path, which was to install the xterm package in cygwin-64. That appears to have resolved the issue.
I downgraded screen version to Screen version 4.02.01 (GNU) 28-Apr-14 and it worked.
I am considering writing a graphical tool that will show you what gnu-screen sessions you have and what windows are available in them. You would then be able to, for example, click on the window title and it would take you there. I do not want to modify gnu-screen in any way so that my tool can work with existing installations on other machines and so on.
I can get ordinary output from programs running inside screen out of the screen session by using a log-file, or by copying the last few lines into the exchange-buffer. What I really need in order to make a nice user interface though is the contents of the status line (the line that temporarily appears at the bottom of the window). For example, to get the list of windows in a session I can send the windowlist command, but the result is never part of the output. Does anyone know if there is a way to make screen put its messages into the log, into a paste-buffer, into the current window, or anything similar where I can grab it from another program?
My problem is that i wish to capture the text that is displayed in the
console of Xcode when an application is executed and display it in a
text box in my App.
If i override NSLog i can just capture the explicit NSLog commands
that are issued in the course of the program. However many statements
that are just inserted by the compiler are not captured.
Is there a way to read the Xcode Console buffer while the app is
running and display it in the app too ??
What you see in the log window of Xcode is a composite of the messages that would normally go to standard out and standard error file streams and to the system log. If you want to capture those streams, you need to close them and reopen them as pipes or files.
If you do this, the documentation says that if you redirect standard error from the default, NSLog will log to that as well as the console. Thus you don't need to override it.
Redirecting standard error and standard out is a fairly common thing to do in Unix. The basic technique to redirect to a file is to close the file descriptor using close(2) and then reopen it using open(2) or pipe(2).
The Xcode Console is just a window that reads errors and such from the Console logs. Try reading from there.