Re: $* in here-document

On 4/24/25 11:13 PM, Martijn Dekker wrote: Reproducer: IFS=/ set a b c cat <In any context in which field splitting is not possible, POSIX specifies that $* uses the first character of $IFS as the output field separator. Here-documents are such a context. Thanks for the report. I fixed t

$* in here-document

Reproducer: IFS=/ set a b c cat <In any context in which field splitting is not possible, POSIX specifies that $* uses the first character of $IFS as the output field separator. Here-documents are such a context. I am fixing the same bug in ksh93 right now. Other shells (dash, mksh, y

Re: [sr #111047] Value of BASHPID changes when inside a here-document

On 4/4/24 9:05 PM, Lawrence Velázquez wrote: Reproducing my comment [1] for the list: On Apr 4, 2024, at 5:57 PM, Richard Waite wrote: Does variable expansion for here-documents occur in a subshell? Sometimes. When a command requires forking (roughly speaking), its redirections (not just

Re: [sr #111047] Value of BASHPID changes when inside a here-document

Reproducing my comment [1] for the list: > On Apr 4, 2024, at 5:57 PM, Richard Waite wrote: > > Does variable expansion for here-documents occur in a subshell? Sometimes. When a command requires forking (roughly speaking), its redirections (not just here-documents) are processed

[sr #111047] Value of BASHPID changes when inside a here-document

URL: <https://savannah.gnu.org/support/?111047> Summary: Value of BASHPID changes when inside a here-document Group: The GNU Bourne-Again SHell Submitter: rmwaite Submitted: Thu 04 Apr 2024 09:57:30

Re: $* within a here-document puts space instead of the first IFS char.

On Fri, Feb 16, 2024 at 9:02 PM Damien ISSANCHOU wrote: > When expanding $* within a here-document, bash puts a space between > each positional parameters while I would expect it to put the first > character of the IFS variable (if it contains at least one character) as > per

Re: $* within a here-document puts space instead of the first IFS char.

is also implemented in other | contexts where field splitting shall not be performed such as within | here strings. Note that a here doc without a quoted end word (after <<) is essentially a double quoted string - apart from the " character being nothing special in it, it shoud

$* within a here-document puts space instead of the first IFS char.

From: Damien Issanchou To: bug-bash@gnu.org Subject: $* within a here-document puts space instead of the first IFS char. Configuration Information: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 uname output: Linux AsWhite 4.19.0-20-amd64 #1 SMP Debian 4.19.235-1 (2022

Re: BUG: Here-doc delimiter: unclosed quotes

On 1/18/24 9:16 AM, Dastan Abdygali wrote: Bash Version: 5.2 Patch Level: 0 Release Status: release Description: If unclosed single quotes or unclosed double quotes are used as a delimiter in here-doc, bash lets the user finish the quote on the next lines. As a result

BUG: Here-doc delimiter: unclosed quotes

-darwin19.6.0 Bash Version: 5.2 Patch Level: 0 Release Status: release Description: If unclosed single quotes or unclosed double quotes are used as a delimiter in here-doc, bash lets the user finish the quote on the next lines. As a result delimiter contains \newline character. Which

Re: Newlines resulting from alias expansion are ignored by here-document processing

found > > > > My reading of the upcoming POSIX revision > > (https://www.austingroupbugs.net/view.php?id=953#c4214) > > is that they should be treated just like newline tokens coming from the > > source. > > Thanks for the report. Reading here-documents from aliases is a known &g

Re: Newlines resulting from alias expansion are ignored by here-document processing

On 11/30/23 3:45 AM, gldrk wrote: $ cat test alias 'foo=cat <My reading of the upcoming POSIX revision (https://www.austingroupbugs.net/view.php?id=953#c4214) is that they should be treated just like newline tokens coming from the source. Thanks for the report. Reading here-docume

Re: Newlines resulting from alias expansion are ignored by here-document processing

This patch appears to solve the issue. As far as I can tell, this routine is only used for here-documents. diff --git a/parse.y b/parse.y index 8fd24a1c..4d361af7 100644 --- a/parse.y +++ b/parse.y @@ -2083,6 +2083,8 @@ read_a_line (remove_quoted_newline) static char *line_buffer = (char

Newlines resulting from alias expansion are ignored by here-document processing

$ cat test alias 'foo=cat

Re: "here document" causing failures. Implementation is inconsistent and not documented.

On 10/10/23 8:56 PM, Jim McD wrote: Bug: Trailing white space after the delimiting tag cause the here document to fail with an error like /./: line : warning: here-document at line delimited by end-of-file (wanted `msg_end')Trailing white space/ This is not a bug. Trailing white

Re: "here document" causing failures. Implementation is inconsistent and not documented.

On Wed, Oct 11, 2023 at 11:56:42AM +1100, Jim McD wrote: > Bug: > Trailing white space after the delimiting tag cause the here document to > fail with an error like > /./: line : warning: here-document at line > delimited by end-of-file (wanted `msg_end')Trailing white &g

Re: "here document" causing failures. Implementation is inconsistent and not documented.

On Wed, Oct 11, 2023 at 11:56:42AM +1100, Jim McD wrote: > Bug: > Trailing white space after the delimiting tag cause the here document to > fail with an error like > /./: line : warning: here-document at line > delimited by end-of-file (wanted `msg_end')Trailing white &g

"here document" causing failures. Implementation is inconsistent and not documented.

Bug: Trailing white space after the delimiting tag cause the here document to fail with an error like /./: line : warning: here-document at line delimited by end-of-file (wanted `msg_end')Trailing white space/ Trailing white space after the start of the here statement is ignored.

Re: Document that here strings don't support brace expansion.

Chet Ramey writes: > If they're linked, why wouldn't saying filename generation isn't performed > be enough to imply that brace expansion isn't performed either? Hmm, yes, good point. Dale

Re: Document that here strings don't support brace expansion.

On 3/15/23 12:52 AM, Alex Bochannek wrote: Chet, Thank you for the thoughtful responses. My thoughts below got a bit long, so here is a summary: - The here-string documentation should either spell out that brace expansion is not performed or simple only list the expansions that are

Re: Document that here strings don't support brace expansion.

> can be produced. In those, all the expansions typically happen. > > In the other, exactly one word is required - like the word in var=${word} > or the word in case ${word} in, or (in bash, and perhaps a couple of other > shells) the word after a here string operator <<<${word} (an

Re: Document that here strings don't support brace expansion.

s required - like the word in var=${word} or the word in case ${word} in, or (in bash, and perhaps a couple of other shells) the word after a here string operator <<<${word} (and one more I will come to in a minute). [The word after a here-doc redirect operator (<<) is strange for hys

Re: Document that here strings don't support brace expansion.

thoughts below got a bit > long, so here is a summary: > > - The here-string documentation should either spell out that brace > expansion is not performed or simple only list the expansions that > are. > - The same goes for the documentation for the shell-expand-line Readlin

Re: Document that here strings don't support brace expansion.

Chet, Thank you for the thoughtful responses. My thoughts below got a bit long, so here is a summary: - The here-string documentation should either spell out that brace expansion is not performed or simple only list the expansions that are. - The same goes for the documentation for the shell

Re: Document that here strings don't support brace expansion.

On Tue, Mar 14, 2023, 7:04 PM Chet Ramey wrote: > On 3/14/23 11:23 AM, Dale R. Worley wrote: > > Alex Bochannek writes: > >> "The WORD undergoes tilde expansion, parameter and variable expansion, > >> command substitution, arithmetic expansion, and quote removal. Filename > >> expansion and wor

Re: Document that here strings don't support brace expansion.

On 3/14/23 11:23 AM, Dale R. Worley wrote: Alex Bochannek writes: "The WORD undergoes tilde expansion, parameter and variable expansion, command substitution, arithmetic expansion, and quote removal. Filename expansion and word splitting are not performed." It is missing brace expansion, whic

Re: Document that here strings don't support brace expansion.

Alex Bochannek writes: > "The WORD undergoes tilde expansion, parameter and variable expansion, > command substitution, arithmetic expansion, and quote removal. Filename > expansion and word splitting are not performed." > > It is missing brace expansion, which is not supported: Interesting ...

Re: Document that here strings don't support brace expansion.

On 3/13/23 7:06 PM, Alex Bochannek wrote: I also noticed that there doesn't seem to be an easy way to expand braces with Readline, which I suspect may have to do with where in the parsing process of Bash brace expansion actually happens. Readline is fairly application-agnostic. There is a mec

Re: Document that here strings don't support brace expansion.

Chet Ramey writes: > On 3/11/23 3:39 AM, Alex Bochannek wrote: >> Bash Version: 5.2 >> Patch Level: 15 >> Release Status: release >> Description: >> The documentation for here strings says: >> "The WORD undergoes tilde expansion, parameter and va

Re: Document that here strings don't support brace expansion.

On 3/11/23 3:39 AM, Alex Bochannek wrote: Bash Version: 5.2 Patch Level: 15 Release Status: release Description: The documentation for here strings says: "The WORD undergoes tilde expansion, parameter and variable expansion, command substitution, arithmetic expansion, and quote re

Document that here strings don't support brace expansion.

Bash Version: 5.2 Patch Level: 15 Release Status: release Description: The documentation for here strings says: "The WORD undergoes tilde expansion, parameter and variable expansion, command substitution, arithmetic expansion, and quote removal. Filename expansion and word splitting ar

Re: Subsequent Here Doc/String Never Evaluated in Process Substitution

On 10/28/22 6:37 AM, ad...@nosuck.org wrote: Thank you for the awesome shell.  I noticed the following after upgrading from 5.1.16-3 to 5.2.2-2 on Fedora.  It actually resulted in a minor amount of data loss. Thanks for the report. I believe this was fixed a couple of weeks ago as the result o

Re: Subsequent Here Doc/String Never Evaluated in Process Substitution

ted to insert « printf HERE\\n >&2 » between the assignment and the cat, only to then see HERE\n: command not found.) Indeed, it appears that the command following the "do" always absorbs the first word from the second command, despite the line break between them. This does s

Subsequent Here Doc/String Never Evaluated in Process Substitution

Thank you for the awesome shell. I noticed the following after upgrading from 5.1.16-3 to 5.2.2-2 on Fedora. It actually resulted in a minor amount of data loss. #!/usr/bin/env -S bash -- mapfile -t < <( cat <<- EOF ;FFMETADATA1 EOF while read -r ; do

Re: Parse error of function definition with here doc in command substitution

On 10/16/22 12:45 PM, D630 wrote: Hi, In version `5.2.0(1)-rc2 (x86_64-pc-linux-gnu)` from Debian, this code ``` _=$( f1() {     c <<-!     ! } f2() {     : } ) ``` results in ``` bash: command substitution: line 15: syntax error near unexpected token `(' b

Parse error of function definition with here doc in command substitution

Hi, In version `5.2.0(1)-rc2 (x86_64-pc-linux-gnu)` from Debian, this code ``` _=$( f1() { c <<-! ! } f2() { : } ) ``` results in ``` bash: command substitution: line 15: syntax error near unexpected token `(' b

Re: Command substitution fails in here-document delimiter.

> On Jul 13, 2021, at 4:37 PM, Paul Gilmartin wrote: > > Description: > When "word" in here-document contains command substitution, > bash reports an error: > here: line 4: warning: here-document at line 2 delimited by end-of-file > (wanted `foo$( tru

Command substitution fails in here-document delimiter.

bbug1 Description: Binary data

Re: here strings fold newlines on MacOS

, 2021, 1:35 PM -0500, Chet Ramey , wrote: > On 1/30/21 5:44 PM, Rich Lafferty wrote: > > > Bash Version: 5.1 > > Patch Level: 0 > > Release Status: release > > > > Description: > > Here strings ('<<<') fold newlines into spaces on MacOS, b

Re: here strings fold newlines on MacOS

On 1/30/21 5:44 PM, Rich Lafferty wrote: Bash Version: 5.1 Patch Level: 0 Release Status: release Description: Here strings ('<<<') fold newlines into spaces on MacOS, but not on Linux, leading to incompatibilites in bash code expected to work the same on both platforms. T

Re: here strings fold newlines on MacOS

> On Jan 30, 2021, at 9:28 PM, "" > wrote: > > Are you certain that you're not testing /bin/bash (version 3.2.57) in the > case of macOS? I ask because the bug you describe is said to have been > addressed by the release of 4.4-beta [1]. > > z. Bash

Re: here strings fold newlines on MacOS

:31 PST 2020; root:xnu-4903.278.51~1/RELEASE_X86_64 x86_64 Machine Type: x86_64-apple-darwin18.7.0 Bash Version: 5.1 Patch Level: 0 Release Status: release Description: Here strings ('<<<') fold newlines into spaces on MacOS, but not on Linux, leading to incompatibilites in ba

here strings fold newlines on MacOS

/RELEASE_X86_64 x86_64 Machine Type: x86_64-apple-darwin18.7.0 Bash Version: 5.1 Patch Level: 0 Release Status: release Description: Here strings ('<<<') fold newlines into spaces on MacOS, but not on Linux, leading to incompatibilites in bash code expected to work the same on both pl

Re: Is there a way to force here-documents/strings to use temporary files?

20 Aralık 2020 Pazar tarihinde Chet Ramey yazdı: > > I decided ultimately to make the change for the most common cases, where > the amount of data passed in a here string or here document is small. But > that is simply an implementation detail; the documented semantics of here- >

Re: Is there a way to force here-documents/strings to use temporary files?

On 12/20/20 2:25 AM, Oğuz wrote: So, is there any way to force here-documents to use temporary files no matter how long the expanded document is? If not, it would be nice if compat50 had this effect. There is not. I'm not sure that a compat setting would be appropriate for something th

Is there a way to force here-documents/strings to use temporary files?

Before Bash-5.1 I used to be able to do things like this and get consistent results: $ { grep -x -m1 1; grep -x 2; } <<<`seq 3` 1 2 $ { grep -x -m1 1; grep -x 2; } <<<`seq 3` 1 2 But now, since here-documents use pipes when the expanded document i

Re: Does Bash 5.1 block SIGINT until here-document is ready?

you sure a misplacement of the child is the issue here? Or am I missing something? The issue is whether or not `sleep's process group is the same as the terminal's process group. If it's not, `sleep' will not get keyboard- generated signals. -- ``The lyf so short, the cr

Re: Does Bash 5.1 block SIGINT until here-document is ready?

is the issue here? Or am I missing something? Oğuz On Sat, Dec 12, 2020 at 10:16 PM Chet Ramey wrote: > On 12/12/20 5:54 AM, Oğuz wrote: > > In Bash 5.1, Ctrl-C doesn't interrupt the command below. The only way > out I > > guess is to stop it Ctrl-Z and run `kill %%`, but

Re: Does Bash 5.1 block SIGINT until here-document is ready?

On 12/12/20 5:54 AM, Oğuz wrote: In Bash 5.1, Ctrl-C doesn't interrupt the command below. The only way out I guess is to stop it Ctrl-Z and run `kill %%`, but that's really too much work. cat < It's not a signal blocking problem. It's a combination of an interactive shell and the shell for

Does Bash 5.1 block SIGINT until here-document is ready?

In Bash 5.1, Ctrl-C doesn't interrupt the command below. The only way out I guess is to stop it Ctrl-Z and run `kill %%`, but that's really too much work. cat <

No longer receifing nntp feed from here

Anyone to look why this is no longer connected to the bug-bash@gnu.org ML? -- Lea Gris

Re: Incomplete command substitution in here-document not regarded as an error

On 11/6/19 4:37 PM, Oğuz wrote: cat < Thanks for the report. Bash has, for some years, allowed EOF/EOS to terminate a command substitution in certain circumstances, but this really only shows up when you're expanding it inside a here-document. There is a (relatively cryptic) warning

Incomplete command substitution in here-document not regarded as an error

cat <

Re: '#' in here-doc

On 10/23/19 5:35 PM, Oğuz wrote: > After running this on bash 5.0.9: > > wc -c < # > EOF > > if I hit up arrow key, I get this: > > wc -c < # > > EOF > > (there is an extra blank line). Can't reproduce on bash 4.4.20 though Thanks for the report. I'll take a look. Chet -- ``The lyf so short

'#' in here-doc

After running this on bash 5.0.9: wc -c <

Re: closing '}' misplaced in here-document in function

On 6/29/19 1:44 PM, Denis McKeon wrote: > Bash Version: 5.0 > Patch Level: 7 > Release Status: release > > Description: > >     Bash appears to move the closing '}' >     from after a closing here-document delimiter >     to the start of the here-doc bo

closing '}' misplaced in here-document in function

x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-redhat-linux-gnu Bash Version: 5.0 Patch Level: 7 Release Status: release Description: Bash appears to move the closing '}' from after a closing here-document delimiter to the start of the here-doc body (just after t

Re: "here strings" and tmpfiles

On Fri, Apr 12, 2019 at 10:32 PM Chet Ramey wrote: > > On 4/11/19 3:08 PM, konsolebox wrote: > > >>> 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 c

Re: "here strings" and tmpfiles

On 4/11/19 3:08 PM, konsolebox wrote: >>> 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

Re: "here strings" and tmpfiles

On 4/11/19 3:15 AM, Robert Elz wrote: > (Substitute cat if you're that kind of weirdo!). We're really going to throw down right here? -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocr

Re: "here strings" and tmpfiles

eripheral issue, since the here-document implementation uses a different function that (usually) calls mkstemp. But since this function is used for making non-regular files (named pipes), you pretty much have to use a function that returns a name. If you'd like to take a run at a better imp

Re: "here strings" and tmpfiles

On 4/11/19 12:02 AM, Jason A. Donenfeld wrote: > Hi Chet, Hi. > I hope that can shed light on the motivation a bit. Pass got hit by > this a bit ago: > https://git.zx2c4.com/password-store/commit/?id=367efa5846492e1b0898aad8a2c26ce94163ba24 I note that the pipe-for-small-enough-heredocs works fo

Re: "here strings" and tmpfiles

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 do

Re: "here strings" and tmpfiles

On 4/10/19 7:18 PM, Daniel Kahn Gillmor wrote: > 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

Re: "here strings" and tmpfiles

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 medium. > > Do you have swa

Re: "here strings" and tmpfiles

On Thu, Apr 11, 2019, 10:42 PM Andreas Kusalananda Kähäri < andreas.kah...@abc.se> wrote: > On Thu, Apr 11, 2019 at 09:01:50PM +0800, konsolebox wrote: > > On Thu, Apr 11, 2019, 4:04 PM Andreas Schwab wrote: > > > > > On Apr 10 2019, Daniel Kahn Gillmor wrote: > > > > > > > data written to the l

Re: "here strings" and tmpfiles

On Thu, Apr 11, 2019 at 09:01:50PM +0800, konsolebox wrote: > On Thu, Apr 11, 2019, 4:04 PM 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 some

Re: "here strings" and tmpfiles

On Thu, Apr 11, 2019 at 9:06 PM Greg Wooledge wrote: > So... yes. Because everyone in 2019 has a laptop and therefore has swap > enabled because it's used for hibernation. Sure captain. It was a joke. -- konsolebox

Re: "here strings" and tmpfiles

On Thu, Apr 11, 2019 at 09:01:50PM +0800, konsolebox wrote: > On Thu, Apr 11, 2019, 4:04 PM Andreas Schwab wrote: > > Do you have swap enabled? > > It's 2019. So... yes. Because everyone in 2019 has a laptop and therefore has swap enabled because it's used for hibernation. That was what you me

Re: "here strings" and tmpfiles

On Thu, Apr 11, 2019, 4:04 PM 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 medium. > > Do you have sw

Re: "here strings" and tmpfiles

On Thu, Apr 11, 2019 at 06:02:41AM +0200, Jason A. Donenfeld wrote: > what about internally treating "x < x"? Are these somehow not quite equivalent because x is in a subshell > in one but not the other, or something like that? cmd <<< string opens a temporary file for writing, dumps the string

Re: "here strings" and tmpfiles

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 medium. Do you have swap enabled? Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.

Re: "here strings" and tmpfiles

if you're that kind of weirdo!). Now I want to play tennis.Here boy (girl). Hold onto this racquet and hit the ball back. Oh, you need hands, well, let's see how I can make that happen You're not tall enough to hit my lobs, well, leg ex

Re: "here strings" and tmpfiles

ng onward at context and whatnot to actually see what exactly you're doing; it's possible that you've thought through all this and its particular use is fine somehow. But from a cursory birdseye look, I wonder if there are three CVEs lurking in here (mktemp, random stuff, toctou).

Re: "here strings" and tmpfiles

On Thu, Apr 11, 2019 at 6:02 AM Jason A. Donenfeld wrote: > curious about is - what about internally treating "x <

Re: "here strings" and tmpfiles

Hi Chet, On Wed, Apr 10, 2019 at 3:07 PM Chet Ramey wrote: > This is unnecessary hyperbole. The existing file-based mechanism works > just fine. We're talking about what's essentially an optimization. > [...] > This doesn't make any sense. > [...] > There isn't an "insecure path." I'm a bit late

Re: "here strings" and tmpfiles

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 > port

Re: "here strings" and tmpfiles

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

Re: "here strings" and tmpfiles

On 4/10/19 4:33 PM, konsolebox wrote: > On Wed, Apr 10, 2019 at 11:15 PM Chet Ramey 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

Re: "here strings" and tmpfiles

On 10/4/2019 09:04, Greg Wooledge wrote: > On Wed, Apr 10, 2019 at 11:59:19AM -0400, Daniel Kahn Gillmor wrote: >> If we look at the problem from the perspective of the risk of >> herestring/heredoc content leaking to non-ephemeral storage, > > The content is already in the damned SHELL SCRIPT. >

Re: "here strings" and tmpfiles

On Wed, Apr 10, 2019 at 11:15 PM Chet Ramey 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_c

Re: "here strings" and tmpfiles

On Tue, Apr 9, 2019 at 10:01 PM Jason A. Donenfeld wrote: > A real solution for this issue involves getting rid of the temporary file > all together. Since we're talking about a bash string, it's already in > memory. Why not just fork() if the write() will block? A simple way would be > to always

Re: "here strings" and tmpfiles

ggest there's no risk, but that it's minor. OK, so take a risk management approach. That risk is so minor that it has existed -- and been accepted -- for as long as here documents have existed. That risk I mentioned is not just security-related, though I imagine that's where Jason&#

Re: "here strings" and tmpfiles

On Wed, Apr 10, 2019 at 11:59:19AM -0400, Daniel Kahn Gillmor wrote: > If we look at the problem from the perspective of the risk of > herestring/heredoc content leaking to non-ephemeral storage, The content is already in the damned SHELL SCRIPT. How much more "non-ephemeral" can it get?

Re: "here strings" and tmpfiles

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

Re: "here strings" and tmpfiles

On 4/9/19 12:19 AM, Robert Elz wrote: > Date:Mon, 08 Apr 2019 17:04:41 -0700 > From:L A Walsh > Message-ID: <5cabe199.9030...@tlinx.org> > > | On 4/8/2019 7:10 AM, Chet Ramey wrote: > > | > Pipes are objectively not the same as files. They > | > > | > 1. Do n

Re: "here strings" and tmpfiles

It is perfectly normal for a reader >> to read long after the writer has finished and exited. Try this >> >> printf %s\\n hello | { sleep 5; cat; } >> > === > It may be normal in some cases, but: > > https://superuser.com/questions/554855/how-can-i-f

Re: "here strings" and tmpfiles

On Wed, Apr 10, 2019, 1:09 AM Eli Schwartz wrote: > That being said, it seems like a rather odd place to configure and use a > heavyweight shell merely to allow third parties to include > downstream-specific bashisms. I think there is a great deal of wisdom in > the fact that the referenced issue

Re: "here strings" and tmpfiles

On 4/9/19 10:07 AM, konsolebox wrote: > Perhaps bash can also look at /dev/shm. It's a common tmpfs, but I > haven't checked if it's standard and what utility mounts it. I don't > really use it. Another non-portable feature. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer

Re: "here strings" and tmpfiles

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 now a commit that > fills the pipe up to the OS's maximum

Re: "here strings" and tmpfiles

d of writing to a file system -- whether a pipe, a > here doc/string does that, or explicitly through redirection. Things > could work without requiring the presence of a file system. There is no portable way to turn an arbitrary block of memory into a file descriptor. There are mmap-based appr

Re: "here strings" and tmpfiles

tax is replaced by the filename of the named pipe or /dev/fd/ entry. Here documents << and here strings <<< use temporary files. No new processes are created.

Re: "here strings" and tmpfiles

On Tue, Apr 09, 2019 at 04:48:30PM -0700, L A Walsh wrote: > > cp <(process) /tmp/foo > --- > *red face* I'd never tried to copy something that > looked like input redirection. My apologies on my misconception. One of the archetypal examples that we give when explaining process substitut

Re: "here strings" and tmpfiles

out of space, then sleeping and retrying the operation would make since, as it would be expected that the reader would be freeing blocks on disk as it read them. It's not always a safe assumption, but what else can it do? [explanation of data piping elided -- seems to be simi

Re: "here strings" and tmpfiles

On 4/9/19 10:25 AM, konsolebox wrote: > On Mon, Apr 8, 2019 at 10:39 PM Greg Wooledge wrote: >> That's incorrect in this context. We're talking about boot scripts here, >> not interactive user shells. In boot scripts, on every operating system >> I've ever

Re: "here strings" and tmpfiles

On Tue, Apr 9, 2019 at 11:28 PM Chet Ramey wrote: > > On 4/9/19 11:25 AM, konsolebox wrote: > > On Tue, Apr 9, 2019 at 10:28 PM Chet Ramey wrote: > >> > >> On 4/9/19 10:10 AM, konsolebox wrote: > >>> On Wed, Mar 20, 2019 at 8:19 PM Greg Wooledge wrote: > > Just like that one time L. Wa

Re: "here strings" and tmpfiles

On 4/9/19 11:25 AM, konsolebox wrote: > On Tue, Apr 9, 2019 at 10:28 PM Chet Ramey wrote: >> >> On 4/9/19 10:10 AM, konsolebox wrote: >>> On Wed, Mar 20, 2019 at 8:19 PM Greg Wooledge wrote: Just like that one time L. Walsh tried to write a bash boot script that used <() to populat

Re: "here strings" and tmpfiles

On Tue, Apr 9, 2019 at 10:28 PM Chet Ramey wrote: > > On 4/9/19 10:10 AM, konsolebox wrote: > > On Wed, Mar 20, 2019 at 8:19 PM Greg Wooledge wrote: > >> > >> Just like that one time L. Walsh tried to write a bash boot script that > >> used <() to populate an array, and it failed because she was

Re: "here strings" and tmpfiles

On 4/9/19 10:10 AM, konsolebox wrote: > On Wed, Mar 20, 2019 at 8:19 PM Greg Wooledge wrote: >> >> Just like that one time L. Walsh tried to write a bash boot script that >> used <() to populate an array, and it failed because she was running >> it too early in the boot sequence, and /dev/fd/ wasn

Re: "here strings" and tmpfiles

On Mon, Apr 8, 2019 at 10:39 PM Greg Wooledge wrote: > That's incorrect in this context. We're talking about boot scripts here, > not interactive user shells. In boot scripts, on every operating system > I've ever used, the shell being used is either POSIX sh or Bou

  1   2   3   4   >