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
On 7/22/25 4:57 AM, Dr. Werner Fink wrote:
Description:
The kill test of util-linux fails with bash 5.3
---
/home/abuild/rpmbuild/BUILD/util-linux-2.41.1-build/util-linux-2.41.1/tests/expected/kill/decode
2025-05-05 08:28:45.049284591 +
+++
/home/abuild/rpmbuild/BUILD/util-lin
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
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?
>
1 - 100 of 185 matches
Mail list logo