When I use less -F in an xterm nothing I can't see anything because after the file is displayed the screen is restored. If the terminal has the restore capability less should silently disable the F flag.
----- Forwarded message from Marco d'Itri <md@linux.it> ----- Subject: Bug#51462: less: -F and X Reply-To: "Marco d'Itri" <md@linux.it>, 51462@bugs.debian.org From: "Marco d'Itri" <md@linux.it> To: submit@bugs.debian.org X-Mailer: bug 3.2.7 Date: Sun, 28 Nov 1999 20:38:17 +0100 (CET) Package: less Version: 346-2 Severity: normal When I use less -F in an xterm nothing I can't see anything because after the file is displayed the screen is restored. If the terminal has the restore capability less should silently disable the F flag.----- End forwarded message -----
Hm, that seems rather extreme. If the user explicitly requested -F
behavior, I don't think it's correct to just ignore him. I think it
would be better to silently disable the screen-restore. However, the
problem is, as far as I know, there's no way to tell from the termcap
description whether the terminal init/deinit sequence ("ti"/"te")
restores the screen or not. So I can't really do either approach: I
can't disable -F if the terminal has restore capability, because I can't
tell if the terminal has restore capability. And I can't disable the
restore, because I can't tell whether ti/te does a restore (or perhaps
does something else that's required to make the terminal function). I
guess what it comes down to is you shouldn't use -F if your terminal
does a restore; or you should use -F in conjunction with -X if you know
it's safe to do so. (Same thing applies to -E.)
--Mark
Marco, what do you think about Mark's explanations? May I close this bug report? Thomas
On Nov 29, Mark Nudelman <marknu@flash.net> wrote:
>> after the file is displayed the screen is restored.
>> If the terminal has the restore capability less should silently disable
>> the F flag.
>Hm, that seems rather extreme. If the user explicitly requested -F
>behavior, I don't think it's correct to just ignore him. I think it
I put -F in my ~/.less file, and I think most users do that. This is not
a flag you want to use only sometimes.
>would be better to silently disable the screen-restore. However, the
>problem is, as far as I know, there's no way to tell from the termcap
>description whether the terminal init/deinit sequence ("ti"/"te")
>restores the screen or not. So I can't really do either approach: I
You could at least add an hack which checks if $TERM is xterm* or
rxvt*. I think this would fix the problem nearly every time.
>guess what it comes down to is you shouldn't use -F if your terminal
>does a restore; or you should use -F in conjunction with -X if you know
I use different terminals and I can't have different config files.
On Nov 30, Thomas Schoepf <schoepf@debian.org> wrote: >May I close this bug report? I think you can classify it as a whislist bug.
With this patch -F is silently disabled when running in a xterm. It's an hack but it let me put -F in ~/.less.--- less-346.dist/main.c Fri Nov 5 02:47:36 1999 +++ less-346/main.c Wed Dec 29 23:09:31 1999 @@ -195,6 +195,19 @@ quit(QUIT_OK); } +#ifdef linux + /* -F will not work in X because the old screen will be restored + before the user has the time to read the displayed text */ + { + extern int quit_if_one_screen; + char *term; + if ((term = getenv("TERM"))) { + if (strncmp(term, "xterm", 5) == 0) + quit_if_one_screen = FALSE; + } + } +#endif + if (missing_cap && !know_dumb) error("WARNING: terminal is not fully functional", NULL_PARG); init_mark();
Thanks for your patch. But I won't integrate this into Debian's less distribution, because it's really a hack ;-) Of course, I'll leave this bug open, the patch will be available to anyone who wants it. Thomas PS: I usually use kvt (KDE's terminal) and there -F works fine even with TERM=xterm-debian
Since the bug report hasn't been closed yet, I'll assume that this hasn't been resolved. I don't know if there is a way to work it out, but my suggestion would be to extend -F. Not sure what option that would be, though. My current LESS variable is set to -FMie#4j5~ and I suggest something like -FXMie#4j5~, which would mean that if the entire file can be displayed on the first screen, less wouldn't send the termcap initialisation and would automatically exit.