#2522 Issue closed: Very long path names corrupt display ESP if VNC is used¶
Labels: support / question, fixed / solved / done
Hardcore-fs opened issue at 2020-11-21 21:47:¶
recovery is worknig fine..
however on very logng path names it is corrupting the display
ESP. if a VNC is used.
the screen eventually just goes blank, making it very difficult to see
what is going on.
perhaps a way to trim the middle out of the pat so only the end gets displayed...
jsmeix commented at 2020-11-23 08:23:¶
ReaR's output is normal stdout/stderr output as other programs also do.
So when very long lines or very long words (like long path names)
corrupt "display ESP if VNC is used" the problem is in the
"display ESP if VNC is used" area but not in ReaR.
It is not possible with reasonable effort in ReaR to trim the middle out
of long paths
because we would have to check all places where ReaR outputs something
(hundreds of places in the code) if there might be a path in the
output
or we would have to implement some kind of "generic artificial
intelligence
output filter" in ReaR that checks all output for long paths and trims
them.
But even if we had such functionality available I would be against it
because I do want to show complete information to the user
and not some nicer looking but incomplete/cropped stuff.
Because ReaR output is traditional Unix style stdout/stderr output
the right way is to use the traditional Unix way of getting things
done
by an appropriate pipe of commands that do what you specifically need.
For example something like
# usr/sbin/rear -D mkrescue | tee rearfullstdout | cut -b -78
which works reasonably well for me.
I also tried
# usr/sbin/rear -D mkrescue | tee rearfullstdout | fold -w 78
but at least my fold program (on openSUSE Leap 15.1) does not
continuously output what it gets from its stdin but seems to have
a rather big internal buffer until all is output at the end.
But for user input dialogs the dialog messages must be output at once
so fold cannot be used (at least not my fold program).
Also redirecting stderr with e.g.
# usr/sbin/rear -D mkrescue 2>&1 | tee rearfullstdout | cut -b -78
had bad effects because for user input like
read -p "Enter your input " 0<&6 1>&7 2>&8
the read prompt is not shown because read outputs the "Enter your
input "
string without a trailing newline so this string is not output by
cut -b -78, e.g.
# read -p "Your input " 2>&1 | cut -b -78
shows nothing unless one has input something and hit [enter]
then - after the input was done - the read prompt gets shown.
Off the top of my head I don't know a "trim-long-paths" program
but if is exists something like
# rear -D recover | tee rearfullstdout | trim-long-paths
could be exactly what you need.
Hardcore-fs commented at 2020-11-23 22:41:¶
Please don't talk nonsense........ needs "ai"?
if it looks like it is more than 1 screen line for a file path being copied.... just remove the middle of the path string until it fits... and make it an option....
[Export of Github issue for rear/rear.]