On Mon, 25 Apr 2022, 22:03 Chet Ramey, wrote:
> On 4/22/22 9:51 AM, Sam Liddicott wrote:
>
> > Please could we at least have a shopt to maintain the old
> behaviour?
>
> Let's start with making it part of BASH_COMPAT=50.
>
Thanks- that's great.
Sam
> --
> ``The lyf so short, the craf
On 2022-04-26 00:54, Chet Ramey wrote:
On 4/25/22 4:33 PM, Alexey wrote:
My key point that we have two choices for future:
- make read from pipe faster, or
You mean the read builtin, right? I already explained those semantics.
- provide options for force here-string to use temp files.
On 4/22/22 9:51 AM, Sam Liddicott wrote:
Please could we at least have a shopt to maintain the old behaviour?
Let's start with making it part of BASH_COMPAT=50.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Ch
On 4/25/22 4:33 PM, Alexey wrote:
My key point that we have two choices for future:
- make read from pipe faster, or
You mean the read builtin, right? I already explained those semantics.
- provide options for force here-string to use temp files.
Yes, the absolute worst case scenario h
On Apr 26 2022, Alexey via Bug reports for the GNU Bourne Again SHell wrote:
> My key point that we have two choices for future:
> - make read from pipe faster, or
> - provide options for force here-string to use temp files.
>
> I don't see any other options for fast-enough performance.
Don't u
On 2022-04-25 23:55, Chet Ramey wrote:
On 4/25/22 1:03 PM, Alexey wrote:
There is one more problem with pipes — they are extremely slow.
It's not pipes per se -- it's the semantics of the shell `read' builtin
and standard input. Profiling or a system call tracer would have
provided
insight
On Mon, Apr 25, 2022 at 11:43:31PM +0400, Alexey via Bug reports for the GNU
Bourne Again SHell wrote:
> Annex: with reading to buffer there is some problem: if I want to read first
> part to variable and rest of pipe pass to external program... Bash could be
> an additional pipe layer for next pr
On 4/25/22 1:03 PM, Alexey wrote:
There is one more problem with pipes — they are extremely slow.
It's not pipes per se -- it's the semantics of the shell `read' builtin
and standard input. Profiling or a system call tracer would have provided
insight.
The shell is very careful not to `steal
On 2022-04-25 21:03, Alexey wrote:
On 2022-04-25 17:14, Chet Ramey wrote:
On 4/24/22 4:26 PM, Alexey via Bug reports for the GNU Bourne Again
SHell wrote:
My pipe size is 4kb, but...
ulimit -p
8
{ file /proc/self/fd/0; } <<<"$(dd if=/dev/urandom bs=1
count=$((4096*16)))"
/proc/
On 4/25/22 11:22, Chet Ramey wrote:
Thanks for the input.
You're welcome. Whenever you decide what to do about this, could you
please let us know? I'd like coreutils printf to stay compatible with
Bash printf. Thanks.
On 4/25/22 11:03 AM, Paul Eggert wrote:
On 4/11/22 11:52, Chet Ramey wrote:
On 4/9/22 3:31 PM, Paul Eggert wrote:
It sounds like there are three cases.
1. If the `L' modifier is supplied, as an extension (POSIX doesn't allow
length modifiers for the printf utility), use long double. This
On 2022-04-25 13:03, Alexey via Bug reports for the GNU Bourne Again
SHell wrote:
There is one more problem with pipes — they are extremely slow.
Examples:
GNU bash, version 5.1.16(1)-release (x86_64-pc-linux-gnu)
1) Preparation: create two files with ASCII content:
one for to be file
On 2022-04-25 17:14, Chet Ramey wrote:
On 4/24/22 4:26 PM, Alexey via Bug reports for the GNU Bourne Again
SHell wrote:
My pipe size is 4kb, but...
ulimit -p
8
{ file /proc/self/fd/0; } <<<"$(dd if=/dev/urandom bs=1
count=$((4096*16)))"
/proc/self/fd/0: symbolic link to pipe:[14
On 4/11/22 11:52, Chet Ramey wrote:
On 4/9/22 3:31 PM, Paul Eggert wrote:
It sounds like there are three cases.
1. If the `L' modifier is supplied, as an extension (POSIX doesn't allow
length modifiers for the printf utility), use long double. This would
work in both default and posix
On 4/24/22 4:11 PM, Lawrence Velázquez wrote:
Oh yeah, I remember this. Here is Chet's position at the time:
https://lists.gnu.org/archive/html/bug-bash/2020-12/msg00085.html
I ended up changing my initial position and tried to thread the needle with
a hybrid solution:
https://lists.gnu.or
On 4/22/22 9:51 AM, Sam Liddicott wrote:
Bash Version: 5.1
Patch Level: 16
Release Status: release
Description:
Listed in the changes:
c. Here documents and here strings now use pipes for the expanded
document if it's smaller than the pipe buffer size, reverting
On 4/24/22 1:53 PM, Ángel wrote:
On 2022-04-23 at 14:46 -0400, Lawrence Velázquez wrote:
On Fri, Apr 22, 2022, at 9:51 AM, Sam Liddicott wrote:
Fix:
Please could we at least have a shopt to maintain the old
behaviour?
Perhaps BASH_COMPAT=5.0 could be extended to handle this.
I thin
On 4/24/22 4:26 PM, Alexey via Bug reports for the GNU Bourne Again SHell
wrote:
My pipe size is 4kb, but...
ulimit -p
8
{ file /proc/self/fd/0; } <<<"$(dd if=/dev/urandom bs=1
count=$((4096*16)))"
/proc/self/fd/0: symbolic link to pipe:[1427240]
{ file /proc/self/fd/0; } <<<
18 matches
Mail list logo
