On Sun, Dec 22, 2024 at 12:49:07AM +0700, Budi wrote:
> How is Bash' code to store string of any characters should be containing
> pair of "" and '' at the same time explicitly, being exact verbatim so,
> ie. cannot be modified, escaped or etc, as expected from ordinary/naive
> human writing), into
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
On Sat, Aug 10, 2024 at 12:01:58PM +1000, Martin D Kealey wrote:
> If anyone tells you that honorific+given name is the preferred polite way
> to talk to older people, tell them you know someone whose native language
> is English who says that what they're saying is "polite" is actually an
> insult
On Mon, Dec 25, 2023 at 05:00:37PM -0500, Seth Sabar wrote:
> I'm reaching out to report what I believe to be a bug with the
> *--pretty-print* feature in bash-5.2.
Tangentially, this option doesn't seem to be documented outside of "bash
--help":
$ git clone https://git.savannah.gnu.org/git/b
On Fri, Nov 10, 2023 at 01:22:54PM -0500, Greg Wooledge wrote:
> It most definitely is *not* everywhere. It's part of GNU coreutils,
> and is generally not present on any system that does't use those (BSDs
> and commercial Unixes for example).
>From _seq(1)_ on FreeBSD:
> The seq command first a
On Thu, May 28, 2020 at 03:12:47PM -0700, Keith Thompson wrote:
> I see this problem on copies of bash 5.0.16 and 5.0.17 built from
> sourced on Ubuntu 20.04 LTS. It does *not* occur with the /bin/bash
> GNU bash, version 5.0.16(1)-release (x86_64-pc-linux-gnu)
> provided by the distribution.
On Thu, Nov 24, 2016 at 12:05:20AM -0800, Eric Pruitt wrote:
> In my Bash configuration, I have things setup so Ctrl+Z is no longer
> translated into a signal at the Bash prompt so it can be remapped. Most
> recently, I decided to modify the Bash source to implement this change
On Thu, Dec 22, 2016 at 09:32:37AM -0500, Chet Ramey wrote:
> I haven't thought about it too much, but I'm initially reluctant to put
> this into the mainline source, when it seems like it could be accomplished
> without any source changes at all.
A lot of "new" functionality added in each release
On Thu, Nov 24, 2016 at 12:05:20AM -0800, Eric Pruitt wrote:
> In my Bash configuration, I have things setup so Ctrl+Z is no longer
> translated into a signal at the Bash prompt so it can be remapped. Most
> recently, I decided to modify the Bash source to implement this change
In my Bash configuration, I have things setup so Ctrl+Z is no longer
translated into a signal at the Bash prompt so it can be remapped. Most
recently, I decided to modify the Bash source to implement this change
in the interpreter because the stty invocations introduced a perceptible
amount of lag
On Wed, Oct 05, 2016 at 09:20:58AM -0400, Chet Ramey wrote:
> Try the attached patch, which reduces the number of warnings to 1 per call
> to command substitution.
I don't agree with this approach -- I think you should be able to turn
off the warning completely, so I am not interested in testing t
On Fri, Sep 16, 2016 at 03:45:39PM -0400, Greg Wooledge wrote:
> On Fri, Sep 16, 2016 at 12:38:20PM -0700, Eric Pruitt wrote:
> > first time. However, that construct still won't work because if a
> > variable is defined, it will still choose "not empty:"
> &
On Fri, Sep 16, 2016 at 12:30:59PM -0700, Eric Pruitt wrote:
> > That, or ${VAR:+not empty} which is how I suggest testing for variable
> > set-and-not-empty-ness.
>
> I'm aware of that construct, but that doesn't do what I want unless I'm
> missing something;
On Fri, Sep 16, 2016 at 03:22:29PM -0400, Greg Wooledge wrote:
> Off hand I'd say the bash 4.4 behavior is correct. * matches 0 or
> more characters, so it should match an empty or undefined variable.
Yes, I agree that the Bash 4.4 behavior is more reasonable, but I think
the change at least need
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu'
-DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/local/share
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu'
-DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/local/share
On Sun, May 01, 2016 at 03:54:16AM -0400, Grisha Levit wrote:
> Does the issue go away if you do a "bind 'set colored-stats off"' ?
No. That already defaults to "off", and I don't override it. I ran the
"bind" command anyway, and it didn't make a difference.
Eric
On Tue, Apr 26, 2016 at 01:54:12PM -0400, Chet Ramey wrote:
> Thanks for the report. I will fix this before bash-4.4 is released.
Is there some way for me to work around this issue in older versions of
Bash using autocompletion hooks?
Eric
On Tue, Apr 26, 2016 at 01:54:12PM -0400, Chet Ramey wrote:
> Thanks for the report. I will fix this before bash-4.4 is released.
Thank you. I am happy to compile a prerelease build to try out your
solution if you want another tester before you roll fix into an RC.
Eric
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKA
20 matches
Mail list logo
