[PATCH] Option to clear the screen on quit

[Oskari Pirhonen]

Add the option to clear the screen when quitting mutt. This is
controlled by the clear_on_quit config option. Defaults to "no".

Signed-off-by: Oskari Pirhonen 
---
 init.h | 6 ++
 main.c | 4 
 mutt.h | 1 +
 3 files changed, 11 insertions(+)

diff --git a/init.h b/init.h
index 3ccb7382..5f42730b 100644
--- a/init.h
+++ b/init.h
@@ -661,6 +661,12 @@ struct option_t MuttVars[] = {
   ** this variable is \fIunset\fP, no check for new mail is performed
   ** while the mailbox is open.
   */
+  { "clear_on_quit",DT_BOOL, R_NONE, {.l=OPTCLEARONQUIT}, {.l=0} },
+  /*
+  ** .pp
+  ** When this variable is \fIset\fP, Mutt will clear the terminal screen when
+  ** quitting.
+  */
   { "collapse_unread", DT_BOOL, R_NONE, {.l=OPTCOLLAPSEUNREAD}, {.l=1} },
   /*
   ** .pp
diff --git a/main.c b/main.c
index 3fd930b6..d17aa2f4 100644
--- a/main.c
+++ b/main.c
@@ -1408,6 +1408,10 @@ cleanup_and_exit:
   mutt_free_windows ();
   mutt_buffer_pool_free ();
   if (!option (OPTNOCURSES))
+  {
+if (option(OPTCLEARONQUIT))
+  clear();
 mutt_endwin (exit_endwin_msg);
+  }
   exit (exit_code);
 }
diff --git a/mutt.h b/mutt.h
index e4b88788..065ed0d7 100644
--- a/mutt.h
+++ b/mutt.h
@@ -411,6 +411,7 @@ enum
   OPTBROWSERSTICKYCURSOR,
   OPTCHECKMBOXSIZE,
   OPTCHECKNEW,
+  OPTCLEARONQUIT,
   OPTCOLLAPSEUNREAD,
   OPTCOMPOSECONFIRMDETACH,
   OPTCONFIRMAPPEND,
-- 
2.32.0

Re: [PATCH] Option to clear the screen on quit

[Kevin J. McCarthy]

On Sun, Oct 17, 2021 at 12:25:24AM -0500, Oskari Pirhonen wrote:

Add the option to clear the screen when quitting mutt. This is
controlled by the clear_on_quit config option. Defaults to "no".


I think most terminals nowadays have alternative screen support enabled 
by default, don't they?  Unless this is a common option in other 
applications, I don't feel like this belongs inside Mutt.


--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature

Re: [PATCH] Option to clear the screen on quit

[Oskari Pirhonen]

On Sun, Oct 17, 2021 at 09:35:26AM -0700, Kevin J. McCarthy wrote:
> I think most terminals nowadays have alternative screen support enabled 
> by default, don't they?

I'm not sure what you mean by that? All I know is that when I run mutt
in a TTY (my main interface) it doesn't clear the screen, but instead
just scrolls it up enough to fit the bash prompt at the bottom. Being
able to clear the screen automatically is a potential privacy
enhancement since that way a user's inbox isn't visible unless they're
actively viewing it.

I see that there's a 3p patches page on the Wiki. Is that still actively
maintained? If so, is that a more appropriate place to add the patch if
you don't think it belongs in mutt proper?

- Oskari

Re: [PATCH] Option to clear the screen on quit

[Claus Assmann]

Why don't you use a wrapper which invokes
clear
after mutt finished? No extra code needed in mutt.

Re: [PATCH] Option to clear the screen on quit

[Oskari Pirhonen]

On Sun, Oct 17, 2021 at 08:31:41PM +0100, Claus Assmann wrote:
> Why don't you use a wrapper which invokes
> clear
> after mutt finished? No extra code needed in mutt.

Wow, I can't believe I didn't think of that *facepalms*.

Thanks for the tip. It was much faster to write than adding the config
option. Here's the script I used in case anyone else sees this and wants
to do the same:

```
#! /bin/bash

eval $(which mutt) "$@" && clear
```

- Oskari

Re: [PATCH] Option to clear the screen on quit

[Matthias Andree]

Am 17.10.21 um 22:04 schrieb Oskari Pirhonen:
> On Sun, Oct 17, 2021 at 08:31:41PM +0100, Claus Assmann wrote:
>> Why don't you use a wrapper which invokes
>> clear
>> after mutt finished? No extra code needed in mutt.
> Wow, I can't believe I didn't think of that *facepalms*.
>
> Thanks for the tip. It was much faster to write than adding the config
> option. Here's the script I used in case anyone else sees this and wants
> to do the same:
>
> ```
> #! /bin/bash
>
> eval $(which mutt) "$@" && clear
> ```

Oskari,

Speaking of simplifications:

1. Is the "clear only if mutt exits with status 0" intentional? If not,
";" would be preferable to "&&".

2. Why do you 'eval $(which mutt)' rather than just running plain 'mutt'?
which(1) isn't portable, it's not a POSIX utility nor a POSIX sh built-in,
and its output may consequently be unsuitable for shell evaluation.

Re: [PATCH] Option to clear the screen on quit

[Oskari Pirhonen]

On Mon, Oct 18, 2021 at 12:33:33AM +0200, Matthias Andree wrote:
> 1. Is the "clear only if mutt exits with status 0" intentional? If not,
> ";" would be preferable to "&&".

It is intentional, yes. I don't want it to clear the screen if there's
an error so that any messages that may be printed aren't lost.

> 2. Why do you 'eval $(which mutt)' rather than just running plain 'mutt'?
> which(1) isn't portable, it's not a POSIX utility nor a POSIX sh built-in,
> and its output may consequently be unsuitable for shell evaluation.

I had mistakenly assumed which(1) was in coreutils, which would be fine
for reasonably portable scripts. Thanks for pointing that out, I'm sure
to remember it now. Come to think of it, not entirely sure why I used
eval there; it works fine when I remove it too.

Thanks for the tips. Updated script, just for the record:

```
#! /bin/bash

mutt "$@" && clear
```

- Oskari

Re: [PATCH] Option to clear the screen on quit

[Vincent Lefevre]

On 2021-10-17 19:40:19 -0500, Oskari Pirhonen wrote:
> I had mistakenly assumed which(1) was in coreutils, which would be fine
> for reasonably portable scripts.

Note that under Debian/unstable, /usr/bin/which now gives a warning:

/usr/bin/which: this version of `which' is deprecated; use `command -v' in 
scripts instead.

> Thanks for the tips. Updated script, just for the record:
> 
> ```
> #! /bin/bash
> 
> mutt "$@" && clear
> ```

If you're using "clear" for privacy reasons and your terminal happens
to have an alternate screen, note that "clear" will *not* clear the
alternate screen. For instance, with xterm, after quitting Mutt, you
can do a Ctrl-MiddleClick, then click on "Show Alternate Screen", and
this reveals Mutt's contents just before Mutt has quit.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: [PATCH] Option to clear the screen on quit

[Vincent Lefevre]

On 2021-10-17 09:35:26 -0700, Kevin J. McCarthy wrote:
> On Sun, Oct 17, 2021 at 12:25:24AM -0500, Oskari Pirhonen wrote:
> > Add the option to clear the screen when quitting mutt. This is
> > controlled by the clear_on_quit config option. Defaults to "no".
> 
> I think most terminals nowadays have alternative screen support enabled by
> default, don't they?  Unless this is a common option in other applications,
> I don't feel like this belongs inside Mutt.

Following my remark about the privacy reason, I think that the patch
would be useful to make sure that data are not silently left on the
alternate screen (which is no longer visible after quitting Mutt,
but can be retrieved at least in xterm with its menus, and possibly
via escape sequences I think). The patch clears the screen before
quitting the curses window, thus does the right thing. But the
description needs a bit more details, as many users might think
that this option is not useful for them (as the alternate screen
is no longer visible), while it could be.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: [PATCH] Option to clear the screen on quit

[Kevin J. McCarthy]

On Fri, Oct 22, 2021 at 12:51:04PM +0200, Vincent Lefevre wrote:

Following my remark about the privacy reason, I think that the patch
would be useful to make sure that data are not silently left on the
alternate screen (which is no longer visible after quitting Mutt,
but can be retrieved at least in xterm with its menus, and possibly
via escape sequences I think).


I don't feel _strongly_ against the patch, but absent a real threat 
model I'm still not convinced it belongs inside Mutt.


After 25 years of this behavior, is clearing the alternate screen really 
now a security or privacy issue; against an attacker who evidently has 
access to your terminal?


A quick test showed vim and less also leave the alternate state as-is.

However, I'm often wrong, and so invite others to please tell me I'm 
being an idiot (again).  :-)


--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature

Re: [PATCH] Option to clear the screen on quit

[Vincent Lefevre]

On 2021-10-22 10:30:43 -0700, Kevin J. McCarthy wrote:
> On Fri, Oct 22, 2021 at 12:51:04PM +0200, Vincent Lefevre wrote:
> > Following my remark about the privacy reason, I think that the patch
> > would be useful to make sure that data are not silently left on the
> > alternate screen (which is no longer visible after quitting Mutt,
> > but can be retrieved at least in xterm with its menus, and possibly
> > via escape sequences I think).
> 
> I don't feel _strongly_ against the patch, but absent a real threat model
> I'm still not convinced it belongs inside Mutt.
> 
> After 25 years of this behavior, is clearing the alternate screen really now
> a security or privacy issue; against an attacker who evidently has access to
> your terminal?

There might still be a possibility to have the contents printed via
escape sequences, e.g. with some shell command. For instance, what
happened to me in the past:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=301989

(FYI, the data were sent on a *shared* printer in my lab).

The same kind of issue could theoretically still occur, though this
should be very rare.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: [PATCH] Option to clear the screen on quit

[Derek Martin]

On Sat, Oct 23, 2021 at 02:04:08PM +0200, Vincent Lefevre wrote:
> On 2021-10-22 10:30:43 -0700, Kevin J. McCarthy wrote:
> > On Fri, Oct 22, 2021 at 12:51:04PM +0200, Vincent Lefevre wrote:
> > > Following my remark about the privacy reason, I think that the patch
> > > would be useful to make sure that data are not silently left on the
> > > alternate screen (which is no longer visible after quitting Mutt,
> > > but can be retrieved at least in xterm with its menus, and possibly
> > > via escape sequences I think).
> > 
> > I don't feel _strongly_ against the patch, but absent a real threat model
> > I'm still not convinced it belongs inside Mutt.
> > 
> > After 25 years of this behavior, is clearing the alternate screen really now
> > a security or privacy issue; against an attacker who evidently has access to
> > your terminal?
> 
> There might still be a possibility to have the contents printed via
> escape sequences, e.g. with some shell command. For instance, what
> happened to me in the past:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=301989
> 
> (FYI, the data were sent on a *shared* printer in my lab).

There is an ANSI escape sequence to tee data to your printer, sure...
but it can not be used retroactively copy data that is on your
terminal to the printer.  It just copies data that is currently being
displayed (i.e. since the sequence was emitted) to the printer.

I think the notion that this is a privacy/security concern is nuts.
In the unlikely scenario you left something sensitive on your terminal
window when you exited mutt, andf you're *really* that paranoid, clear
the screen from your terminal's menu before leaving it, or close your
terminal window.  If you leave your computer unattended and unlocked,
giving random passers-by access to your terminals, THAT, not this, is
the security issue.

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



signature.asc
Description: PGP signature

Re: [PATCH] Option to clear the screen on quit

[Vincent Lefevre]

On 2021-10-25 14:44:32 -0500, Derek Martin wrote:
> There is an ANSI escape sequence to tee data to your printer, sure...
> but it can not be used retroactively copy data that is on your
> terminal to the printer.  It just copies data that is currently being
> displayed (i.e. since the sequence was emitted) to the printer.

I was wondering whether this could occur when switching to the
alternate screen. But it seems that this is not the case, at least
not with Xterm's logging feature.

So I assume that as long as the user doesn't use a virtual terminal
inside the real terminal, things are safe. Users of virtual terminals
(GNU Screen, etc.) should be careful, as older data are sent back to
the real terminal when switching a window, for instance. However, in
case of any issue, the real solution should be to ensure that the
printing feature is disabled.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: [PATCH] Option to clear the screen on quit

[Steffen Nurpmeso]

Vincent Lefevre wrote in
 <20211027151035.ga14...@cventin.lip.ens-lyon.fr>:
 |On 2021-10-25 14:44:32 -0500, Derek Martin wrote:
 |> There is an ANSI escape sequence to tee data to your printer, sure...
 |> but it can not be used retroactively copy data that is on your
 |> terminal to the printer.  It just copies data that is currently being
 |> displayed (i.e. since the sequence was emitted) to the printer.
 |
 |I was wondering whether this could occur when switching to the
 |alternate screen. But it seems that this is not the case, at least
 |not with Xterm's logging feature.
 |
 |So I assume that as long as the user doesn't use a virtual terminal
 |inside the real terminal, things are safe. Users of virtual terminals
 |(GNU Screen, etc.) should be careful, as older data are sent back to
 |the real terminal when switching a window, for instance. However, in
 |case of any issue, the real solution should be to ensure that the
 |printing feature is disabled.

Fwiw i implemented optional automatic clearance upon suspension (/
exit) when ca-mode (smcup..rmcup) is enabled for the mailer
i maintain, blindly trusting your words (i use the st terminal).
You and Oskari Pirhonen have a credit for this.  I thought it is
nice since the alternative screen cannot be reached via clear(1).
(Granted the MUA is not really ca-mode compatible.)

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [PATCH] Option to clear the screen on quit

[Derek Martin]

On Wed, Oct 27, 2021 at 05:10:35PM +0200, Vincent Lefevre wrote:
> On 2021-10-25 14:44:32 -0500, Derek Martin wrote:
> > There is an ANSI escape sequence to tee data to your printer, sure...
> > but it can not be used retroactively copy data that is on your
> > terminal to the printer.  It just copies data that is currently being
> > displayed (i.e. since the sequence was emitted) to the printer.
> 
> I was wondering whether this could occur when switching to the
> alternate screen. But it seems that this is not the case, at least
> not with Xterm's logging feature.

Right, that wouldn't make sense... the I/O is not re-delivered to the
terminal (and I assume the contents of the alternate screen are just
sitting in a buffer, which is simply re-displayed).  Otherwise
switching back and forth between screens would cause the data to be
sent to the printer, again and again...  That does not seem like it
would ever be desireable behavior.

> So I assume that as long as the user doesn't use a virtual terminal
> inside the real terminal, things are safe. Users of virtual terminals
> (GNU Screen, etc.) should be careful, as older data are sent back to
> the real terminal when switching a window, for instance.

I hadn't considered this, but one would hope that maintainers of such
software would not buffer the printer sequence so that it is only
issued on initial display.  In any case...

> However, in case of any issue, the real solution should be to ensure
> that the printing feature is disabled.

I would not disagree. :)

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



signature.asc
Description: PGP signature

Re: [PATCH] Option to clear the screen on quit

[Cameron Simpson]

On 22Oct2021 10:30, Kevin J. McCarthy  wrote:
[...]
>After 25 years of this behavior, is clearing the alternate screen 
>really now a security or privacy issue; against an attacker who 
>evidently has access to your terminal?

Plenty of attackers can peer over your shoulder (as opposed to getting 
to sit and use the terminal).

That said, and ignoring the alternate screen, I've noted with annoyance 
that "clear" in iterm doesn't erase. It seems to scroll up or something; 
can scroll back to my content. handy for accidents, but when that 
content came from my password wallet this is not what I want.

Cheers,
Cameron Simpson 

Re: [PATCH] Option to clear the screen on quit

[Cameron Simpson]

On 17Oct2021 15:04, Oskari Pirhonen  wrote:
>#! /bin/bash

I much prefer:

#!/bin/sh

absent some special reason. /bin/sh exists on all POSIX systems, and 
bash need not (and if it does, it is not always in /bin).

>eval $(which mutt) "$@" && clear

Others have wondered about the "which". I wonder about the "eval", which 
is just asking for attack (or unhappy accidents). Please try not to use 
it.

Cheers,
Cameron Simpson 

Re: [PATCH] Option to clear the screen on quit

[Vincent Lefevre]

On 2021-10-29 14:19:29 -0500, Derek Martin wrote:
> On Wed, Oct 27, 2021 at 05:10:35PM +0200, Vincent Lefevre wrote:
> > I was wondering whether this could occur when switching to the
> > alternate screen. But it seems that this is not the case, at least
> > not with Xterm's logging feature.
> 
> Right, that wouldn't make sense... the I/O is not re-delivered to the
> terminal (and I assume the contents of the alternate screen are just
> sitting in a buffer, which is simply re-displayed).  Otherwise
> switching back and forth between screens would cause the data to be
> sent to the printer, again and again...  That does not seem like it
> would ever be desireable behavior.

Well, for lots of bugs, the behavior doesn't make sense. That's why
they are bugs. Thus it may be a good idea not to leave private data
behind, in case there would be such a bug.

Similarly, there is (was?) this old Xorg/nouveau bug that may reveal
parts of the user's desktop after reboot (which is problematic on a
shared computer). Displaying old video memory (not erased at logout
or at shutdown) doesn't make sense, but this happened.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: [PATCH] Option to clear the screen on quit

[Petr Pisar]

V Mon, Nov 01, 2021 at 11:44:25AM +1100, Cameron Simpson napsal(a):
> That said, and ignoring the alternate screen, I've noted with annoyance 
> that "clear" in iterm doesn't erase. It seems to scroll up or something; 
> can scroll back to my content. handy for accidents, but when that 
> content came from my password wallet this is not what I want.
> 
For that purposes I added ^[3J sequence into Linux 3.0 which erases not only
whole display but also a scroll-back buffer of the terminal. (Though Linux
4.something removed scrollback buffer completely, you cannot Shift+PgUp
anymore.)

Maybe it's time to send a feature request to a terminal emulator of your
choice to implement it. (I remember xterm's maintainer was not against.)
clear of ncurses emmits it:

$ clear | hexdump -C
  1b 5b 48 1b 5b 32 4a 1b  5b 33 4a |.[H.[2J.[3J|
000b

Naturaly it should also extend to altearnative screens. As the purpose of the
sequence is to erase all data for security reasons.

-- Petr


signature.asc
Description: PGP signature

Re: [PATCH] Option to clear the screen on quit

[Derek Martin]

On Tue, Nov 02, 2021 at 12:17:17PM +0100, Vincent Lefevre wrote:
> On 2021-10-29 14:19:29 -0500, Derek Martin wrote:
> > On Wed, Oct 27, 2021 at 05:10:35PM +0200, Vincent Lefevre wrote:
> > > I was wondering whether this could occur when switching to the
> > > alternate screen. But it seems that this is not the case, at least
> > > not with Xterm's logging feature.
> > 
> > Right, that wouldn't make sense... the I/O is not re-delivered to the
> > terminal (and I assume the contents of the alternate screen are just
> > sitting in a buffer, which is simply re-displayed).  Otherwise
> > switching back and forth between screens would cause the data to be
> > sent to the printer, again and again...  That does not seem like it
> > would ever be desireable behavior.
> 
> Well, for lots of bugs, the behavior doesn't make sense. That's why
> they are bugs. Thus it may be a good idea not to leave private data
> behind, in case there would be such a bug.
> 
> Similarly, there is (was?) this old Xorg/nouveau bug that may reveal
> parts of the user's desktop after reboot (which is problematic on a
> shared computer). Displaying old video memory (not erased at logout
> or at shutdown) doesn't make sense, but this happened.

Yeah but those are actual bugs, where leaving data behind on the
user's terminal's alternate screen IS NOT.  It's designed to work that
way, and the design is correct... it's largely the reason alternate
screens exist.  Re-dumping the data to your printer would be a bug in
your terminal.

If your terminal has a bug where that's a problem, any related
security issue is in the terminal, NOT in Mutt.  I think you can make
a pretty good case that Mutt should work around stupidity in broken
e-mail clients (like all the various brain damage in Outlook), since
it is directly related to, and directly affects, Mutt's primary
function.  But I don't think you can make a good case that Mutt should
try to work around every possible bug in every possible software
component of your system, since that is a practical impossibility.

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



signature.asc
Description: PGP signature

Re: [PATCH] Option to clear the screen on quit

[Derek Martin]

On Tue, Nov 02, 2021 at 07:10:24PM +0100, Petr Pisar wrote:
> V Mon, Nov 01, 2021 at 11:44:25AM +1100, Cameron Simpson napsal(a):
> For that purposes I added ^[3J sequence into Linux 3.0 which erases not only
> whole display but also a scroll-back buffer of the terminal. (Though Linux
> 4.something removed scrollback buffer completely, you cannot Shift+PgUp
> anymore.)
> 
> Maybe it's time to send a feature request to a terminal emulator of your
> choice to implement it. (I remember xterm's maintainer was not against.)
> clear of ncurses emmits it:
> 
> $ clear | hexdump -C
>   1b 5b 48 1b 5b 32 4a 1b  5b 33 4a |.[H.[2J.[3J|
> 000b
> 
> Naturaly it should also extend to altearnative screens. As the purpose of the
> sequence is to erase all data for security reasons.

No that's not "natural."  The whole point of having alternative
screens is to retain the data on one while you do work in the other.
If you want the alternate screen cleared, clear it.  If worse comes to
worst, close the terminal.  A command-line option to clear might be
nice to make this easy for the user, but it should not be the default
behavior.  Then if it really is what you want, all the time, you can
just make a shell alias:

alias clear="clear --clear-alternate-screen-also"


-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



signature.asc
Description: PGP signature

Re: [PATCH] Option to clear the screen on quit

[Vincent Lefevre]

On 2021-11-09 17:42:57 -0600, Derek Martin wrote:
> On Tue, Nov 02, 2021 at 07:10:24PM +0100, Petr Pisar wrote:
> > V Mon, Nov 01, 2021 at 11:44:25AM +1100, Cameron Simpson napsal(a):
> > For that purposes I added ^[3J sequence into Linux 3.0 which erases not only
> > whole display but also a scroll-back buffer of the terminal. (Though Linux
> > 4.something removed scrollback buffer completely, you cannot Shift+PgUp
> > anymore.)
> > 
> > Maybe it's time to send a feature request to a terminal emulator of your
> > choice to implement it. (I remember xterm's maintainer was not against.)
> > clear of ncurses emmits it:
> > 
> > $ clear | hexdump -C
> >   1b 5b 48 1b 5b 32 4a 1b  5b 33 4a |.[H.[2J.[3J|
> > 000b
> > 
> > Naturaly it should also extend to altearnative screens. As the
> > purpose of the sequence is to erase all data for security reasons.
> 
> No that's not "natural."  The whole point of having alternative
> screens is to retain the data on one while you do work in the other.

The main point of the alternate screen is to retain data on the main
screen, which is typically a shell session. I doubt that people wish
to retain data on the alternate screen in general, and most terminals
don't offer an option to display the content of the alternate screen
(switching to the alternate screen with "tput smcup" won't work,
because it is automatically cleared at this time, even with xterm).
And note that even when the content of the alternate screen is kept
and can be retrieved, these are only partial data, because the
alternate screen does not have a scroll-back buffer.

BTW, in the past, xterm was clearing the alternate screen when
switching back to the main screen:

  https://invisible-island.net/xterm/xterm.faq.html#xterm_tite

  "The 1049 code is a refinement of 1047 and 1048, clearing the
  alternate screen before switching to it rather than after switching
  back to the normal screen. Since patch #90 in 1998 xterm allows you
  (with a popup menu entry designed to exploit this behavior) to
  switch the display back to the alternate screen to select text from
  it, to paste into the normal screen. You can also set or clear the
  titeInhibit resource using another popup menu entry (Enable
  Alternate Screen Switching)."

This is an interesting feature when an external command is run from
the application. For instance, with Mutt, this happens when replying
to a mail: Mutt quits the alternate screen before running the editor,
but one may still want the data that were displayed before the editor
was run.

> If you want the alternate screen cleared, clear it.  If worse comes to
> worst, close the terminal.  A command-line option to clear might be
> nice to make this easy for the user, but it should not be the default
> behavior.  Then if it really is what you want, all the time, you can
> just make a shell alias:
> 
> alias clear="clear --clear-alternate-screen-also"

That doesn't exist, but a solution to clear the alternate screen
is "tput smcup; tput rmcup" (and you can add "clear" if you want
to clear the main screen too).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: [PATCH] Option to clear the screen on quit

[Derek Martin]

On Mon, Nov 01, 2021 at 11:47:40AM +1100, Cameron Simpson wrote:
> On 17Oct2021 15:04, Oskari Pirhonen  wrote:
> >#! /bin/bash
> 
> I much prefer:
> #!/bin/sh
> absent some special reason. /bin/sh exists on all POSIX systems, and 
> bash need not (and if it does, it is not always in /bin).

I agree wholeheartedly, and FWIW invoking as bash changes the behavior
of scripts in subtle but possibly undesireable ways.  Probably won't
affect most people but if you're a "power user" and use certain
features of the shell (such as for example setting ENV) it can...

The only downside is these days on many systems /bin/sh is dash which
annoyingly behaves differently than bash, again in mostly subtle ways,
but one common one you might hit is options for the echo command.

> >eval $(which mutt) "$@" && clear
> 
> Others have wondered about the "which". I wonder about the "eval", which 
> is just asking for attack (or unhappy accidents). Please try not to use 
> it.

Agree on this as well.  Someone commented that which is deprecated on
debian unstable--this seems like a pointless and stupid change.  Every
Unix system I can think of has had a which command going back maybe 40
years... deprecating it has the potential to break a lot of things for
as far as I can see no practical reason whatsoever.

This is not progress.

On Mon, Nov 01, 2021 at 11:44:25AM +1100, Cameron Simpson wrote:
> On 22Oct2021 10:30, Kevin J. McCarthy  wrote:
> [...]
> >After 25 years of this behavior, is clearing the alternate screen 
> >really now a security or privacy issue; against an attacker who 
> >evidently has access to your terminal?

Hopefully we've established that it isn't.

> That said, and ignoring the alternate screen, I've noted with annoyance 
> that "clear" in iterm doesn't erase.

I don't think that's actually true--at least it isn't for me.  It
absolutely does clear the terminal...  But what it does not do is
clear the scroll-back buffer.  I would prefer it did, also.  It may
have a setting for that which I haven't discovered.

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



signature.asc
Description: PGP signature

Re: [PATCH] Option to clear the screen on quit

[Derek Martin]

On Mon, Jan 10, 2022 at 06:21:58PM -0600, Derek Martin wrote:
> > I much prefer:
> > #!/bin/sh
> > absent some special reason. /bin/sh exists on all POSIX systems, and 
> > bash need not (and if it does, it is not always in /bin).
> 
> I agree wholeheartedly, and FWIW invoking as bash changes the behavior

Sorry for waking up this thread, I had this message postponed from 2
months ago and meant to kill it, sent it instead. ^_^;

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



signature.asc
Description: PGP signature