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 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 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 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
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 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
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 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
dstart,cursorposition,(mode&CONVERTBACKSLASH?quotechars(expandedcompletion):expandedcompletion));"
This was sent here as suggested by your bug reporting under the guise of
"philosophical bugs".
Thank you for your consideration,
(I'll probably fix this myself someday, but i
-Daniel
g, 18. Dezember 2014 um 08:52 Uhr
Von: "Eduardo A. Bustamante López"
An: "Lars-Daniel Weber"
Cc: bug-bash@gnu.org
Betreff: Re: bug with German umlauts
Did you test against the current development version?
I'm not seeing that in 4.3:
dualbus@hp ~ % bash --version
GNU b
Are you shure?
Debian's bash includes patches up to bash42-037, which is dated 16-Jul-2012 17:20.
But the error still appears.
Gesendet: Donnerstag, 18. Dezember 2014 um 15:02 Uhr
Von: "Chet Ramey"
An: "Lars-Daniel Weber" , bug-bash@gnu.org
Cc: chet.ra...@case.
On November 18, 2023, Greg Wooledge wrote:
>On Sat, Nov 18, 2023 at 08:36:06AM -0500, dbarrett--- via Bug reports for the
>GNU Bourne Again SHell wrote:
>> echo foo | tee >(xclip -i) | tr o x
>>
>> The command does print "fxx" but then it hangs.
>>
>> The same command behaves correctly when run
101 - 113 of 113 matches
Mail list logo
