I wouldn't consider dozens of stackoverflow/askubuntu/etc complaints of
missing/disappearing history "cherry-picked". There were far more than
I sent.
I understand not wanting to pull the rug out from under people, but the
kludges Kealey posted were inelegant. An opt-in for the suggested
be
On Tue, Aug 20, 2024, at 1:42 AM, supp...@eggplantsd.com wrote:
> The suggestion is that the default behavior needs some work
The default behavior is unlikely to change. For every cherry-picked
example of someone unsatisfied with it (bugs aside), there is likely
someone else who prefers it as is
I know it can. The suggestion is that the default behavior needs some
work:
https://askubuntu.com/questions/67283/is-it-possible-to-make-writing-to-bash-history-immediate
https://askubuntu.com/questions/80371/bash-history-handling-with-multiple-terminals
https://askubuntu.com/questions/885531/h
sorry, I meant HISTTIMEFORMAT rather than HISTTIMEFMT
On Tue, 20 Aug 2024 at 14:58, Martin D Kealey
wrote:
> The following suggestions, or close approximations, can all be implemented
> using the existing facilities.
>
> On Tue, 20 Aug 2024 at 05:52, wrote:
>
>> I would suggest:
>>
>> 1. Append
The following suggestions, or close approximations, can all be implemented
using the existing facilities.
On Tue, 20 Aug 2024 at 05:52, wrote:
> I would suggest:
>
> 1. Append to history file immediately on each command.
>
Easily done by putting `history -a` into `PROMPT_COMMAND`
2. Restrict u
2024年8月20日(火) 5:52 Koichi Murase :
> 2024年8月20日(火) 2:25 Martin D Kealey :
> > Perhaps a compromise would be to put the documentation in a directory
> > that's not inside the source code directory, so it's easier to `git diff`
> > just one or the other. (In practice, that would mean moving some of
2024年8月20日(火) 2:25 Martin D Kealey :
> Perhaps a compromise would be to put the documentation in a directory
> that's not inside the source code directory, so it's easier to `git diff`
> just one or the other. (In practice, that would mean moving some of the
> code into a new subdirectory.)
One c
On Mon, Aug 19, 2024 at 15:52:22 -0400, supp...@eggplantsd.com wrote:
> I would suggest:
> 2. Restrict up-arrow completion to the history of present session.
This is going to be an *extremely* unpopular suggestion.
Though, I must wonder: do you literally mean *only* the up-arrow (or
Ctrl-P or ESC
Version: GNU bash, version 5.2.15(1)-release (x86_64-pc-linux-gnu)
OS: Linux 6.1.0-23-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.99-1
(2024-07-15) x86_64 GNU/Linux
Issue: History Behavior
For up-arrow completion, I think restricting to the history of the
current bash session is the correct beha
This was actually caught by the test suite
---
builtins/shopt.def | 1 +
tests/shopt.right | 4
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/builtins/shopt.def b/builtins/shopt.def
index 67bc0c22..37fda11e 100644
--- a/builtins/shopt.def
+++ b/builtins/shopt.def
@@ -357,6 +3
On Mon, 19 Aug 2024 at 06:45, shynur . wrote:
> I believe these output files should be added to `.gitignore` and generated
> during the `make` process.
Not doing so is deliberate in some cases.
In an ideal world, yes they should be generated during `make`, but that
would increase the "build to
On 2024-08-18 at 11:21 +0700, Robert Elz wrote:
> Interactive shells with -n (noexec) set are pointless
The man page states:
> -n Read commands but do not execute them. This may be used
> to check a shell script for syntax errors. This is ig‐
>
12 matches
Mail list logo
