With `tmux` there is a visual mode that allows to `tail -F` with search, selection etc.
Stop using tail -f (mostly)
141–150 of 211 posts
Re: Stop using tail -f (mostly)
#142less is my favorite text editor. It's a pity it doesn't actually edit text.
You should try vim dude.
Re: Stop using tail -f (mostly)
#143Earlier quoted context omitted.
+1 (upvoted). $ less ./somefile /somesearch^M ( (Edit: formatting)
But how do you combine the two on the command line, so less is tailing the file AND highlighting a pattern when launched? I typically read logfiles with less +F, but it would be nice to create an alias for patterns in specific types of logs, so I don't have to remember them or rely on command history.
$ less +F +/mypattern^M /my/file/to/search_and_follow
* Note that I needed to "quote" (^V^M) that carriage-return to get the search pattern to work.
Happy searching-and-following.
Re: Stop using tail -f (mostly)
#144I would be careful about such casual use of less: http://seclists.org/fulldisclosure/2014/Nov/74
Re: Stop using tail -f (mostly)
#145Earlier quoted context omitted.
But how do you combine the two on the command line, so less is tailing the file AND highlighting a pattern when launched? I typically read logfiles with less +F, but it would be nice to create an alias for patterns in specific types of logs, so I don't have to remember them or rely on command history.
$ less +F +/mypattern^M /my/file/to/search_and_follow * Note that I needed to "quote" (^V^M) that carriage-return to get the search pattern to work. Happy searching-and-following.
Thanks! Any idea what the quoted carriage return does? I wouldn't have thought of that in a million years.
Re: Stop using tail -f (mostly)
#146Perhaps neovim with terminal mode and tail -F might be the best of all worlds.
Re: Stop using tail -f (mostly)
#147Earlier quoted context omitted.
Sure it does. If your log lines are distinct (e.g. they have timestamps or unique IDs) then you can use less's search highlighting to provide a visual marker for a specific line, similar to what you can do by manually inserting a bunch of blank lines on the console. This trick doesn't work if your log file has a bunch of identical lines and you want to keep an eye on their rate, though.
imagine the scenario: "I want to see everything that happens in a single request" Enter method: 1. Press enter a bunch of times 2. Reload browser 3. Press enter a bunch of times and scroll up Your method: 1. Search for last line in output to highlight it? 2. Reload page 3. Try and figure out where stuff starts and ends with loads of visual noise
I won't argue that for this specific use case, tail isn't friendlier than less.
But the original poster posted a useful tip, and is now getting aggressive downvotes and comments like "This has nothing to do with what is being discussed in this subthread." I think that's unwarranted.
Re: Stop using tail -f (mostly)
#148This _almost_ touches on the useful part of this: If you search in less and then put it in follow mode, it continues to highlight the search terms. This is very useful for trapping an exception or webcall in the wild. The downside: less buffers and tail -f prints directly. On a slow printing log this can cause events to show up slowly, and can cause performance issues on a fast moving log. If you're piping through a…
The other useful thing is filtering - on sufficiently modern versions of less [1], you can use & to filter the lines, in the same way you use / to search them - only lines matching the filter are shown, and the display continues to update. Use &! for a negative filter. This has replaced grep | tail for me, with the advantage that it's non-destructive, so you can undo the filter, reapply a different one, etc. [1] Ever…
& is very handy, however it is also excruciatingly slow. It looks like it uses an O(n^2) algorithm, just from observing how slow it works.
Re: Stop using tail -f (mostly)
#149Earlier quoted context omitted.
multitail is great. I really cannot use command line utils that don't support colors/highlighting anymore. htop instead of top, etc. It just gives me much better visibility and readability. I'm surprised that so many non-color utils are still being used. It just feels so 1994 to me to stare at a white on black display. I guess there's nothing more slow moving and conservative than shell interfaces, thus articles like…
I wrote a Python script (called synesthesia)[1] that'll colorize input based on regex matches, and any matched text will be the same color for the same content. The use case that drove its development was needing to keep track of UUIDs across multiple logs - and grep --color will colorize its matches, but not differentiate between ones that have different content. With this, I could watch both logs as data was passed…
that's way better than my alternative which was a bash function:
function hl() {
local R=''
while [ $# -gt 0 ]; do
R="$R|$1"
shift
done
env GREP_COLORS="mt=38;5;$((RANDOM%256))" egrep --color=always $R
}
Re: Stop using tail -f (mostly)
#150Be very, very careful with this: http://seclists.org/fulldisclosure/2014/Nov/74 But really, it's 2015. Are you really using a terminal emulator without a buffer search? Are you not using screen or tmux, both of which can do these things natively, with no external tools? Why? And what is wrong with backgrounding the tail command, running your grep, and then foregrounding the tail command?
Personally? The reason I'm not using screen is that there's no way to atomically [attach, create new window] in screen and I value my gnome-terminal tabs. If tmux can do that, then I'd consider it reason to switch.
Depending on what you mean by "atomic" (do you really mean atomic, or do you just not want to have to type anything after you've attached to create the new window?), you can do this with screen's -X option. If that's what you want to do I can try to dig up the way I used to do this.