[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "here strings" and tmpfiles
From: |
konsolebox |
Subject: |
Re: "here strings" and tmpfiles |
Date: |
Fri, 12 Apr 2019 03:08:28 +0800 |
On Thu, Apr 11, 2019 at 5:31 AM konsolebox <konsolebox@gmail.com> wrote:
>
> On Thu, Apr 11, 2019, 4:45 AM Chet Ramey <chet.ramey@case.edu> wrote:
>>
>> On 4/10/19 4:33 PM, konsolebox wrote:
>> > On Wed, Apr 10, 2019 at 11:15 PM Chet Ramey <chet.ramey@case.edu> wrote:
>> >> If we're going to go off into hypotheticals and speculation, it would be
>> >> nice if memfd_create were available universally.
>> >
>> > I see many parts in lib/* that adapts to available system features
>> > like mmap and MAP_ANONYMOUS. I don't see why memfd_create should be
>> > an exception. Using a volatile file is much better than forking, and
>> > this only requires a one-time implementation of a wrapper library
>> > function that returns -1 if the feature is not available in the
>> > system. It should be easy to integrate with the current code since it
>> > returns an fd.
>>
>> It has slightly inconvenient semantics, in that you can't open it more
>> than once, and if you can't do that, you can't convert it from read-write
>> to readonly.
>
>
> Perhaps it can be reopened via /dev/fd.
Also file sealing maybe. The way it restricts writing is just a
little different.
I just realized that memfd_create has the potential to allow
optimization of capturing output to a variable as well. Rather than
transferring data through pipes, it can simply use a ram-based file.
In some way I think the file's data can be directly accessed and
allocated or assigned to the variable. Maybe with the help of mmap.
It can even introduce a new general set of "String-IO" features to
bash, which is quite an exciting idea. The compromise is to use
temporary files in systems that don't support anonymous RAM-based
files, just like how temporary files are currently used in here docs.
I can think of the following syntaxes for starters:
cmd >>> var # Trailing newlines are kept and no implicit subshell
var=${{echo a}} # No implicit subshell, but trailing newlines are
still trimmed. Not really useful to me.
var >>| cmd # Trailing newlines are kept. Better than <<< if used
with lastpipe, unless bash defaults to no fork unless necessary.
There should be more.
I bet scripters who like doing functional-like abomination in shells
where functions return values through echo or printf would be happy
with it because no more subshells.
--
konsolebox
- Re: "here strings" and tmpfiles, (continued)
- Re: "here strings" and tmpfiles, L A Walsh, 2019/04/09
- Re: "here strings" and tmpfiles, Greg Wooledge, 2019/04/10
- Re: "here strings" and tmpfiles, Greg Wooledge, 2019/04/10
- Re: "here strings" and tmpfiles, Chet Ramey, 2019/04/10
- Re: "here strings" and tmpfiles, konsolebox, 2019/04/10
- Re: "here strings" and tmpfiles, Chet Ramey, 2019/04/10
- Re: "here strings" and tmpfiles, konsolebox, 2019/04/10
- Re: "here strings" and tmpfiles,
konsolebox <=
- Re: "here strings" and tmpfiles, Chet Ramey, 2019/04/12
- Re: "here strings" and tmpfiles, konsolebox, 2019/04/12
- Re: "here strings" and tmpfiles, Chet Ramey, 2019/04/10
- Re: "here strings" and tmpfiles, Jason A. Donenfeld, 2019/04/09
- Re: "here strings" and tmpfiles, Chet Ramey, 2019/04/10
- Re: "here strings" and tmpfiles, Daniel Kahn Gillmor, 2019/04/10
- Re: "here strings" and tmpfiles, Greg Wooledge, 2019/04/10
- Re: "here strings" and tmpfiles, Peter & Kelly Passchier, 2019/04/10
- Re: "here strings" and tmpfiles, Chet Ramey, 2019/04/10
- Re: "here strings" and tmpfiles, Daniel Kahn Gillmor, 2019/04/10