bug-bash
[Top][All Lists]
Advanced

[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 <address@hidden> wrote:
>
> On Thu, Apr 11, 2019, 4:45 AM Chet Ramey <address@hidden> wrote:
>>
>> On 4/10/19 4:33 PM, konsolebox wrote:
>> > On Wed, Apr 10, 2019 at 11:15 PM Chet Ramey <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]