On 5/2/22 2:36 PM, Jesse Hathaway wrote:
On Mon, May 2, 2022 at 9:53 AM Chet Ramey wrote:
My preference is a portable memfd_create(); I think I could get around
its limitations.
I'm sure you can google with the best of them, but I did come across
this project
which did some work trying to cre
On Mon, May 2, 2022 at 9:53 AM Chet Ramey wrote:
> My preference is a portable memfd_create(); I think I could get around
> its limitations.
I'm sure you can google with the best of them, but I did come across
this project
which did some work trying to create a portable version of memfd_create(),
On 4/28/22 10:39 PM, Ángel wrote:
On 2022-04-25 at 10:40 -0400, Chet Ramey wrote:
Perhaps BASH_COMPAT=5.0 could be extended to handle this.
I think a shopt makes more sense. Forcing heredocs to be files
although something legit to request, is more a caller workaround to
bugs in called programs
On 2022-04-25 at 10:40 -0400, Chet Ramey wrote:
> > > Perhaps BASH_COMPAT=5.0 could be extended to handle this.
> >
> > I think a shopt makes more sense. Forcing heredocs to be files
> > although something legit to request, is more a caller workaround to
> > bugs in called programs.
>
> Shell opt
On 4/28/22 11:26 AM, Alexey wrote:
I promised you more examples, and here they are:
Very common case to build a list of files for further processing:
declare -a FILES
#1
FILES=(); time readarray -t FILES <<<"$(find "$d" -xdev -maxdepth 5
-type f)"
#2
# <<< act as a tmp file (due
Hello.
On 2022-04-28 20:56, Greg Wooledge wrote:
Second, none of your examples work with arbitrary filenames, which may
contain newline characters. The solution to that is to use find
-print0
and to read the NUL-delimited stream in the shell.
I want to assure you (and others) that my point wa
On Thu, Apr 28, 2022 at 07:26:19PM +0400, Alexey via Bug reports for the GNU
Bourne Again SHell wrote:
> Hello.
>
> I promised you more examples, and here they are:
> Very common case to build a list of files for further processing:
> declare -a FILES
> #1
> FILES=(); time readarray -t FILE
On 2022-04-26 01:05, Alexey via Bug reports for the GNU Bourne Again
SHell wrote:
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 explaine
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 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/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; } <<<
On 2022-04-25 01:02, Greg Wooledge wrote:
On Mon, Apr 25, 2022 at 12:26:46AM +0400, Alexey via Bug reports for
the GNU Bourne Again SHell wrote:
My pipe size is 4kb, but...
ulimit -p
8
$ ulimit -a
[...]
pipe size(512 bytes, -p) 8
Always check the units.
I have checked un
On Mon, Apr 25, 2022 at 12:26:46AM +0400, Alexey via Bug reports for the GNU
Bourne Again SHell wrote:
> My pipe size is 4kb, but...
> ulimit -p
> 8
$ ulimit -a
[...]
pipe size(512 bytes, -p) 8
Always check the units.
Thanks for that important context.
Chet Ramey once said:
> One can argue that the concerns on either side (seeking on stdin vs.
> assuming that here-strings will never hit the file system) are assumptions
> that should not be made,
In reality no-one is making such an assumption, neither idea ente
On 2022-04-22 17:51, Sam Liddicott wrote:
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -flto=auto -ffat-lto-objects -flto=auto
-ffat-lto-objects -fstack-protector-strong -Wformat
-Werror=format-security
> On Apr 24, 2022, at 3:41 PM, Oğuz wrote:
>
> 24 Nisan 2022 Pazar tarihinde Ángel yazdı:
>>
>> I think a shopt makes more sense. Forcing heredocs to be files although
>> something legit to request, is more a caller workaround to bugs in
>> called programs.
>>
>
> https://lists.gnu.org/archiv
24 Nisan 2022 Pazar tarihinde Ángel yazdı:
>
> I think a shopt makes more sense. Forcing heredocs to be files although
> something legit to request, is more a caller workaround to bugs in
> called programs.
>
https://lists.gnu.org/archive/html/bug-bash/2020-12/msg00084.html
--
Oğuz
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 think a shopt makes more s
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.
--
vq
Sam Liddicott writes:
> 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
>to temporary files if it's larger.
>
> This causes problems with many p
For the record, here is my bash workaround to convert a heredoc fd into a
tmpfile.
Code golfers - please feel free to simplify it
Just prefix the command with "herefile" and the fd that needs converting to
a file,
e.g.
herefile 3 command ... /dev/fd/3 3<<&'"$2" &&
# run command reading
33 matches
Mail list logo
