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
digest..."
>
>
> Today's Topics:
>
>1. redirection / process substitution fails to read a file
> descriptor (Mike Peters)
>2. Re: redirection / process substitution fails to read a file
> descriptor (Greg Wooledge)
>3. Re: bug-bash Digest,
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
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
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
On 2024/01/14 13:34:06 -0500, Chet Ramey wrote:
>BASH PATCH REPORT
>=
>
> Bash-Release: 5.2
> Patch-ID: bash52-022
>
> Bug-Reported-by: srobert...@peratonlabs.com
> Bug-Reference-ID:
> Bug-Reference-URL:
> https:
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
Putting aside the effort to implement, it might be important to think on
how the h-data structure will be used by users. For me, the common use case
will be to implement a simple, small "record" like structure to make it
easier to write readable code. Bash will never be able to compete with
Python/
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
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. Users who are using old platforms are most likely
using a "
Hi.
I agree that the bash local variables are less than ideal (dynamic scope vs
local scope). However, we got to use what we have. In that context, using
'main' has lot of value - documentation, declarative, etc.
In my projects, we use "named" main to create reusable code (e.g. date
calculator ca
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 Wooledge
> To:
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
/usr/bin, then try:
"tou
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; charset=
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
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...@gnu.org wrote:
> Send bug-bash mailing l
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
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
On Thu, Mar 07, 2019 at 03:42:49PM +0100, Dr. Werner Fink wrote:
> On Mon, Mar 04, 2019 at 09:00:38AM -0500, Chet Ramey wrote:
> > On 3/4/19 8:19 AM, wer...@suse.de wrote:
> >
> > > Bash Version: 5.0
> > > Patch Level: 2
> > > Release Status: release
> > >
> > > Description:
> > > Since patch b
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
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
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
On 02/09/2018 05:54 AM, Eduardo A. Bustamante López wrote:
On Thu, Feb 08, 2018 at 05:51:06PM -0800, Nolan wrote:
On 02/08/2018 05:04 PM, Eduardo Bustamante wrote:
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.
E
On Thu, Feb 08, 2018 at 05:51:06PM -0800, Nolan wrote:
> On 02/08/2018 05:04 PM, Eduardo Bustamante wrote:
> > 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 e
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?
>
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
Hi all,
On Sun, 24 Sep 2017 19:24:10 +0300
Pierre Gaston wrote:
> On Sun, Sep 24, 2017 at 5:01 PM, 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/bas
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
On Sun, Sep 24, 2017 at 5:01 PM, 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
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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="|" read a b c ; do
>>>
On Mon, Jan 12, 2015 at 11:50:56AM -0500, Chet Ramey wrote:
> On 1/12/15 9:55 AM, wer...@linux-8jdz.site wrote:
> > Configuration Information [Automatically generated, do not change]:
> > Machine: x86_64
> > OS: linux-gnu
> > Compiler: gcc -I/home/abuild/rpmbuild/BUILD/bash-4.3
> > -L/home/abuild/
bug-bash-requ...@gnu.org 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 message with subject or body 'help' to
> bug-bash-
On Sat, Jul 13, 2013 at 02:52:07AM -0700, Linda Walsh wrote:
> Not even putting an underscore in front or back of it. 'path' is a
> not an uncommon name for shell scripts to use.
>
> Also, I assume you know that suse scripts export COLUMNS in places
> like /etc/profile, /etc/csh.login and /etc/k
On 3/16/12, Chet Ramey wrote:
> On 3/14/12 2:14 PM, Somchai Smythe wrote:
>> Hello,
>>
>> I am reporting a problem with performance, not correctness.
>>
>> While preparing some examples for a course lecture where I code the
>> same algorithm in many languages to compare languages, I ran some code
On 3/14/12 2:14 PM, Somchai Smythe wrote:
> Hello,
>
> I am reporting a problem with performance, not correctness.
>
> While preparing some examples for a course lecture where I code the
> same algorithm in many languages to compare languages, I ran some code
> and while it was reasonably quick
On 3/14/12 2:14 PM, Somchai Smythe wrote:
> Hello,
>
> I am reporting a problem with performance, not correctness.
>
> While preparing some examples for a course lecture where I code the
> same algorithm in many languages to compare languages, I ran some code
> and while it was reasonably quick
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/23/12 2:50 AM, Dan Douglas wrote:
> Hello, In the case of exported functions, Bash interprets a copy descriptor
> followed by an expansion as the >& synonym for &>, resulting in the output
> going to a file named as the value of the FD it's give
On 3/11/11 1:45 AM, Ingo Molnar wrote:
>
> * Chet Ramey wrote:
>
>>> So the above trace is one that my patch would have handled correctly
>>> (since it has no EINTR). Maybe a combination of the two approaches
>>> would work even better?
>>
>> I installed what is essentially the union of your cha
1 - 100 of 163 matches
Mail list logo
