On 10/8/20 12:37 PM, Andreas Schwab wrote:
> On Okt 08 2020, Chet Ramey wrote:
>
>> There's no good way to tell whether or not a terminal supports bracketed
>> paste, but I suppose this is as good a start as any. Remember that gdb
>> can always turn it off while running the test suite.
>
> It
On Okt 08 2020, Chet Ramey wrote:
> There's no good way to tell whether or not a terminal supports bracketed
> paste, but I suppose this is as good a start as any. Remember that gdb
> can always turn it off while running the test suite.
It needs to be controllable from the outside. gdb itself
On 10/7/20 12:42 PM, Andreas Schwab wrote:
> On Sep 10 2020, Chet Ramey wrote:
>
>> h. Bracketed paste mode is enabled by default (for now).
>
> Shouldn't that be disabled on a dumb terminal? This wrecks havoc on the
> gdb testsuite. It sets TERM=dumb to tell readline not to do any fancy
>
On Okt 07 2020, Chet Ramey wrote:
> On 10/7/20 12:42 PM, Andreas Schwab wrote:
>> On Sep 10 2020, Chet Ramey wrote:
>>
>>> h. Bracketed paste mode is enabled by default (for now).
>>
>> Shouldn't that be disabled on a dumb terminal? This wrecks havoc on the
>> gdb testsuite. It sets TERM=dumb
On 10/7/20 12:42 PM, Andreas Schwab wrote:
> On Sep 10 2020, Chet Ramey wrote:
>
>> h. Bracketed paste mode is enabled by default (for now).
>
> Shouldn't that be disabled on a dumb terminal? This wrecks havoc on the
> gdb testsuite. It sets TERM=dumb to tell readline not to do any fancy
>
On 10/7/20 12:42 PM, Andreas Schwab wrote:
> On Sep 10 2020, Chet Ramey wrote:
>
>> h. Bracketed paste mode is enabled by default (for now).
>
> Shouldn't that be disabled on a dumb terminal? This wrecks havoc on the
> gdb testsuite. It sets TERM=dumb to tell readline not to do any fancy
>
On Sep 10 2020, Chet Ramey wrote:
> h. Bracketed paste mode is enabled by default (for now).
Shouldn't that be disabled on a dumb terminal? This wrecks havoc on the
gdb testsuite. It sets TERM=dumb to tell readline not to do any fancy
output, but this no longer works.
Andreas.
--
Andreas
Hi,
On Mon, Sep 21, 2020 at 09:13:13PM -0400, Dale R. Worley wrote:
> Andreas Schwab writes:
> I assume that if you really want the old effect, you can still do
>
> exec {dup}<&1
You mean:
exec {dup}<&0
>
> ... <( ... <$dup ) ...
and:
... <( ... <&$dup ) ...
>
> exec
Andreas Schwab writes:
> On Sep 21 2020, Dale R. Worley wrote:
>
>> Andreas Schwab writes:
>>> On Sep 10 2020, Chet Ramey wrote:
>>>
yy. Process substitution processes now get their input from /dev/null,
since
they are asynchronous, not interactive, and not jobs.
>>>
>>> That
On Sep 21 2020, Dale R. Worley wrote:
> Andreas Schwab writes:
>> On Sep 10 2020, Chet Ramey wrote:
>>
>>> yy. Process substitution processes now get their input from /dev/null, since
>>> they are asynchronous, not interactive, and not jobs.
>>
>> That breaks scripts that want to filter
Andreas Schwab writes:
> On Sep 10 2020, Chet Ramey wrote:
>
>> yy. Process substitution processes now get their input from /dev/null, since
>> they are asynchronous, not interactive, and not jobs.
>
> That breaks scripts that want to filter stdin with a process
> substitution, eg:
>
> while
On 9/17/20 5:13 PM, Robert Elz wrote:
> | I don't have list-specific email configs.
>
> Are there any lists for which you want to direct replies to yourself
> rather than the list?
That doesn't have much to do with my email configs, which are not specific
to mailing lists, since those
Date:Thu, 17 Sep 2020 14:40:04 -0400
From:Chet Ramey
Message-ID:
| That's why I find yash so interesting to test against. It's written by
| someone with almost no contact with the standards community, yet attempts
| to implement the letter of POSIX.
Yes.
On 9/16/20 6:45 PM, Robert Elz wrote:
> Date:Wed, 16 Sep 2020 11:35:41 -0400
> From:Chet Ramey
> Message-ID: <210592e5-f42c-32ee-7c85-9418d3e29...@case.edu>
>
> | That's what gives the impression that the standards committees are a
> | private club.
>
> This one
Date:Wed, 16 Sep 2020 11:35:41 -0400
From:Chet Ramey
Message-ID: <210592e5-f42c-32ee-7c85-9418d3e29...@case.edu>
| That's what gives the impression that the standards committees are a
| private club.
This one isn't confined to the standards industry, it exists
On 9/15/20 2:09 PM, Robert Elz wrote:
> Date:Tue, 15 Sep 2020 11:47:58 -0400
> From:Chet Ramey
> Message-ID:
>
>
> | This wouldn't be the first time the standard relied on readers
> | drawing an inference that's not explicit.
>
> No, it isn't. It is really hard
Date:Tue, 15 Sep 2020 11:47:58 -0400
From:Chet Ramey
Message-ID:
| This wouldn't be the first time the standard relied on readers
| drawing an inference that's not explicit.
No, it isn't. It is really hard to avoid that however, as quite often
when the text
On 9/14/20 2:56 PM, Robert Elz wrote:
> | "However, the double-quote character ( '"' ) [edited, since the HTML on
> the
> | web site is malformed]
>
> So it is, what a mess, the pdf formatted version is fine, so that is just
> a conversion error. Wonder if it is fixed yet? If not you
On 9/13/20 4:51 PM, Robert Elz wrote:
> | The specific construct is
> |
> | P=A
> | cat < | ${P+\"$P\"}
> | EOF
>
> That should output \"A\"
OK, let's discuss it.
>
> | In this case, the usual proscription on double quotes in here-documents
> | does not apply, since the double
On 9/13/20 2:45 PM, Andreas Schwab wrote:
> You have a regression here though:
>
> cat < \"
> EOF
Thanks, you're right. I'll take a look.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU
Date:Sun, 13 Sep 2020 14:29:15 -0400
From:Chet Ramey
Message-ID:
| The specific construct is
|
| P=A
| cat <
You have a regression here though:
cat <
On 9/13/20 8:21 AM, Andreas Schwab wrote:
> On Sep 10 2020, Chet Ramey wrote:
>
>> qqq. Fixed a bug that could cause backslashes quoting double quotes in here
>> document bodies to not be removed when expanding the body.
>
> Are you sure about this? My reading of POSIX says that a
Date:Sun, 13 Sep 2020 14:21:23 +0200
From:Andreas Schwab
Message-ID: <87imchg94s@igel.home>
| My reading of POSIX says that a backslash
| before a double quote should not be removed, as double quotes are not
| special in here docs.
That would be a correct
On Sep 10 2020, Chet Ramey wrote:
> qqq. Fixed a bug that could cause backslashes quoting double quotes in here
> document bodies to not be removed when expanding the body.
Are you sure about this? My reading of POSIX says that a backslash
before a double quote should not be removed, as
On Sep 11 2020, Jesse Hathaway wrote:
> On Fri, Sep 11, 2020 at 5:40 AM Andreas Schwab wrote:
>> The reason for using a process substitution is so that the loop can set
>> shell variables.
>
> Would using lastpipe be an option instead?
No, the scripts are out there and will break.
Andreas.
--
On 9/11/20 6:39 AM, Andreas Schwab wrote:
> On Sep 10 2020, Chet Ramey wrote:
>
>> yy. Process substitution processes now get their input from /dev/null, since
>> they are asynchronous, not interactive, and not jobs.
>
> That breaks scripts that want to filter stdin with a process
>
11 Eylül 2020 Cuma tarihinde Andreas Schwab yazdı:
> On Sep 10 2020, Chet Ramey wrote:
>
> > yy. Process substitution processes now get their input from /dev/null,
> since
> > they are asynchronous, not interactive, and not jobs.
>
> That breaks scripts that want to filter stdin with a
On Fri, Sep 11, 2020 at 5:40 AM Andreas Schwab wrote:
> The reason for using a process substitution is so that the loop can set
> shell variables.
Would using lastpipe be an option instead?
lastpipe
If set, and job control is not active, the shell runs
On Sep 10 2020, Chet Ramey wrote:
> yy. Process substitution processes now get their input from /dev/null, since
> they are asynchronous, not interactive, and not jobs.
That breaks scripts that want to filter stdin with a process
substitution, eg:
while read ...; do ...; done < <(filter)
30 matches
Mail list logo
