Timeline for What does POSIX require for quoted here documents inside command substitution?
Current License: CC BY-SA 4.0
32 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 28, 2020 at 13:44 | history | edited | Paulo Tomé | CC BY-SA 4.0 | Formatted text. |
| Apr 30, 2017 at 11:23 | history | edited | Kusalananda♦ | edited tags | |
| Apr 13, 2017 at 12:37 | history | edited | CommunityBot | replaced http://unix.stackexchange.com/ with https://unix.stackexchange.com/ | |
| Feb 24, 2017 at 21:28 | comment | added | Stéphane Chazelas | mksh is now widely considered pdksh's future (OpenBSD ksh being another one, but the MirBSD ksh author also maintains the Debian package bringing it to a much wider audience and mksh and oksh generally feed each other). Good catch for the bash bug btw. | |
| Feb 24, 2017 at 21:14 | answer | added | Kevin | timeline score: 8 | |
| Feb 11, 2017 at 23:05 | history | edited | Michael Homer | CC BY-SA 3.0 | Confirm that it is a Bash bug |
| Feb 11, 2017 at 6:23 | comment | added | Michael Homer | @geirha I reported a Bash bug; I'm not going to bother about pdksh since it doesn't seem to have even a shadow of current maintenance. | |
| Feb 10, 2017 at 19:47 | comment | added | geirha | I give it two more days, then I report it as a bash bug if you don't have by then. | |
| S Feb 10, 2017 at 1:29 | history | bounty ended | CommunityBot | ||
| S Feb 10, 2017 at 1:29 | history | notice removed | CommunityBot | ||
| Feb 6, 2017 at 22:51 | comment | added | Chindraba | @MichaelHomer, mostly speculation on my part. A set of rules can be setup where first rule encountered is used, and later rules handle what hasn't be handled yet. OTOH as rules are encountered the modify the results of prior rules. Sort of like the difference between OR and AND. Just a different way of considering how the rules might be interpreted by the developers when implementing them. | |
| Feb 6, 2017 at 7:50 | comment | added | Michael Homer | I have not heard of this lower-numbering rule previously and it seems somewhat at odds with the organisational system. | |
| Feb 6, 2017 at 7:43 | comment | added | Chindraba | Maybe bash has it correct, and the others not. §2.3, numbered lower so higher priority (right?), says " result token shall contain exactly the characters that appear in the input (except for <newline> joining)". Is not bash doing the newline joining in what it's sending to the command substitution? Again command substitution lower number than Here-Document rules. I just love ambiguities :/ | |
| Feb 3, 2017 at 0:30 | comment | added | don_crissti | I think you are interpreting this correctly and imo the standard is pretty clear since "The shell shall expand the command substitution by executing command in a subshell environment [...] and replacing the command substitution [...] with the standard output of the command [...]" So it runs the command in a subshell and replaces $(...) with whatever that output is... Now, when running the command in your example in a subshell (in bash) it does output the expected result. It's only when turning it into command substitution that it collapses "ghi" and "jkl". So this is a bug imo | |
| S Feb 1, 2017 at 23:49 | history | bounty started | Michael Homer | ||
| S Feb 1, 2017 at 23:49 | history | notice added | Michael Homer | Authoritative reference needed | |
| Jan 31, 2017 at 8:04 | comment | added | geirha | Looks like it's an easy fix. This patch seem to work at least: ignore_quoted_newline_in_quoted_heredoc.patch | |
| Jan 31, 2017 at 5:04 | history | edited | Michael Homer | CC BY-SA 3.0 | added 8 characters in body |
| Jan 31, 2017 at 1:01 | comment | added | Michael Homer | Fair enough. I'll give it a couple of days first. If nothing else we could ask for a formal interpretation. | |
| Jan 30, 2017 at 10:59 | comment | added | geirha | @MichaelHomer, well even if we don't consider it a bug, just as different, valid interpretations of a vague standard, Chet will non-the-less want the behaviours to match the other POSIX shells. mksh is yet another shell that does the sane thing btw (not interpreting the \). | |
| Jan 30, 2017 at 9:42 | history | edited | Michael Homer | CC BY-SA 3.0 | Add Token Recognition quote |
| Jan 30, 2017 at 8:38 | comment | added | Michael Homer | @geirha It's not clear (yet) that it is a bug. If we find something definitive I will file it with whichever shells turn out to need it. | |
| Jan 30, 2017 at 8:33 | comment | added | geirha | Have you reported this as a bug against bash yet? I agree it's a bug in bash, and I can reproduce it both in 4.4 and latest devel version. | |
| Jan 29, 2017 at 8:24 | history | tweeted | twitter.com/StackUnix/status/825620534851420161 | ||
| Jan 29, 2017 at 8:19 | history | edited | Michael Homer | CC BY-SA 3.0 | added 228 characters in body |
| Jan 29, 2017 at 8:17 | comment | added | Kusalananda♦ | FWIW: pdksh behaves like bash 4.4 and 4.3. | |
| Jan 29, 2017 at 7:54 | history | edited | Michael Homer | CC BY-SA 3.0 | added 34 characters in body |
| Jan 29, 2017 at 7:30 | history | edited | Michael Homer | CC BY-SA 3.0 | Be more explicit about contrasting shells |
| Jan 29, 2017 at 6:13 | comment | added | Michael Homer | @JuliePelletier echo "$x", but any way of inspecting the variable works. I've edited that line into the bottom. | |
| Jan 29, 2017 at 6:11 | history | edited | Michael Homer | CC BY-SA 3.0 | added 15 characters in body |
| Jan 29, 2017 at 6:07 | comment | added | Julie Pelletier | Can you show us how you produce your output in the second case? | |
| Jan 29, 2017 at 5:20 | history | asked | Michael Homer | CC BY-SA 3.0 |