On 8/24/20 4:15 PM, George R Goffe wrote:
> Chet,
>
> I'm not seeing any visual "bells". The audio part of this computer is
> broken... NO sound...
I'm not sure what I can do about that. If the visual bell doesn't work and
the sound is broken, you're not going to get much of an indication no
mat
On 8/24/20 3:05 PM, Шкіпер Десна wrote:
> Hello!
> If I use something like `user@localhost:/folder$ echo -n 123`, then in a
> new line before 'user...' I see '123', but it's yet normal, but if I use
> something like `user@localhost:/folder$ echo -n $(echo 123)` or
> `user@localhost:/folder$ printf
Hello!
If I use something like `user@localhost:/folder$ echo -n 123`, then in a
new line before 'user...' I see '123', but it's yet normal, but if I use
something like `user@localhost:/folder$ echo -n $(echo 123)` or
`user@localhost:/folder$ printf %s 123`, it may seem that everything is in
order,
On 8/20/20 12:13 PM, A M wrote:
> Hello, I would like to make a feature request/suggestion on Bash. (I was
> told submitting to this mailing list was the right way to do it.)
>
> Feature request: Enable reverse-search-history (C-r) to be case-insensitive.
>
> Currently reverse-search-history is c
On 8/24/20 3:53 PM, Martijn Dekker wrote:
>> What I mean is looking for PROMPT_COMMAND as happens now, and reacting a
>> different way if it's an array variable. That would resolve the existing
>> assignment issues, but open up the separate issues you describe.
>
>
> But I also suggested a way o
Op 24-08-20 om 20:37 schreef Chet Ramey:
On 8/24/20 12:58 PM, Martijn Dekker wrote:
Op 24-08-20 om 15:57 schreef Chet Ramey:
I sometimes think I should have stuck with converting PROMPT_COMMAND to
an array. Either way, there's going to be a transition, and maybe that
would have been the easiest
2020-08-25 1:59 Martijn Dekker :
> Is it too late? I think that would actually be cleaner than adding a
> separate array, per Koichi's report.
If it's not too late to change, converting PROMPT_COMMAND to an array
looks better to me too. As for the problem of scripts doing
`PROMPT_COMMAND=command'
On 8/24/20 12:58 PM, Martijn Dekker wrote:
> Op 24-08-20 om 15:57 schreef Chet Ramey:
>> I sometimes think I should have stuck with converting PROMPT_COMMAND to
>> an array. Either way, there's going to be a transition, and maybe that
>> would have been the easiest.
>
> Is it too late? I think tha
Op 24-08-20 om 15:57 schreef Chet Ramey:
I sometimes think I should have stuck with converting PROMPT_COMMAND to
an array. Either way, there's going to be a transition, and maybe that
would have been the easiest.
Is it too late? I think that would actually be cleaner than adding a
separate arr
2020-08-24 23:57 Chet Ramey :
> There's no real good solution. I wanted a clean break between the scalar
> and array versions, figuring that the distributions that populated
> PROMPT_COMMAND could easily make that PROMPT_COMMANDS[0].
Thank you for your reply. OK, if there would be no better solut
On 8/22/20 10:35 PM, Koichi Murase wrote:
> Hi, I have a question on the behavior of the new array PROMPT_COMMANDS
> and the best practice to use it.
>
> In coming Bash 5.1, the new array variable `PROMPT_COMMANDS' is
> available in the replacement of `PROMPT_COMMAND'. When the array
> `PROMPT_CO
On 8/22/20 5:25 PM, George R Goffe wrote:
>
> Chet,
>
> I'm really perplexed with this situation. I type in "ls -al 123456" with
> only 1 tab key. NO indication of what's happening. I hit enter and get a
> message that "ls: cannot access '123456': No such file or directory" I try
> the same co
Date:Sun, 23 Aug 2020 23:17:32 -0700 (MST)
From:almahdi
Message-ID: <1598249852364-0.p...@n7.nabble.com>
| How do we intercept and redirect file saving or output to stdout directly in
| bash, just like e.g
|
| xkbcomp $DISPLAY
I think you're just experiencing
13 matches
Mail list logo
