On Mon 2019-04-15 17:35:49 -0400, Chet Ramey wrote:
> I'll probably release a patch, yes. In the meantime, distributions are free
> to take the change and apply it to their versions.
Thanks for the followup! I've updated https://bugs.debian.org/920455
with the appropriate details.
--dkg
On Sat 2019-04-13 14:03:22 -0400, Chet Ramey wrote:
> It's an easy change. See the attachment.
Thanks! The attached patch removed a comment and changed an #if 1 to
#if 0, but i think the comment change is just a cleanup reflecting the
previous state of the codebase. Is that right?
> I agree tha
On Fri 2019-04-12 12:05:24 -0400, Chet Ramey wrote:
> But the execs mean that the shell that is eventually invoked to run the
> `wait' is the parent of the process substitution. So the subshell has
> children, whether or not it has run the process substitution itself.
Yes, agreed. This is the sit
Over in the "here strings and tmpfiles" thread, a distraction came up,
which i'm splitting out into a separate thread. Please don't conflate
the two, i'm just looking for further clarity about process
substitutions and the wait builtin.
dkg and chet wrote:
https://bugs.debian.org/920455
>>>
On Thu 2019-04-11 10:04:02 +0200, Andreas Schwab wrote:
> On Apr 10 2019, Daniel Kahn Gillmor wrote:
>
>> data written to the local filesystem can be discovered by someone
>> analyzing the disk controller data path, or by someone with access to
>> the underlying storage
On Wed 2019-04-10 16:16:44 -0400, Chet Ramey wrote:
> Is it just that people have not realized all along that most shells,
> certainly all historical shells, that implement here documents use temp
> files to do it? It's really only the ash-based shells (not an insignificant
> portion of the shells
On Wed 2019-04-10 09:07:27 -0400, Chet Ramey wrote:
> On 4/9/19 2:56 AM, Jason A. Donenfeld wrote:
>> Since originally raising this issue with dkg (leading to this email
>> thread), I've only followed along from a bit of a distance. But it does
>> look like there's been some good progress: there's
On Tue 2019-03-19 09:31:55 -0400, Greg Wooledge wrote:
> There are scripts that *rely* on the seekability of the temporary files
> created by here-documents and here-strings. "Improving" the "situation"
> would break backward compatibility.
i hope you noticed that of my suggested improvements, on
On Tue 2019-03-19 08:25:50 -0400, Greg Wooledge wrote:
> On Mon, Mar 18, 2019 at 05:18:10PM -0400, Daniel Kahn Gillmor wrote:
>> strace -o tmp/bash.herestring.strace -f bash -c 'cat <<<"hello there"'
>> It turns out that this creates a tempora
Thanks for the feedback, Eduardo--
On Mon 2019-03-18 17:40:17 -0700, Eduardo A. Bustamante López wrote:
> I don't think the implementation details of herestrings are documented
> anywhere,
> and I'm not too sure if they should (i.e. IMO if you need that degree of
> control
> over the implementat
On Mon 2019-03-18 17:18:10 -0400, Daniel Kahn Gillmor wrote:
> A few possible options for trying to improve the situation:
>
> a) use socketpair(2) or pipe(2) instead of making a tmpfile. this has
> the potential downside that the semantics of access to the remaining
>
hi bash developers--
I ran the following command to get a sense of how bash deals with here
strings under the hood:
strace -o tmp/bash.herestring.strace -f bash -c 'cat <<<"hello there"'
(i'm testing with bash 5.0-2 on debian testing/unstable).
It turns out that this creates a temporary fil
12 matches
Mail list logo
