On 7/11/22 1:05 PM, Frédéric Moulins wrote:
Avoid a double redisplay when using reverse incremental search for
example. `rl_message` already calls `(*rl_redisplay_function)` before
returning, in all cases (`USE_VARARGS` or not).
Thanks for the report.
Chet
--
``The lyf so short, the craft so
On Sun, 10 Jul 2022 at 05:39, Yair Lenga wrote:
> Re: command prefaced by ! which is important:
> * The '!' operator 'normal' behavior is to reverse the exit status of a
> command ('if ! check-something ; then ...').
>
Unless that status is ignored, in which case, well, it's still ignored.
> *
Hi Yair
One other comment:
On Sun, 10 Jul 2022 at 05:39, Yair Lenga wrote:
> The old 'errexit' logic was spec'ed many years ago. As far as I can tell,
> it existed in bash 2.0, from 1996. I think requirements/expectations are
> different now. The 'exit on error' error handling was good for 1996
Thanks for sharing your thoughts. I admit that my goals are
significantly less ambitious compared with what you described (lexical
scope, etc.). I do not think that it's possible to stretch my proposal to
meet all the use cases you describe. For me, the 'errfail' is similar to
'pipefail' option - p
(typo correction).
Thanks for sharing your thoughts. I admit that my goals are
significantly less ambitious compared with what you described (lexical
scope, etc.). I do not think that it's possible to stretch my proposal to
meet all the use cases you describe. For me, the 'errfail' is similar to
'p
On 7/7/22 8:42 AM, Michal Berger wrote:
> BASH_VERSION: 5.1.4(1)-release (shipped with Debian 11)
>
> Considering script like this:
>
> 1 #!/usr/bin/env bash
> 2
> 3 set -o errexit
> 4 set -o errtrace
> 5
> 6 bt() {
> 7 local line file file_v
> 8
> 9
