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 t
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 a
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 scrol
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
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 th
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 c
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.
>
> R
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 won
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
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 cop
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.
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
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 sur
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 n
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
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
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 `comman
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 are
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 ti
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
o
Why don't you use a wrapper which invokes
clear
after mutt finished? No extra code needed in mutt.
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, b
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? Unle
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..5f4
24 matches
Mail list logo
