On 7/23/25 9:41 AM, Dr. Werner Fink wrote:
On 2025/07/23 09:38:41 -0400, Chet Ramey wrote:
On 7/23/25 9:34 AM, Dr. Werner Fink wrote:
Correct configured it seems to work
abuild@noether:/mnt> LD_PRELOAD=/usr/lib64/libuid_wrapper.so ./bash
Segmentation fault (core dumped)
LD_PREL
On 2025/07/23 09:38:41 -0400, Chet Ramey wrote:
> On 7/23/25 9:34 AM, Dr. Werner Fink wrote:
>
> > Correct configured it seems to work
> >
> > abuild@noether:/mnt> LD_PRELOAD=/usr/lib64/libuid_wrapper.so ./bash
> > Segmentation fault (core dumped)
> > LD_PRELOAD=/usr/lib64/libuid_wra
On 7/23/25 9:34 AM, Dr. Werner Fink wrote:
Correct configured it seems to work
abuild@noether:/mnt> LD_PRELOAD=/usr/lib64/libuid_wrapper.so ./bash
Segmentation fault (core dumped)
LD_PRELOAD=/usr/lib64/libuid_wrapper.so ./bash
abuild@noether:/mnt> UID_WRAPPER=1 UID_WRAPPER_ROOT=1
On 2025/07/23 09:24:09 -0400, Chet Ramey wrote:
> On 7/23/25 9:06 AM, Dr. Werner Fink wrote:
> > On 2025/07/23 14:53:23 +0200, Dr. Werner Fink wrote:
> > >
> > > The problem is the LD_PRELOAD use in the libssh test suite
> > >
> > > with HAVE_SETRESUID and HAVE_SETRESGID enabled the call
> > >
>
On 7/23/25 9:06 AM, Dr. Werner Fink wrote:
On 2025/07/23 14:53:23 +0200, Dr. Werner Fink wrote:
The problem is the LD_PRELOAD use in the libssh test suite
with HAVE_SETRESUID and HAVE_SETRESGID enabled the call
LD_PRELOAD=/usr/lib64/libsocket_wrapper.so:/usr/lib64/libnss_wrapper.so:/usr/lib64
On 7/23/25 3:18 AM, Dr. Werner Fink wrote:
307827 futex(0x7ff1d2806158, FUTEX_WAKE_PRIVATE, 2147483647) = 0
307827 getresuid([399], [399], [399]) = 0
307827 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=NULL} ---
307827 +++ killed by SIGSEGV +++
This is just a function to get a
On 2025/07/23 14:53:23 +0200, Dr. Werner Fink wrote:
>
> The problem is the LD_PRELOAD use in the libssh test suite
>
> with HAVE_SETRESUID and HAVE_SETRESGID enabled the call
>
> LD_PRELOAD=/usr/lib64/libsocket_wrapper.so:/usr/lib64/libnss_wrapper.so:/usr/lib64/libuid_wrapper.so:/usr/lib64/libp
On 2025/07/23 09:18:45 +0200, Dr. Werner Fink wrote:
>
> Starting sshd with bash-5.3 leads to
>
> 307827 execve("/bin/sh", ["sh", "-c", "--",
> "KRB5CCNAME=/tmp/test_socket_wrapper_EElgbB/gss/cc
> KRB5_CONFIG=/tmp/test_socket_wrapper_EElgbB/gss/k/krb5.conf
> KRB5_KDC_PROFILE=/tmp/test_socket_w
On 2025/07/23 08:42:54 +0200, Dr. Werner Fink wrote:
> On 2025/07/22 10:07:41 -0400, Chet Ramey wrote:
> > On 7/22/25 10:04 AM, Dr. Werner Fink wrote:
> > > On 2025/07/22 09:55:38 -0400, Chet Ramey wrote:
> > > > On 7/22/25 9:47 AM, Dr. Werner Fink wrote:
> > > > > On 2025/07/22 09:10:05 -0400, Che
On 2025/07/22 10:07:41 -0400, Chet Ramey wrote:
> On 7/22/25 10:04 AM, Dr. Werner Fink wrote:
> > On 2025/07/22 09:55:38 -0400, Chet Ramey wrote:
> > > On 7/22/25 9:47 AM, Dr. Werner Fink wrote:
> > > > On 2025/07/22 09:10:05 -0400, Chet Ramey wrote:
> > > > > On 7/22/25 8:12 AM, Dr. Werner Fink wr
als. */
-// set_signal_async_ignored (SIGINT);
+ set_signal_async_ignored (SIGINT);
get_original_signal (SIGQUIT);
set_signal_handler (SIGQUIT, SIG_IGN);
The rationale for those additions is in
https://lists.gnu.org/archive/html/bug-bash/2023-01/msg00050.html
They came in in January, 2023, af
On 7/22/25 10:04 AM, Dr. Werner Fink wrote:
On 2025/07/22 09:55:38 -0400, Chet Ramey wrote:
On 7/22/25 9:47 AM, Dr. Werner Fink wrote:
On 2025/07/22 09:10:05 -0400, Chet Ramey wrote:
On 7/22/25 8:12 AM, Dr. Werner Fink wrote:
On 2025/07/22 13:15:38 +0200, Dr. Werner Fink wrote:
[...]
found a
On 2025/07/22 09:55:38 -0400, Chet Ramey wrote:
> On 7/22/25 9:47 AM, Dr. Werner Fink wrote:
> > On 2025/07/22 09:10:05 -0400, Chet Ramey wrote:
> > > On 7/22/25 8:12 AM, Dr. Werner Fink wrote:
> > > > On 2025/07/22 13:15:38 +0200, Dr. Werner Fink wrote:
> > > > [...]
> > > >
> > > > found a not e
On 7/22/25 9:47 AM, Dr. Werner Fink wrote:
On 2025/07/22 09:10:05 -0400, Chet Ramey wrote:
On 7/22/25 8:12 AM, Dr. Werner Fink wrote:
On 2025/07/22 13:15:38 +0200, Dr. Werner Fink wrote:
[...]
found a not expanded m4 autoconf macro GL_MDA_DEFINES in m4/fcntl-o.m4
Good catch. What happens if
On 2025/07/22 09:10:05 -0400, Chet Ramey wrote:
> On 7/22/25 8:12 AM, Dr. Werner Fink wrote:
> > On 2025/07/22 13:15:38 +0200, Dr. Werner Fink wrote:
> > [...]
> >
> > found a not expanded m4 autoconf macro GL_MDA_DEFINES in m4/fcntl-o.m4
>
> Good catch. What happens if you take that macro out an
On 7/22/25 8:12 AM, Dr. Werner Fink wrote:
On 2025/07/22 13:15:38 +0200, Dr. Werner Fink wrote:
[...]
found a not expanded m4 autoconf macro GL_MDA_DEFINES in m4/fcntl-o.m4
and hence in the final configure script which leads to
When I take out that macro, it doesn't change the resulting config
On 7/22/25 8:12 AM, Dr. Werner Fink wrote:
On 2025/07/22 13:15:38 +0200, Dr. Werner Fink wrote:
[...]
found a not expanded m4 autoconf macro GL_MDA_DEFINES in m4/fcntl-o.m4
Good catch. What happens if you take that macro out and re-run autoconf
and configure?
--
``The lyf so short, the craft
On 7/22/25 4:57 AM, Dr. Werner Fink wrote:
One line cause this behaviour change:
---
/abuild/oscbuild/openSUSE_Tumbleweed/home/abuild/rpmbuild/BUILD/bash-5.3.0-build/bash-5.3/execute_cmd.c
2025-07-22 10:52:15.705599240 +0200
+++ bash-5.3/execute_cmd.c 2025-06-05 17:02:01.0 +0
On 2025/07/22 13:15:38 +0200, Dr. Werner Fink wrote:
[...]
found a not expanded m4 autoconf macro GL_MDA_DEFINES in m4/fcntl-o.m4
and hence in the final configure script which leads to
osc bl openSUSE_Tumbleweed x86_64 | grep fcntl
[ 19s] checking for working fcntl.h... no
[ 22s] checking
On 2025/07/22 10:33:41 +0100, Sam James wrote:
> "Dr. Werner Fink" writes:
>
> > On 2025/07/22 09:08:38 +0200, wer...@suse.de wrote:
> >> Configuration Information [Automatically generated, do not change]:
> >> Machine: x86_64
> >> OS: linux-gnu
> >> Compiler: gcc
> >> Compilation CFLAGS: -O2 -Wa
"Dr. Werner Fink" writes:
> On 2025/07/22 09:08:38 +0200, wer...@suse.de wrote:
>> Configuration Information [Automatically generated, do not change]:
>> Machine: x86_64
>> OS: linux-gnu
>> Compiler: gcc
>> Compilation CFLAGS: -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3
>> -fstack-protector-
On 2025/07/22 09:08:38 +0200, wer...@suse.de wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3
> -fstack-protector-strong -funwind-tables -fasynchronou
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?
1 - 100 of 221 matches
Mail list logo
