On 11/18/24 10:22 PM, Grisha Levit wrote:
On Tue, Nov 5, 2024 at 11:20 AM Chet Ramey wrote:
On 10/18/24 4:22 PM, Grisha Levit wrote:
There's some issue with undo list handling in history-search-* commands:
Doing a successful search with a line that has an undo list causes the
undo entries fr
On 12/2/24 12:52 AM, Keith Thompson wrote:
Bash Version: 5.2
Patch Level: 32
Release Status: release
Description:
If the wordlist given to `complete -W` includes words
containing the ':' character, completion misbehaves.
The problem seems to occur if two or more words in the wordlist
What is your value of COMP_WORDBREAKS?
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
On 11/30/24 10:41 PM, Lawrence Velázquez wrote:
On Sat, Nov 30, 2024, at 9:36 PM, Dan Jacobson wrote:
We see for simple
$ history
output, there's no way to change the file it reads, at least with the
current (same PID) shell.
Why is "same PID" a requirement? Why isn't something like this
suff
On Sat, Nov 30, 2024, 2:05 AM Dan Jacobson wrote:
> $ history
> is nice, but what if you want to have it read from a different file?
> $ help history
> says
> If FILENAME is given, it is used as the history file. Otherwise,
> if HISTFILE has a value, that is used, else ~/.bash_history.
>
On 11/30/24 9:36 PM, Dan Jacobson wrote:
$ history |wc - $HISTFILE|sed \$d
7622 75741 532254 -
14973 29625 320996 /home/jidanni/.bash_history_jidanni
Works as expected.
Sure. You have fewer in-memory history entries than in your history file,
which is kind of unusual, but not unhea
On Mon, Dec 2, 2024, at 3:27 PM, Chet Ramey wrote:
> On 11/30/24 10:41 PM, Lawrence Velázquez wrote:
>> On Sat, Nov 30, 2024, at 9:36 PM, Dan Jacobson wrote:
>>> We see for simple
>>> $ history
>>> output, there's no way to change the file it reads, at least with the
>>> current (same PID) shell.
>
On Mon, Dec 02, 2024 at 12:27:41PM -0800, Chet Ramey wrote:
> On 11/30/24 10:41 PM, Lawrence Velázquez wrote:
> > history_f() (
> > history -c &&
> > history -r -- "$1" &&
> > history
> > )
> > history_f .bash_history_foobar
>
> That *is* the `same P
OK, that explains the problem, and I have a workaround.
(Background: I have a personal tool that uses "foo:bar" syntax for
some of its arguments. I've modified the tool to use "foo/bar
instead.)
Escaping the colons with backslashes doesn't seem to work:
$ echo $BASH_VERSION
5.2.32(1)-release
$ e
On 12/2/24 5:05 PM, Lawrence Velázquez wrote:
On Mon, Dec 2, 2024, at 3:27 PM, Chet Ramey wrote:
On 11/30/24 10:41 PM, Lawrence Velázquez wrote:
On Sat, Nov 30, 2024, at 9:36 PM, Dan Jacobson wrote:
We see for simple
$ history
output, there's no way to change the file it reads, at least with t
10 matches
Mail list logo
