Linux terminal emulator that can display line number and scroll up/down - Page 1
Forum section: electronics / general

author: retiredcaps
author_rank: Super Contributor
timestamp: February 10, 2021, 09:21:53 pm
content: I'm looking for a linux terminal emulator that has the following features- ability to display line number on the left hand side- page up/down using the page up/down keys in addition to a scroll bar for the mouse- support color fonts- support different size fonts- change cursor shape (block cursor, underline, etc)- support ubuntu fonts (or ability to change fonts)- ability to search for words in terminal and what's scrolled off the screen- cut and paste using mouse and keyboardSo far qterminal which comes with Lubuntu is the closest, but misses out on the line number and page up/down key function.I have tried tilda, stterm, terminator, gnome-terminal but find them lacking and no better than qterminal for my needs.I use this terminal primarily for debugging log messages via adb logcat | logcat-colorize. I do not need multiple terminals to fit in one screen.Suggestions are welcome.

author: Nominal Animal
author_rank: Super Contributor
timestamp: February 11, 2021, 05:05:46 pm
content: I took a gander at thesource of logcat-colorize, and it only uses ANSISGRescape codes to colorize/emphasize the output, so what you really need, is to runadb logcat | logcat-colorize | less -b 1024 -BNQRSLine numbers are at the beginning of each line. If you want them colorized, or formatted differently, I can help with that: we can use sed or awk to insert the line numbers in a more preferred format, and pipe that output to| less -b 1024 -BQRSinstead.To follow the output, you need to press F.To stop following the output, you need to press Ctrl+C.You can scroll with the mouse wheel, cursor keys, or PageUp/PageDown keys; Home and End move to the beginning or end of the (saved one-megabyte) buffer.When at the beginning of the buffer, press / to search for a string.If you don't want to limit the buffer to one megabyte, and want to keep all of the log in RAM, drop the -b 1024 -B, and use| less -NQRSinstead.I know it's not optimal, but it is pretty good. Better yet,lessworks with any text input, so being familiar with how it works (seeman 1 less) lets you use it for many other situations also; it is in the top ten most used commands for me.

author: PKTKS
author_rank: Super Contributor
timestamp: February 11, 2021, 05:32:10 pm
content: I deal mostly with terminals..For a long period ... and never ever saw line numbers ..I think mostly the reason is that the line buffer whichnot only can be dynamically defined per terminal butalso vary quite a lot among terminals.The best thing (better written and focused) is stillthe XTerm.. because it can handle whatever featureyou can think of.. besides line numbers..Fancy stuff like alpha blending and "modern" frumostly are RXVT delegated..Paul

author: retiredcaps
author_rank: Super Contributor
timestamp: February 11, 2021, 05:43:41 pm
content: Quote from: Nominal Animal on February 11, 2021, 05:05:46 pm@Nominal Animal, thank you for the excellent suggestion and taking the time to actually look at the source code for logcat-colorize. I truly appreciate your time in helping.I came to the realization yesterday after more research that it would likely have to be a combination of tools and pipes to get it working.Now that you have given me a starting point, I can fine tune and tweak to what I desire.

author: retiredcaps
author_rank: Super Contributor
timestamp: February 11, 2021, 05:48:33 pm
content: Quote from: PKTKS on February 11, 2021, 05:32:10 pmHi Paul, I appreciate you taking the time to share your experience in this area. I just thought with so much history and various choices that at least one terminal emulator would offer line numbers, but as long as I have a workaround using a combination of linux tools, I can make it work.

author: PKTKS
author_rank: Super Contributor
timestamp: February 11, 2021, 06:04:54 pm
content: Quote from: retiredcaps on February 11, 2021, 05:48:33 pmWelcome.. my pleasure if 2 cents bits will helpAll xterm variants own a user defined term emulationwith a also user defined scroll back buffer.. which can be really big.Compilation time determines most of safety issues and features.Attached my solution using a line capable editor inside RXVT and XTermclassic foo bar goo duu non sense writtenAll features are dynamically configured - on/off - term type.EXCEPT the scroll back buffer... defined upon calling convention..Paul

author: PKTKS
author_rank: Super Contributor
timestamp: February 11, 2021, 06:14:10 pm
content: Interesting to use as well all the features of colorizationand graphical features of ncurses...Windowed NCURSES is very nice the editor provides me numbering..Paul

author: guenthert
author_rank: Frequent Contributor
timestamp: February 11, 2021, 07:23:56 pm
content: Sorry, I don't quite understand. What information would line numbers in a terminal (emulator) convey? Would those numbers change after scrolling? What's the first line number? Can it be reset?Several editors and paginators are capable of (optionally) displaying line number (of the document displayed). A feature I rarely use (I'm glad we left line numbers of BASIC and FORTRAN long behind us).

author: retiredcaps
author_rank: Super Contributor
timestamp: February 11, 2021, 08:00:36 pm
content: Quote from: guenthert on February 11, 2021, 07:23:56 pmThe line numbers would act as a reference of where something started in my debug log section. For example, if I spot an error at line 1500 and then another at 1800, then I can page up/down (using the keyboard keys page up and page down) between those 300 lines. If I go to line 2500, then I know I need to get back to 1500.QuoteNo.QuoteFirst line number would be #1 as soon as adb logcat starts. I don't need it to be reset.QuoteIf I capture the output of adb logcat and paste it into an editor, I lose all the color information. I need the color information to help me find the errors (typically red).I attached log of the problem I'm trying to solve (audio won't play over bluetooth). It helps me to know this error is line 5076. Now I could cut & paste what I think is unique about line 5076 to help me find my way back here, but as you can see it repeated in 5078. And since a lot of these log messages are new to me, I don't know what is unique and what is common.I think what I'm asking is just unique to the way I troubleshoot inside a terminal.

author: retiredcaps
author_rank: Super Contributor
timestamp: February 11, 2021, 08:06:35 pm
content: In addition, when I'm scrolling with the mouse in a 5000+ line log , I have no idea, without line numbers, where I am. Also, the page up/down keys give me finer control in +/-24 lines because I cannot move the mouse with that precision.

author: PKTKS
author_rank: Super Contributor
timestamp: February 11, 2021, 08:19:59 pm
content: Quote from: retiredcaps on February 11, 2021, 08:06:35 pmRedirect or pipe your session to a file...Use TEE or TAIL ... whatever you may feel comfy...or just plain file like: ( appdbg > file.log 2>&1 ) &Then just about any editor will do this trick;;editor +lineno file.logeditor -line lineno file.log...all should do that... VI NEDIT MC whatever..Paul

author: guenthert
author_rank: Frequent Contributor
timestamp: February 11, 2021, 08:26:43 pm
content: Indeed. The line number you're seemingly interested in is the line number of a document, here a log. The line number of a terminal session is arbitrary and irrelevant. Capture the log in a file and use a paginator. e.g. `less -N logfile`.I never cared about the colour much, so I can't help you there (but you could try the "-r" or "-R" options to less). I let the tool (paginator, editor or grep etc.) search (case insensitively) for any of "can't", "cannot", "couldn't", "could not", "err", "fail", "fatal", "warn" when looking for problems in a log file. Some of which are much too large to inspect manually.

author: guenthert
author_rank: Frequent Contributor
timestamp: February 11, 2021, 08:49:03 pm
content: I think the whole line number business is a red herring. When communicating with other developers or support staff, they are more likely interested in the time stamp (better be accurate and with a known time zone) then the line number. The time stamp can often be associated with others (potentially in other log file, perhaps even on other machines given a distributed system) to establish an order of events and hopefully reveal a causal chain.For multi threaded applications it's not uncommon that events occurring close in time are logged in arbitrary order (the time stamp better matches though).

author: guenthert
author_rank: Frequent Contributor
timestamp: February 11, 2021, 09:15:35 pm
content: Don't you hate it if you ask a question and then people provide answers tootherquestions?If you really want color and line numbers in a terminal emulator, Emacs comes to the rescue (of course). I just tried it for the first time, but the ansi-term major mode is capable of displaying colors and can be combined with the linum minor mode. So there it is.

author: Nominal Animal
author_rank: Super Contributor
timestamp: February 11, 2021, 09:17:06 pm
content: Apparently, adb-logcat uses rather weird date and time format,MM-DD HH:MM:SS.ttt.Personally, I like ISO 8601-like date and time timestamps,YYYY-MM-DD HH:MM:SS.tttwhich also sort correctly textually. (Technically speaking,ISO 8601date time format has a T in between and either Z (for UTC) or the difference to UTC at end, i.e.YYYY-MM-DDTHH:MM:SS+HH:MM.)This works for me for the same purpose retiredcaps is wanting line numbers: to immediatelyseewhere one is within the huge log file, without thinking (or looking at the scroll bar, especially if one hides the scrollbar from their terminal emulator).

author: retiredcaps
author_rank: Super Contributor
timestamp: February 11, 2021, 09:47:20 pm
content: Quote from: Nominal Animal on February 11, 2021, 09:17:06 pmThe format of the date doesn't matter to me. The timestamp may not work for me in my case because there may be 1000s log entires within a 1 or 2 second period.

author: retiredcaps
author_rank: Super Contributor
timestamp: February 11, 2021, 09:48:21 pm
content: Quote from: guenthert on February 11, 2021, 08:49:03 pmI'm only using the line numbers for my own purposes. If I had to share a log, it wouldn't include the line numbers.

author: retiredcaps
author_rank: Super Contributor
timestamp: February 11, 2021, 09:53:35 pm
content: Quote from: PKTKS on February 11, 2021, 06:04:54 pmThanks. I will try them out. I'm always willing to try different tools. Even if they don't end up being used in this case, I learn something new and it may come in handy in the future.

author: Nominal Animal
author_rank: Super Contributor
timestamp: February 11, 2021, 10:38:02 pm
content: Quote from: retiredcaps on February 11, 2021, 09:47:20 pmIn that case, the "standard" LinuxYYYY-MM-DDHH:MM:SS.nnnnnnnnn+HH:MMtimestamps would be better. Native timestamps (struct timespec) in Linux (and Android) have nanosecond precision. I wonder whyadbuses such a silly date-time format?

author: PKTKS
author_rank: Super Contributor
timestamp: February 12, 2021, 10:06:27 am
content: Quote from: retiredcaps on February 11, 2021, 09:53:35 pmI actually use this method in some log records...They are concurrently dumped to a file... some time stamped..Code:( $shell_logger ) 2>&1 | \awk 'BEGIN {FS=":";} NF>1 { print $2; } NF<2 { print $0; }'| \nl -ba -nrn -s":" > file_numbered.log# then at any time I can edit by line the record file as shown above.# in VI we just dovim +linenum file_numbered.lognothing prevents you to also have an open terminal likesaid above using the numbered file in less ( raw mode)both windows will do the trickthe record separator can purge time stamps if needed...and VI can also do this trick inside by opening the two filessimultaneously in vertical panned mode....Paul

author: PKTKS
author_rank: Super Contributor
timestamp: February 12, 2021, 10:19:17 am
content: if still not convinced how it works...just dumped a raw 2 second example... in VInote that our enumeration can be arbitrarily set at will... I never tried to do that on the fly.. (while logging also enumerating..)but it is perfectly possible to pipe a debug shell on this awk enumerator.Paul

author: retiredcaps
author_rank: Super Contributor
timestamp: February 13, 2021, 07:00:14 am
content: Quote from: PKTKS on February 12, 2021, 10:19:17 amI'm convinced you know a lot more than I do about terminals and wouldn't doubt your word on it. It's just a matter of picking and choosing what works for my particular case.Thanks again for all the tips and creative solutions. I appreciate your time in replying.

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 13, 2021, 05:36:31 pm
content: I'm curious what would be the point of seeing line numbers in consoles?

author: Nominal Animal
author_rank: Super Contributor
timestamp: February 13, 2021, 07:15:53 pm
content: Quote from: SiliconWizard on February 13, 2021, 05:36:31 pmretiredcaps needs a tool for easily browsing a continuous Android log. Line numbers are one way to immediately, without spending any mental effort, see where you are within the log stream. I prefer timestamps for this, as I sometimes hide the scrollbar - which anyway may not have enough "resolution" anyway if the log is very long.Having the terminal emulator provide the line numbering was just their first idea, that's all.

author: retiredcaps
author_rank: Super Contributor
timestamp: February 13, 2021, 08:19:40 pm
content: Quote from: Nominal Animal on February 13, 2021, 07:15:53 pm. So true.Again, I might get hundreds of log messages in a 1 second time interval. So remembering 13:11:14.4567 is beyond my abilities. However, I can remember a ballpark range line number like 3500 to 3550. It's also easier for me to jump to line 3500 by typing 3500 into the find command. Line numbers are likely unique in my log where as a message like "error:" might show up 30 to 50 times.In addition, after I make a change to the source code and reboot the device with the new code, I know roughly where to look (i.e. line 3500) vs a time stamp. If I fixed the error, the error message will be gone so I can't rely on searching for the error message either.So the above in combination with color coding helps me find what I'm looking for quickly.

author: Nominal Animal
author_rank: Super Contributor
timestamp: February 13, 2021, 09:22:24 pm
content: Quote from: retiredcaps on February 13, 2021, 08:19:40 pmIt varies from person to person, like remembering faces or names, or whether one prefers 12 hour (AM/PM) or 24 hour clock in numeric format... For whatever reason, I don't need to think about timestamps of this form, or realize what point in time they refer to or remember them; I just automatically recognize it as the one I was looking for. An opaque cookie (magic cookie) sort of thing.Quote from: retiredcaps on February 13, 2021, 08:19:40 pmRight: I didn't think about the boot log aspect at all; line numbers are definitely useful there, even when the message order varies somewhat. There, the timestamp is not that useful (unless relative, saySSS.nnnnnnnnnseconds since startup).One of the funky things about working with Unix/POSIXy systems is that splitting this kind of tool-need into constituent parts (as in adding or separating line numbering to/from the log output) and accomplishing it by piping or otherwise combining multiple tools to get the job done, becomes second nature. It is a powerful skill.Another way you can approach this, assuming that the host you use this on supports multiple terminals, is to redirect the log output to a file before colorizing it. In one or more terminals, you can then "watch" the changes in that file usingless(pressing F does tell it expect the file to grow; it does not assume that just because it is a file, it is not being written to), ortail -F |colorizing etc.| lessoptions. Additional awk/sed magic can then be concurrently used to make the current log and a previous log comparable via e.g.diff -Naburordiff --side-by-side; I prefer theunified format (with + or - at the beginning of each line to mark changes), although it does indicate output order changes as differences also.If this was not just for yourself, but for more developers needing this (or very similar) tool, then the same approach – logging to a file, then using a program that knows the file is being extended concurrently – works for creating a simple but powerful GUI tool, using say GTK+ (if C is preferred) or Qt (if C++ or Python is preferred). A core feature I personally would implement is anN-way timestamp/line number agnostic comparator: each a window would show one log file, but lines would be highlighted (say, only affecting the background, if you use text color for highlighting core terms) depending on whether they match a lines in the other open document windows.(Algorithmically, that sounds like slow going, but really isn't, if we realize each log line is a separate record, and instead of treating them just as a linear record stream, also have them sorted as a binary search tree, or a similar (inherently or regularly balanced) search structure, based on the content ignoring the timestamp/line number. Then, looking for a match per line has an O(NlogN) amortized cost, which is basically instantaneous for each new line if the log file happens to fit in RAM. That mark/match can also be delegated to helper threads, so that the output is always up to date, but the marking may be delayed by a small fraction of a second. Memory-mapping the actual log file, read-only, would conserve RAM use too; useful if comparing multiple huge log files.)Apologies for the walls of text, and hogging the thread. I just really like solving this kind ofI-need-a-tool-to-solve-thisquestions: not solving a single particular problem, but the overall/underlying problem.

author: retiredcaps
author_rank: Super Contributor
timestamp: February 13, 2021, 10:07:37 pm
content: Quote from: Nominal Animal on February 13, 2021, 09:22:24 pmNo worries. I read everything that people post since they went through the effort to try and help. I may not incorporate all the suggestions to what I need, but I learn something new and it gives me another way of thinking about the problem. The latter is useful when troubleshooting.If you have any more ideas/suggestions, please post them. Thanks again.

author: DiTBho
author_rank: Super Contributor
timestamp: February 14, 2021, 01:04:46 pm
content: For a similar problem I hacked Minicom and added lines.Minicom supports VT100 via serial link to remote targets.

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 17, 2021, 03:35:03 pm
content: Quote from: Nominal Animal on February 13, 2021, 07:15:53 pmI wouldn't have thought of doing this myself. I don't know the exact use case of the OP though, but as I think you suggested, I would just have redirected the log's output to a file, and then read the file with any editor that has line numbering.

author: PKTKS
author_rank: Super Contributor
timestamp: February 17, 2021, 03:59:03 pm
content: Quote from: SiliconWizard on February 17, 2021, 03:35:03 pmMy first understanding is that..But lately I realized that may be just a flooding problem..An awk filter is much much handy.. anything on the fly like..Code:(..)($0 ~ /error/ ) { print $0; }($0 ~ /timeout/ ) { print $0; }(..)Anything else is dumped in the void not console..Paul

author: retiredcaps
author_rank: Super Contributor
timestamp: February 18, 2021, 02:13:40 am
content: Quote from: SiliconWizard on February 17, 2021, 03:35:03 pmIf I view in them in an editor, I lose all the color coding from the logcat-colorize that identifies errors, information, warnings, etc. There's no editor that I know that can color code adb logcat output.

author: Nominal Animal
author_rank: Super Contributor
timestamp: February 18, 2021, 03:10:52 am
content: Quote from: retiredcaps on February 18, 2021, 02:13:40 amAll GTK+3 GtkSourceView-based text editors, includinggeditandpluma, have logcat color highlighting. If you open the raw uncolored logcat file in Pluma/gedit, you can choose View > Highlight Mode > Other > logcat.The highlighting is based on GtkSourceView 3.0, and is specified in /usr/share/gtksourceview-3.0/language-specs/logcat.lang:Code:<?xml version="1.0" encoding="UTF-8"?><!--This file is part of GtkSourceViewAuthors: Ryuinferno, Paul Lammertsma, Kelly CraftCopyright (C) 2013 Ryuinferno <ryuinferno.xda@gmail.com>Copyright (C) 2014 Paul Lammertsma <paul@pixplicity.com>Copyright (C) 2017 Kelly Craft <mushroomhead52e@gmail.com>GtkSourceView is free software; you can redistribute it and/ormodify it under the terms of the GNU Lesser General PublicLicense as published by the Free Software Foundation; eitherversion 2.1 of the License, or (at your option) any later version.GtkSourceView is distributed in the hope that it will be useful,but WITHOUT ANY WARRANTY; without even the implied warranty ofMERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNULesser General Public License for more details.You should have received a copy of the GNU Lesser General Public Licensealong with this library; if not, see <http://www.gnu.org/licenses/>.--><language id="logcat" name="logcat" version="2.0" _section="Other"><metadata><property name="mimetypes">text/x-logcat</property><property name="globs">*.logcat</property></metadata><styles><style id="comment" name="Comment" map-to="def:comment"/><style id="verbose" name="Verbose" map-to="def:identifier"/><style id="debug" name="Debug" map-to="def:shebang"/><style id="info" name="Info" map-to="def:string"/><style id="warning" name="Warning" map-to="def:statement"/><style id="error" name="Error" map-to="def:number"/><style id="fatal" name="Fatal" map-to="def:error"/><style id="others" name="Others" map-to="def:comment"/></styles><definitions><context id="comment1" style-ref="comment"><start>^---------</start><end>$</end></context><context id="comment2" style-ref="comment"><start>^#</start><end>$</end></context><context id="datetime" style-ref="comment"><start>^([0-9]{4}-[0-9]{2}|[0-9]{2})-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2}\.[0-9]{3}</start><end> </end></context><context id="thread" style-ref="comment"><start>([ ]+[0-9]+[ ]+|[0-9]{5} )</start><end>([0-9]{5}|[0-9]{4}|[0-9]{3}|[0-9]{2}|[0-9]{1})</end></context><context id="verbose" style-ref="verbose"><start>( V |V\/|V\()</start><end>$</end></context><context id="debug" style-ref="debug"><start>( D |D\/|D\()</start><end>$</end></context><context id="info" style-ref="info"><start>( I |I\/|I\()</start><end>$</end></context><context id="warning" style-ref="warning"><start>( W |W\/|W\()</start><end>$</end></context><context id="error" style-ref="error"><start>( E |E\/|E\()</start><end>$</end></context><context id="fatal" style-ref="fatal"><start>( F |F\/|F\()</start><end>$</end></context><!-- Main context --><context id="logcat" class="no-spell-check"><include><context ref="comment1"/><context ref="comment2"/><context ref="datetime"/><context ref="thread"/><context ref="verbose"/><context ref="debug"/><context ref="info"/><context ref="warning"/><context ref="error"/><context ref="fatal"/></include></context></definitions></language>You can modify (or rather, create your own custom modification, to cater for your particular needs) the lang files, and they'll be available the next time you start gedit/Pluma. The documentation ishere.The downside of using gedit/Pluma is that you need to keep clicking the Reload button when it shows the file has grown, if you open it while it is being generated. Pluma at least does have line numbers (Edit > Preferences, View tab, Line numbers).The color schemes are defined in separate Theme files, basic set installed in /usr/share/gtksourceview-3.0/styles/. Copy the nearest equivalent to your desktop, rename and edit (including the<style-scheme id="id" _name="visiblename" version="1.0">), and copy to~/.config/pluma/styles/, and you can select it the next time you start Pluma, by selecting Edit > Preferences, Font & Colours tab.(So, it's a good idea to realize the lang file specifies thecontextof each fragment, and the theme file the foreground and/or background color for each context.)

author: retiredcaps
author_rank: Super Contributor
timestamp: February 18, 2021, 03:23:36 am
content: Quote from: Nominal Animal on February 18, 2021, 03:10:52 amHmm, is there a foot in the mouth emojii here. I didn't know that gedit could do that. I just tried it and it works. THANK YOU!!!I knew gedit could show some color and syntax highlighting for code, but not logcat. For code, gedit does it automatically. I didn't know it had some many options including logcat.QuoteYes, for certain logs or debugging, I need "real time" logs where I can't copy it into an editor and view it there.I now have plenty of options now to meet probably all my requirements.

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 18, 2021, 05:09:12 pm
content: For "real-time" handling of your logs, (that may have already been suggested) you can always write small utilities to filter/look for specific messages/etc instead of having to visually search for them. I'm sure you can find easy to catch patterns in those logs for the things you want to catch?

author: retiredcaps
author_rank: Super Contributor
timestamp: February 18, 2021, 06:05:29 pm
content: Quote from: SiliconWizard on February 18, 2021, 05:09:12 pmYes, I can grep for patterns.