On Fri, 2021-08-13 at 10:10 -0400, Chet Ramey wrote:
> As long as you stick to things POSIX standardizes. Relevant here, the
> standard even includes a list of variables you should avoid using because
> various shells and applications use them.
GROUPS is not on this list that I can tell. It would
On Wed, 2021-08-11 at 20:36 -0400, Greg Wooledge wrote:
> On Wed, Aug 11, 2021 at 08:00:12PM -0400, Franklin, Jason wrote:
> > This doesn't work unless it was recently fixed. A variation does...
> >
> > bash-5.0$ echo $BASH_VERSION
> > 5.0.17(1)-release
> &
Chet:
My apologies in advance for not responding in thread. The bug-bash
archive interface doesn't expose the "Message-ID" header anywhere I can
find, and I am not a subscriber. I suppose I should become one. :)
> I believe I'd rather have variables behave as they're documented. It's more
> pr
Hey, Robert:
Thanks for the input! Quoting you here with some of my thoughts...
> Using a variable name that's outside what POSIX specifies is hardly
> using a feature that's outside POSIX - if it were then there would be
> no safe non-trivial scripts, since any variable name might be made magic
Hey, Greg!
I presume that you are the Wooledge who hosts the BashFAQ.
If so, thanks for hosting that. It's a huge help. :)
On Mon, 2021-08-09 at 20:36 -0400, Greg Wooledge wrote:
> On Mon, Aug 09, 2021 at 05:35:56PM -0400, Franklin, Jason wrote:
> > Should bash, invoked with &
Greetings:
I discovered today that the GROUPS variable is special in Bash.
I moved some scripts to a new box, and they stopped working. On this
box, /bin/sh linked to /bin/bash instead instead of /bin/dash.
Scripts of of this form...
#!/bin/sh
GROUPS='foo bar'
# do something with $GROUPS
On 5/5/20 11:41 AM, Chet Ramey wrote:
> Thanks for the report and your careful analysis.
>
>>
>> Allow me to explain the reasoning behind the patch...
>>
>> From the CHANGES file, we see this note concerning the "fc" builtin:
>>
>> b. The fc builtin now interprets -0 as the current command line
Greetings:
After sending the original email concerning this issue, I delved into
the code again for one last review. I discovered that, even after the
original fix a segmentation fault is still possible, because histbeg
could be higher than histend! The idea from "fc" would be to print the
list
Greetings:
Yesterday, I encountered a segmentation fault when using the "fc"
builtin command. I cloned the Bash source code from GNU Savannah, and I
verified that the bug is still present in the latest commits to the
master and devel branches (the work below applies to "devel").
To reproduce...
On 4/16/20 10:11 AM, Chet Ramey wrote:
> On 4/16/20 9:21 AM, Franklin, Jason wrote:
>> On 4/15/20 5:35 PM, Chet Ramey wrote:
>>> These all pretty much all fall into the category of the editor reprinting
>>> the prompt before it returns.
>>
>> Hmmm...
>&g
On 4/15/20 5:35 PM, Chet Ramey wrote:
> These all pretty much all fall into the category of the editor reprinting
> the prompt before it returns.
Hmmm...
So, is there no way to have Bash handle the printing of the prompt after
the return of the command and of the editor?
This would allow PROMPT_
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2
-fdebug-prefix-map=/build/bash-orJ5jM/bash-5.0=.
-fstack-protector-strong -Wformat -Werror=format-security -Wall
-Wno-parentheses -Wno-format-security
uname out
On 4/15/20 2:44 PM, Chet Ramey wrote:
> On 4/15/20 11:45 AM, Franklin, Jason wrote:
>> Greetings:
>>
>> I realized that I didn't include my email when I used bashbug to report
>> my issue, so I'm sending a follow-up email so that the maintainers can
>> be
Greetings:
I realized that I didn't include my email when I used bashbug to report
my issue, so I'm sending a follow-up email so that the maintainers can
be in touch.
I browsed the code and tried to fix the issue myself by modifying the
"prompt_again()" function to execute PROMPT_COMMAND directly
14 matches
Mail list logo
