On Fri, 20 Dec 2024 08:09:40 -0500, Greg Wooledge wrote:
> Assuming you meant -d not -c:
Good eye.
> Why did you expect them to be the same?
A surprisingly hard question. Um, well, this report was from something I
noticed a few months ago.
As I recall, `help -d '('` returns information about
On Sunday, November 17, 2024, G. Branden Robinson <
g.branden.robin...@gmail.com> wrote:
>
> recondite
>
That's a recondite word, isn't it Sunday where you live?
--
Oğuz
That email I read. :-(
On Sat, Nov 16, 2024, 20:58 wrote:
> Send bug-bash mailing list submissions to
> bug-bash@gnu.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.gnu.org/mailman/listinfo/bug-bash
> or, via email, send a me
At 2024-11-16T18:52:12-0800, Wiley Young wrote:
> | From: Martin D Kealey
>
> | "In the general case I agree; man
>
> | pages should be reference
>
> | manuals, not tutorials"
>
> We should value others' contributions.
This statement implies that we lack a means of evaluating contribut
| From: Martin D Kealey
| "In the general case I agree; man
| pages should be reference
| manuals, not tutorials"
We should value others' contributions.
Most people, when they read something that they don't yet understand, if
they wish to understand it, will seek out a more accessible
$ bash --version | head -n1
GNU bash, version 5.2.15(1)-release (x86_64-pc-linux-gnu)
$ valgrind --leak-check=full \
--track-origins=yes \
--verbose \
--log-file=valgrind-out-bash.txt \
/bin/bash
==2762== Memcheck, a memory error detector
==2762== Copyright (
On 2/17/24 6:40 AM, John Larew wrote:
This is a portion of a script that appears to be problematic. Each of these
attempts appear to be valid; none of them work.
The issue is apparent with bash in both termux v0.118.0/5.22.6 and Ubuntu
v22.04.3 LTS/5.1.16 (see attached).
The clue is in the e
On 1/16/24 7:11 PM, Emre Ulusoy wrote:
Dear Bash Maintainers,
I hope this message finds you well. I am writing to inquire about the
possibility of contributing to your project.
Recently, I discovered a potential bug in the 'bash --posix' terminal and I
believe I have a fix that could resolve
On Tue, Jan 16, 2024, at 7:11 PM, Emre Ulusoy wrote:
> Recently, I discovered a potential bug in the 'bash --posix' terminal
> and I believe I have a fix that could resolve this issue. Before
> proceeding, I wanted to confirm if this is an open-source project where
> external contributions via p
Dear Bash Maintainers,
I hope this message finds you well. I am writing to inquire about the
possibility of contributing to your project.
Recently, I discovered a potential bug in the 'bash --posix' terminal and I
believe I have a fix that could resolve this issue. Before proceeding, I wanted
On 1/16/24 10:09 AM, Dr. Werner Fink wrote:
On 2024/01/16 09:27:19 -0500, Chet Ramey wrote:
On 1/16/24 4:00 AM, Dr. Werner Fink wrote:
what is with the readline82-008, readline82-009, and readline82-010
patches?
What about them?
Should those be part also of trhe bash52 patches as well?
B
On 2024/01/16 09:27:19 -0500, Chet Ramey wrote:
> On 1/16/24 4:00 AM, Dr. Werner Fink wrote:
>
> > what is with the readline82-008, readline82-009, and readline82-010
> > patches?
>
> What about them?
Should those be part also of trhe bash52 patches as well?
--
"Having a smoking section in a
On 1/16/24 4:00 AM, Dr. Werner Fink wrote:
what is with the readline82-008, readline82-009, and readline82-010
patches?
What about them?
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@cas
-Reference-URL:
> https://lists.gnu.org/archive/html/bug-bash/2022-09/msg00049.html
>
> Bug-Description:
>
> It's possible for readline to try to zero out a line that's not null-
> terminated, leading to a memory fault.
>
> Patch (apply with `patch -p0'
On 7/25/23 5:31 AM, Dr. Werner Fink wrote:
Thanks for the report. This was fixed several months ago.
OK ... last official patch for 5.2 is still bash52-015 :)
https://lists.gnu.org/archive/html/help-bash/2023-07/msg00078.html
But the patch is simple enough to attach.
--
``The lyf so short,
On 2023/07/24 13:16:23 -0400, Chet Ramey wrote:
> On 7/24/23 11:58 AM, vc--- via Bug reports for the GNU Bourne Again SHell
> wrote:
>
> > Bash Version: 5.2
> > Patch Level: 15
> > Release Status: release
> >
> > Description:
> > Segmentation fault in 'for ((...))' loop
> >
> > Repeat-By:
>
On Wed, 7 Sept 2022 at 18:13, Yair Lenga wrote:
> Thanks for providing feedback and expanding with new ideas.
>
> I believe the summary is:
>
> ${a.key1.key2} - Static fields
> ${a.key1.$key2} - Mixed dynamic/static, simple substitution.
> ${a.key1.{complex.$key2}} - For complex keys that may co
Another comment:
While it’s important to use “natural” access, I believe it is ok to have a
command to set values inside the h-value. It does not have to be supported as
part of …=… , which has lot of history, rule, interaction with env var, etc. I
think something like:
hset var.foo.bar=value
Thanks for providing feedback and expanding with new ideas.
I believe the summary is:
${a.key1.key2} - Static fields
${a.key1.$key2} - Mixed dynamic/static, simple substitution.
${a.key1.{complex.$key2}} - For complex keys that may contain anything
${a.key1[expr].key2] - expr is evaluated in num
Some things do indeed come down to personal preference, where there are no
right answers. Then Chet or his successor gets to pick.
Keep in mind that most or all of my suggestions are gated on not being in
backwards-compatibility mode, and that compat mode itself would be
lexically scoped. With tha
Martin brings up several good points, and I think it's worth figuring out
the direction of the implementation. Bash currently does not have good
syntax for H-values, so a new one is needed. It does not make sense to have
a completely new one, as there are few accepted syntax - python,
JavaScript, P
Rather than var[i1.i2.i3] I suggest a C-like var[i1][i2][i3] as that avoids
ambiguity for associative arrays whose keys might include ".", and makes it
simpler to add floating point arithmetic later.
I would like to allow space in the syntax to (eventually) distinguish
between an object with a fai
formats - can be extensions
Looking for feedback
Yair
Date: Fri, 2 Sep 2022 09:38:35 +1000
From: Chris Dunlop
To: Chet Ramey
Cc: tetsu...@scope-eye.net, bug-bash@gnu.org
Subject: Hierarchical data (was: Light weight support for JSON)
Message-ID: <20220901233835.ga2826...@onthe.net.au>
On 8/28/22 1:17 PM, Yair Lenga wrote:
Yes, you are correct - (most/all of) of those examples "K&R".
However, given bash's important role in modern computing - isn't it time to
take advantage of new language features ? this can make code more readable,
efficient and reliable.
There's no actual
On Sun, Aug 28, 2022, at 1:17 PM, Yair Lenga wrote:
> Yes, you are correct - (most/all of) of those examples "K&R".
>
> However, given bash's important role in modern computing - isn't it time to
> take advantage of new language features ?
Why? What benefit would that actually provide?
> this ca
in which they indicate Java 7 (or java java 8) support
will be phased out. Same for C++ and python.
On Sun, Aug 28, 2022 at 12:00 PM wrote:
> Send bug-bash mailing list submissions to
> bug-bash@gnu.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>
> To: Yair Lenga
> Cc: Lawrence Velázquez , Martin D Kealey
> , bug-bash
> Subject: Re: Revisiting Error handling (errexit)
> Message-ID:
> 0dd4vdyl...@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Wed, 6 Jul 2022 at 08:3
Greg,
I agree with you 100%. Not trying to fix errexit behavior. The new errfail (if
accepted) will provide better error handling (via opt-in) without breaking
existing code.
Yair.
Sent from my iPad
> On Jul 4, 2022, at 10:00 PM, bug-bash-requ...@gnu.org wrote:
>
> From: Greg Woole
On 3/31/22 4:44 PM, Jeremy Gurr wrote:
I have put together my own bash debugger (I like it better than the
others I've seen), and wanted to have variable name auto completion in
the 'read' built-in, just like it is in the base command line. Is
there a reason that bash uses a readline that is diff
I have put together my own bash debugger (I like it better than the
others I've seen), and wanted to have variable name auto completion in
the 'read' built-in, just like it is in the base command line. Is
there a reason that bash uses a readline that is differently
configured in the 'read' builtin
On 1/14/21 9:58 PM, Chet Ramey wrote:
On 1/11/21 11:00 AM, Thomas Mellman wrote:
But here's a bug for you, in readline:
- edit a line
- go to some character
- replace that character with another, using the "r" command.
- cruise further down the line to another character
- hit the "." repea
On 1/14/21 4:01 PM, txm wrote:
On 1/14/21 9:58 PM, Chet Ramey wrote:
On 1/11/21 11:00 AM, Thomas Mellman wrote:
But here's a bug for you, in readline:
- edit a line
- go to some character
- replace that character with another, using the "r" command.
- cruise further down the line to anothe
On 1/11/21 11:00 AM, Thomas Mellman wrote:
But here's a bug for you, in readline:
- edit a line
- go to some character
- replace that character with another, using the "r" command.
- cruise further down the line to another character
- hit the "." repeat command
The replace operation will n
On 1/13/21 6:00 PM, bug-bash-requ...@gnu.org wrote:
and then (inevitably)
simply reports an error, because its such files aren't executable.
But it is not inevitable. Using 'cp' as an example. Assuming
you have /usr/bin in your PATH, but ~/bin is in your PATH before
/us
On 1/10/21 6:00 PM, bug-bash-requ...@gnu.org wrote:
Message: 3
Date: Sun, 10 Jan 2021 16:49:50 +0100
From: Ángel
To: bug-bash@gnu.org
Subject: Re: non-executable files in $PATH cause errors
Message-ID:
<94646752576f053515ac2ba4656fe0c895f348ce.ca...@16bits.net>
Content-Type: text/plain; c
On 1/10/21 6:00 PM, bug-bash-requ...@gnu.org wrote:
Message: 3
Date: Sun, 10 Jan 2021 16:49:50 +0100
From: Ángel
To: bug-bash@gnu.org
Subject: Re: non-executable files in $PATH cause errors
Message-ID:
<94646752576f053515ac2ba4656fe0c895f348ce.ca...@16bits.net>
Content-Type
Date:Sun, 11 Oct 2020 16:26:58 +0700
From:Budi
Message-ID:
| set -n not work as its supposed job to check validity of a command
That is not what it does. When -n is set, commands are not executed,
simply parsed.
| $ set -n 'echo HI' &&echo Y
| Y
What that
set -n not work as its supposed job to check validity of a command
using Bash command inside a script ?
for echo command checking
$ set -n 'echo HI' &&echo Y
Y
$ set -n 'eco HI' &&echo Y
Y
won't do the check, how to solve ?
On 10/10/20, bug-bash-requ..
On 2019/10/24 10:47:52 -0400, Greg Wooledge wrote:
> On Thu, Oct 24, 2019 at 09:01:07AM +0200, francis.montag...@inria.fr wrote:
> > When logged on a machine with ssh, executing a simple command CMD1
> > that spawn a "/bin/bash -c some other command" do not source
> > ~/.bashrc: normal behavi
On Sat, May 25, 2019 at 02:56:43PM -0400, Richard Marmorstein wrote:
> There was discussion on Twitter today
> (https://twitter.com/PttPrgrmmr/status/1132351142938185728) about how the
> Bash manual appears to not be indexable by search engines.
>
> https://www.gnu.org/software/bash/manual/bashref
There was discussion on Twitter today
(https://twitter.com/PttPrgrmmr/status/1132351142938185728) about how the
Bash manual appears to not be indexable by search engines.
https://www.gnu.org/software/bash/manual/bashref.html
redirects to
https://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash.
On Mon, Mar 11, 2019 at 02:26:20PM -0700, L A Walsh wrote:
> How would that break compatibility?
The same way shellshock did. A function exported by a parent bash
process using format A could not be read by a child bash process expecting
format B.
Now, you may be thinking, "This makes no sense!
On 3/11/19 4:15 PM, L A Walsh wrote:
>
>
> On 3/6/2019 7:18 AM, Chet Ramey wrote:
>>> Except that the bash debugger gets lost on files that don't
>>> have a real source file name. Environment is not the name of the file
>>> containing the function -- it is a nebulous, ephemeral area of a
>>>
On 3/11/2019 1:34 PM, Greg Wooledge wrote:
> It's not documented so much as blatantly obvious by looking at how it's
> implemented.
>
---
Undocumented features are subject to change at will. Those are called
'internals'. How they are implemented is not necessarily pertinent to
what documen
On Mon, Mar 11, 2019 at 01:15:16PM -0700, L A Walsh wrote:
> 1) Where is it documented that if you export a function, the original
> source location is thrown away by bash?
It's not documented so much as blatantly obvious by looking at how it's
implemented.
wooledg:~$ export -f title
wooledg:~$
On 3/6/2019 7:18 AM, Chet Ramey wrote:
>> Except that the bash debugger gets lost on files that don't
>> have a real source file name. Environment is not the name of the file
>> containing the function -- it is a nebulous, ephemeral area of a
>> process -- but it certainly is not the reposi
t;
> > > Disabling patch bash50-001 solves this problem but cause
> > > other problems. It seems as seen by strace and ltrace that
> > > the bash with patch bash50-001 now makes a stat(2) on every
> > > single part of the path and run onto EACCES erro
On 3/5/19 12:13 AM, L A Walsh wrote:
>> OK, doing that doesn't reveal any problem. If you add
>> shopt -s extdebug; declare -F addnums
>> to prog.sh, it prints
>>
>> addnums 0 environment
>>
> That it prints 'environment' and '0' are issues as the manpage says:
>
>the -F option to dec
On 3/4/2019 4:53 PM, Chet Ramey wrote:
> On 3/4/19 6:44 PM, L A Walsh wrote:
>
>
>>> What does `trace' mean here?
>>>
>> ---
>> from the manpage:
>> "output generated when set -x is enabled"
>>
>
> OK. We've only been talking about function tracing to this point. There
> are
On 3/4/19 6:44 PM, L A Walsh wrote:
>> What does `trace' mean here?
> ---
> from the manpage:
> "output generated when set -x is enabled"
OK. We've only been talking about function tracing to this point. There
are several uses for the word, depending on context.
> FWIW, the other day, I a
On 3/4/2019 6:16 AM, Chet Ramey wrote:
> On 3/3/19 9:53 PM, L A Walsh wrote:
>
>> In bash 4.4.12, if I have some 'library' like functions that I
>> read in at login time, and then later call them -- under trace
>> or under bashdb, no source is shown, as bashdb (and for trace, bash)
>> doesn't
On Sun, Mar 3, 2019 at 9:56 PM L A Walsh wrote:
> The first I will call 'lib.sh' that is sourced from my
> /etc/profile
[snip]
> declare -fxr addnums
[snip]
> ---'prog.sh'---
> #!/bin/bash
> # prog: calls addnums on each line read from stdin
> while read ln; do
> addnums $ln
> done
> ---
On 3/3/19 9:53 PM, L A Walsh wrote:
> In bash 4.4.12, if I have some 'library' like functions that I
> read in at login time, and then later call them -- under trace
> or under bashdb, no source is shown, as bashdb (and for trace, bash)
> doesn't seem to be able to retrieve the original source file
In bash 4.4.12, if I have some 'library' like functions that I
read in at login time, and then later call them -- under trace
or under bashdb, no source is shown, as bashdb (and for trace, bash)
doesn't seem to be able to retrieve the original source file name and
line number where the function was
On 2/14/19 4:20 PM, rugk wrote:
> Hi,
> regarding the paste security issues (pastejacking) [1] there is one last
> thing that shall be done to make it possible for terminal emulators to
> enable a secure shell by default: Enable bracket pasting mode in bash, by
> default.
That's a good reason to t
Hi,
regarding the paste security issues (pastejacking) [1] there is one last
thing that shall be done to make it possible for terminal emulators to
enable a secure shell by default: Enable bracket pasting mode in bash,
by default.
For details, see https://gitlab.gnome.org/GNOME/vte/issues/92,
On 1/21/19 4:46 PM, Martijn Dekker wrote:
> So I think SRANDOM is the best name (or SECURE_RANDOM, though that is a
> bit long).
I'm OK with SRANDOM.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU
On January 20, 2019 2:39:45 PM UTC, Martijn Dekker wrote:
>filename_suffix() {
> chars=ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789
>length=${#chars}
>for ((i=0; i<10; i++)) do
>printf '%s' "${chars:$(( SECURE_RANDOM % length + 1 )):1}"
>done
>}
The char
Op 21-01-19 om 20:12 schreef Chet Ramey:
> On 1/20/19 9:04 PM, Rawiri Blundell wrote:
>> For what it's worth I did consider suggesting URANDOM, however I
>> figured some users may confuse it like this:
>>
>> RANDOM -> /dev/random
>> URANDOM -> /dev/urandom
>>
>> Couple that with an established base
On 1/20/19 9:04 PM, Rawiri Blundell wrote:
> On Mon, Jan 21, 2019 at 10:54 AM Chet Ramey wrote:
>>
>> On 1/20/19 7:52 AM, Rawiri Blundell wrote:
>>
>>> So it might be a case of restricting the usability of this change to
>>> newer kernels that have dedicated calls like getrandom() or
>>> getentrop
Date:Mon, 21 Jan 2019 09:43:17 -0500
From:Chet Ramey
Message-ID: <94f6225c-8de2-cd3d-c83e-0d061c8b0...@case.edu>
| Take the linux mktemp, add the -c option,
Please don't, or at least not the -c option (I don't care if mktemp
is made into a builtin, seems unnecessar
On 1/21/19 8:48 AM, Greg Wooledge wrote:
> On Sun, Jan 20, 2019 at 03:39:45PM +0100, Martijn Dekker wrote:
>> E.g. to create a random character string for a temporary
>> file name, you could do
>>
>> filename_suffix() {
>> chars=ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789
>>
On Sun, Jan 20, 2019 at 03:39:45PM +0100, Martijn Dekker wrote:
> E.g. to create a random character string for a temporary
> file name, you could do
>
> filename_suffix() {
> chars=ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789
> length=${#chars}
> for ((i=0; i<10; i++)
On Mon, Jan 21, 2019 at 10:54 AM Chet Ramey wrote:
>
> On 1/20/19 7:52 AM, Rawiri Blundell wrote:
>
> > So it might be a case of restricting the usability of this change to
> > newer kernels that have dedicated calls like getrandom() or
> > getentropy(), and having to handle detecting/selecting th
On 1/20/19 8:07 PM, Rawiri Blundell wrote:
> */snip*
>
> So it looks like problem solved?
There never was a problem.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tisww
On Mon, Jan 21, 2019 at 1:36 PM Eduardo A. Bustamante López
wrote:
>
> On Sun, Jan 20, 2019 at 05:22:12PM -0500, Chet Ramey wrote:
> > On 1/20/19 4:54 PM, Chet Ramey wrote:
> >
> > >> As an aside, I can confirm the findings of a performance difference
> > >> between 4.4 and 5.0 when running the sc
On Sun, Jan 20, 2019 at 05:22:12PM -0500, Chet Ramey wrote:
> On 1/20/19 4:54 PM, Chet Ramey wrote:
>
> >> As an aside, I can confirm the findings of a performance difference
> >> between 4.4 and 5.0 when running the script provided earlier in the
> >> discussion. At first glance it seems to be du
On 1/20/19 4:54 PM, Chet Ramey wrote:
>> As an aside, I can confirm the findings of a performance difference
>> between 4.4 and 5.0 when running the script provided earlier in the
>> discussion. At first glance it seems to be due to the switch from the
>> old LCG to the current MINSTD RNG,
>
> T
On 1/20/19 7:52 AM, Rawiri Blundell wrote:
> So it might be a case of restricting the usability of this change to
> newer kernels that have dedicated calls like getrandom() or
> getentropy(), and having to handle detecting/selecting those?
>
> So if this is an exercise that you're happy to entert
Op 19-01-19 om 23:10 schreef Chet Ramey:
> On 1/19/19 2:45 PM, Martijn Dekker wrote:
>> Op 16-01-19 om 02:21 schreef Quentin:
>>> If you really need some quality CSPRNG values, I'd suggest adding a
>>> $SECURE_RANDOM variable that just reads from /dev/urandom.
>>
>> IMHO, this would clearly be the
> OK, this is a reasonable approach. Since /dev/urandom just generates
> random bytes, there's a lot of flexibility and we're not subject to
> any kind of backwards compatibility constraints, especially not the
> 16-bit limit. What do you think would be the best way to present that
> to a user? As
On 1/19/19 2:45 PM, Martijn Dekker wrote:
> Op 16-01-19 om 02:21 schreef Quentin:
>> If you really need some quality CSPRNG values, I'd suggest adding a
>> $SECURE_RANDOM variable that just reads from /dev/urandom.
>
> IMHO, this would clearly be the correct approach. I don't know of any
> 21st ce
Op 16-01-19 om 02:21 schreef Quentin:
> If you really need some quality CSPRNG values, I'd suggest adding a
> $SECURE_RANDOM variable that just reads from /dev/urandom.
IMHO, this would clearly be the correct approach. I don't know of any
21st century Unix or Unix-like system that doesn't have /de
Hello there,
I've reviewed both patches and found some things that should be either
greatly improved, or buried some place very deep. :-p
On 2019-01-07 08:15, Ole Tange wrote:
On Mon, Jan 7, 2019 at 12:08 AM Chet Ramey wrote:
On 1/5/19 3:12 PM, Eduardo A. Bustamante López wrote:
> On Fri,
On Thu, Nov 29, 2018 at 08:52:58AM -0800, Chet Ramey wrote:
> On 11/29/18 7:09 AM, Dr. Werner Fink wrote:
> > On Tue, Nov 27, 2018 at 01:24:38PM -0500, Chet Ramey wrote:
> >> The second beta release of bash-5.0 is now available with the URL
> >>
> >> ftp://ftp.cwru.edu/pub/bash/bash-5.0-beta2.tar.g
On 11/29/18 7:09 AM, Dr. Werner Fink wrote:
> On Tue, Nov 27, 2018 at 01:24:38PM -0500, Chet Ramey wrote:
>> The second beta release of bash-5.0 is now available with the URL
>>
>> ftp://ftp.cwru.edu/pub/bash/bash-5.0-beta2.tar.gz
>>
> I see this
>
> [ 2709s] seq.c: In function 'long_double_format
On Tue, Nov 27, 2018 at 01:24:38PM -0500, Chet Ramey wrote:
> The second beta release of bash-5.0 is now available with the URL
>
> ftp://ftp.cwru.edu/pub/bash/bash-5.0-beta2.tar.gz
>
I see this
[ 2709s] seq.c: In function 'long_double_format':
[ 2709s] seq.c:166:9: error: expected ';' before 'r
On Mon, Sep 24, 2018 at 01:52:54PM -0400, Chet Ramey wrote:
> On 9/24/18 1:50 PM, Eduardo Bustamante wrote:
> > On Mon, Sep 24, 2018 at 4:09 AM Dr. Werner Fink wrote:
> > (...)
> >> Reconstructed the attached patch ... seems to work
> >
> > Out of curiosity, what problem are you trying to solve?
On 9/24/18 1:50 PM, Eduardo Bustamante wrote:
> On Mon, Sep 24, 2018 at 4:09 AM Dr. Werner Fink wrote:
> (...)
>> Reconstructed the attached patch ... seems to work
>
> Out of curiosity, what problem are you trying to solve?
https://bugzilla.novell.com/show_bug.cgi?id=1107430
--
``The lyf so
On Mon, Sep 24, 2018 at 4:09 AM Dr. Werner Fink wrote:
(...)
> Reconstructed the attached patch ... seems to work
Out of curiosity, what problem are you trying to solve?
On Fri, Sep 21, 2018 at 01:11:38PM +0200, Dr. Werner Fink wrote:
> Hi,
>
> with 4.3.48 the line
>
> T="";echo ">${T//*/ }<"
>
> leads to
>
> ><
>
> but with 4.4.23 the correct result is given back
>
> > <
>
> in the git repro I do not find any useful login entry for this
Reconstructed
-rwxr-xr-x 1 nolan nolan 130 Feb 7 02:39 myHello
-rw--- 1 nolan nolan 12288 Feb 7 02:39 .myHello.swp
-rw-r--r-- 1 nolan nolan74 Jan 29 13:14 test8
-rw-r--r-- 1 nolan nolan 275 Feb 7 02:20 testFile
-rwxr-xr-x 1 nolan nolan 144 Feb 7 02:33 varassign
nolan@databank:~/bash$ exit
root@dat
36
> -rw-r--r-- 1 nolan nolan 7 Feb 8 01:25 ls.sh
> -rwxr-xr-x 1 nolan nolan 156 Feb 7 02:10 myCopy
> -rwxr-xr-x 1 nolan nolan 130 Feb 7 02:39 myHello
> -rw--- 1 nolan nolan 12288 Feb 7 02:39 .myHello.swp
> -rw-r--r-- 1 nolan nolan74 Jan 29 13:14 test8
> -r
On Thu, Feb 8, 2018 at 4:23 PM, Nolan <4030...@gmail.com> wrote:
> I have found a 'result' of a command that cannot be a feature.
>
> Enter command, command executes, prints exit at the prompt.
>
> Goes to next line in terminal showing the "#" prompt.
>
> A "whoami" says root.
>
> Is this known?
>
I have found a 'result' of a command that cannot be a feature.
Enter command, command executes, prints exit at the prompt.
Goes to next line in terminal showing the "#" prompt.
A "whoami" says root.
Is this known?
Do you need screen captures of my terminal session?
Nolan
On 10/05/2017 02:29 PM, Dan Douglas wrote:
> ...
Another band-aid might be to build bash with -fsplit-stack. Hardly
worth mentioning as it doesn't fix anything - you just run out of memory
instead of overflowing a fixed-size stack, should someone actually want
that for some reason.
signature.as
On 09/25/2017 01:38 PM, Eric Blake wrote:
> On 09/24/2017 12:53 PM, Shlomi Fish wrote:
>
>>
>> I see. Well, the general wisdom is that a program should not ever segfault,
>> but
>> instead gracefully handle the error and exit.
>
> This is possible by installing a SIGSEGV handler that is able to
Hi all,
On Mon, 25 Sep 2017 13:38:01 -0500
Eric Blake wrote:
> On 09/24/2017 12:53 PM, Shlomi Fish wrote:
>
> >
> > I see. Well, the general wisdom is that a program should not ever segfault,
> > but instead gracefully handle the error and exit.
>
> This is possible by installing a SIGSEGV
On 09/24/2017 12:53 PM, Shlomi Fish wrote:
>
> I see. Well, the general wisdom is that a program should not ever segfault,
> but
> instead gracefully handle the error and exit.
This is possible by installing a SIGSEGV handler that is able to
gracefully exit the program when stack overflow is de
On Sun, Sep 24, 2017 at 08:53:46PM +0300, Shlomi Fish wrote:
> I see. Well, the general wisdom is that a program should not ever segfault,
> but
> instead gracefully handle the error and exit.
This only applies to applications, not to tools that let YOU write
applications.
I can write a trivial
On 9/24/17 1:53 PM, Shlomi Fish wrote:
> I see. Well, the general wisdom is that a program should not ever segfault,
> but
> instead gracefully handle the error and exit. Perhaps implement a maximal
> recursion depth like zsh does.
Perhaps read the documentation about the FUNCNEST variable. You
n depth like zsh does. Also see the first item at
https://www.joelonsoftware.com/2007/02/19/seven-steps-to-remarkable-customer-service/
about permanently fixing reported problems at their core instead of dealing
with user reports and requests time and again.
Regards,
Shlomi
> see
On 9/24/17 9:25 AM, Shlomi Fish wrote:
> Hi all,
>
> With bash git master on Mageia v7 x86-64, bash on Debian Stable and other
> reported sytems:
>
> shlomif@telaviv1:~$ /home/shlomif/apps/bash/bin/bash -c 'run() { run; } ; run'
> Segmentation fault (core dumped)
> shlomif@telaviv1:~$
>
> note
tion fault (core dumped)
> shlomif@telaviv1:~$
>
This, or some, variant has been reported multiple times.
Like in most programming languages, you can easily write programs that
behave badly,
in this case you are exhausting the stack has there is no tail call
optimization.
see for instance
https://
Hi all,
With bash git master on Mageia v7 x86-64, bash on Debian Stable and other
reported sytems:
shlomif@telaviv1:~$ /home/shlomif/apps/bash/bin/bash -c 'run() { run; } ; run'
Segmentation fault (core dumped)
shlomif@telaviv1:~$
note that this is not a fork bomb as no processes are spawned, a
Hi all,
With bash git master on Mageia v7 x86-64, bash on Debian Stable and other
reported sytems:
shlomif@telaviv1:~$ /home/shlomif/apps/bash/bin/bash -c 'run() { run; } ; run'
Segmentation fault (core dumped)
shlomif@telaviv1:~$
note that this is not a fork bomb as no processes are spawned, a
Dr. Fink,
Have you tried getting rid of the stderr redirect on your find command to
make sure find isn't showing any errors?
If you eliminate most of the inside of your while loop, does it still
hang? For example:
while IFS="|" read link link_dir link_dest; do
echo "$link,$link_dir,$link_de
On Fri, Jan 16, 2015 at 10:46:02AM -0500, Chet Ramey wrote:
> >>
> >> What do ps and gdb tell you about pid 19175 (and the corresponding pid in
> >> the call to waitchld in the other traceback)? Running, terminated, reaped,
> >> other?
> >
> > d136:~ # ps 10942
> > PID TTY STAT TIME
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/16/15 10:32 AM, Dr. Werner Fink wrote:
> On Fri, Jan 16, 2015 at 09:22:36AM -0500, Chet Ramey wrote:
>> On 1/13/15 4:29 AM, Dr. Werner Fink wrote:
>>
> Bash Version: 4.3
> Patch Level: 33
> Release Status: release
>
> Descripti
On Fri, Jan 16, 2015 at 09:22:36AM -0500, Chet Ramey wrote:
> On 1/13/15 4:29 AM, Dr. Werner Fink wrote:
>
> >>> Bash Version: 4.3
> >>> Patch Level: 33
> >>> Release Status: release
> >>>
> >>> Description:
> >>> Named fifo's causing hanging bash scripts like
> >>>
> >>> while IFS
1 - 100 of 199 matches
Mail list logo
