traviscross
Don't clean screen after quit
I see that when I exit the program it will clear the screen, losing all the information displayed.
It would be nice if it kept the trace information (or that it would print it again if required), so it can be read or copied later.
I agree that this would be useful. But as far as I know this is due to the way the "curses library" works.
When you say you want to use the terminal in direct-access mode, it will switch to a different terminal-screenbuffer and switch back when the program exits.
As a workaround if we'd really want this, we could print the whole report page again after closing curses mode. But that would change behaviour for existing users, OR you'd have to specify the option on the commandline before you start, and you'd always have forgotten it when you need it...
Maybe you could add an option to the menu that's available while MTR is running. Something like "Keep&Quit". Excuse me if this suggestion is too off the line, I have no knowledge of programing.
My workaround is to pipe MTR through a script which manipulates the ANSI codes sent to the terminal. It is a dirty workaround though.
If you are curious https://gist.github.com/LatinSuD/3ec900f487e1f098e570a41b5253d3d3
mtr doesn't clear the screen upon exit when running within a screen session. This is how I run it most of the time, so this behavior doesn't bother me.
Perhaps this observation provides a clue as to how to get it to not clear the screen normally.
OR you'd have to specify the option on the commandline before you start, and you'd always have forgotten it when you need it...
This would be better than having no option at all.
the simplest workaround is to use a terminfo defintion which is compatible with your terminal, but lacks the smcup and rmcup properties. you can check with:
$ infocmp -I xterm | grep rmcup
rmcup=\E[?1049l\E[23;0;0t, rmir=\E[4l, ritm=\E[23m,
$ infocmp -I vt220 | grep rmcup
$ infocmp -I rxvt | grep rmcup
rmcup=\E[2J\E[?47l\E8, rmir=\E[4l, rmso=\E[27m,
vt220 is a subset of what XTerm and other popular terminals support, and is readily available in the terminfo database in most distros, so try:
$ TERM=vt220 mtr example.com
that's not to say I wouldn't like a less hackish solution. one possibility is a new output-mode. my favourite would be an output which looks like --report, but without the delay: just print each run as it happens.
$ mtr --continuous-report -c 2 vg.no
Start: Wed Mar 4 17:05:21 2020
HOST: jordin.ifi.uio.no Loss% Snt Last Avg Best Wrst StDev
1.|-- ifi-gw1.uio.no 0.0% 1 0.7 0.7 0.7 0.7 0.0
2.|-- ojd-gw1.uio.no 0.0% 1 0.5 0.5 0.5 0.5 0.0
3.|-- knh-gw1.uio.no 0.0% 1 0.6 0.6 0.6 0.6 0.0
4.|-- uio-gw8.uio.no 0.0% 1 0.4 0.4 0.4 0.4 0.0
5.|-- oslo-gw1.uninett.no 0.0% 1 0.4 0.4 0.4 0.4 0.0
6.|-- te3-1-2.br1.fn3.as2116.ne 0.0% 1 0.5 0.5 0.5 0.5 0.0
7.|-- ae8.cr2.oslosda310.as2116 0.0% 1 1.3 1.3 1.3 1.3 0.0
8.|-- he5-2-0.ar2.ulv89.as2116. 0.0% 1 0.7 0.7 0.7 0.7 0.0
9.|-- www.vg.no 0.0% 1 0.9 0.9 0.9 0.9 0.0
1.|-- ifi-gw1.uio.no 0.0% 2 0.4 0.4 0.4 0.4 0.0
2.|-- ojd-gw1.uio.no 0.0% 2 0.4 0.5 0.4 0.6 0.0
3.|-- knh-gw1.uio.no 0.0% 2 0.5 0.6 0.5 0.6 0.0
4.|-- uio-gw8.uio.no 0.0% 2 0.3 0.3 0.3 0.3 0.0
5.|-- oslo-gw1.uninett.no 0.0% 2 0.3 0.3 0.3 0.4 0.0
6.|-- te3-1-2.br1.fn3.as2116.ne 0.0% 2 0.5 0.5 0.4 0.5 0.0
7.|-- ae8.cr1.san110.as2116.net 0.0% 2 1.3 1.3 1.3 1.3 0.0
8.|-- he3-0-2.ar2.ulv89.as2116. 0.0% 2 0.7 0.9 0.7 1.0 0.0
9.|-- www.vg.no 0.0% 2 0.6 0.6 0.6 0.6 0.0
$
(-R | --continuous-report is my suggested name for the option)
Nice!
things are often not as easy as initially thought... When as in your example the RTTs (< 2ms) are all less than the interval between the packets (111ms)... AND no packets are lost, then by the time you got the reply from www.vg.no, you can simply print the whole "run".
But what if host 4 hasn't replied yet? Maybe it is taking more than 1 second for the reply to get back to us.... So when a complete "round" has happened, I can print the current status, but you can't be sure that every host on that run has had the chance to reply yet. (you typically run mtr when "things are slow" and you might get something like 4 hops that are fast, and then a hop that is completely overloaded and is dropping 10% of the packets and 2.5 seconds of buffered packets in the output buffer. And some routers prioritize real traffic over our probes and delay teh responses on the probes by more than the next hop.
Anyway, doable, but... not today....
I get rmcup=\E[?1049l\E[23;0;0t, rmir=\E[4l, ritm=\E[23m, on linuxfx. So I could add this to my .bashrc file yes?
I did this but it made my terminal not colour anymore. (5.6.15-windowsfx-10-generic)
things are often not as easy as initially thought... When as in your example the RTTs (< 2ms) are all less than the interval between the packets (111ms)... AND no packets are lost, then by the time you got the reply from www.vg.no, you can simply print the whole "run".
But what if host 4 hasn't replied yet? Maybe it is taking more than 1 second for the reply to get back to us.... So when a complete "round" has happened, I can print the current status, but you can't be sure that every host on that run has had the chance to reply yet. (you typically run mtr when "things are slow" and you might get something like 4 hops that are fast, and then a hop that is completely overloaded and is dropping 10% of the packets and 2.5 seconds of buffered packets in the output buffer. And some routers prioritize real traffic over our probes and delay teh responses on the probes by more than the next hop.
There are two options. Option 1 is the one I tried to hint at: repeat the report multiple times, with the data received so far (notice there are two traces in my sample output). Probably best to restrict it to one report dump per second. Option 2 is to make a single report, and delay output for a line until it has given up on getting more replies (ie. --gracetime has passed). This is quite similar to today's --report mode, although with --report you get no output at all before that time has passed.
I did this but it made my terminal not colour anymore. (5.6.15-windowsfx-10-generic)
Right, my hack was intended to be used with the mtr command only. You could do this with
alias mtr="env TERM=vt220 mtr"
in your .bashrc.
This cool retro vt220 hack seems like a distraction from writing a pull request to fix mtr itself... has anyone tried that yet?
