[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "here strings" and tmpfiles

From: Greg Wooledge
Subject: Re: "here strings" and tmpfiles
Date: Tue, 19 Mar 2019 09:31:55 -0400
User-agent: NeoMutt/20170113 (1.7.2)

On Tue, Mar 19, 2019 at 09:20:33AM -0400, Daniel Kahn Gillmor wrote:
> 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 temporary file, actually touching the
> >> underlying filesystem:
> >
> > Yes, just like here documents do.  And have always done, in all shells.
> Apologies for being unaware of the history.  It looks like there are a
> handful of possible approaches today that minimize these fixes, which
> may not have been possible on older systems, which i listed upthread.
> And they work on arbitrary file descriptors, not just stdin.
> Do you think that bash should not improve the situation, at least on
> platforms that support these other approaches?

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 already showed how to use a pipeline to send information from a shell
variable to another process's stdin without using a here-string (which
is a bashism that is much less portable than the pipeline, in addition
to being less "safe" in the incredibly narrow niche situation being
described in this thread).

There is simply NO valid reason to write <<<"$secret" in a script, and
thus there is no need to "improve" anything other than the scripts
that are doing that.  Use a pipe instead.

reply via email to

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