Date:Wed, 18 Dec 2019 19:40:45 -0400
From:Bize Ma
Message-ID:
| A little delay seems to get it working:
|
| $ echo value | { read -t 0 var; } ; echo $?
| 0
It might, but that is adding no significant delay, and the
results are unpredictable.
jinx$ echo val
It seems that read -t 0 should detect if there is input from a pipe (and
others).
>From man bash:
>> If timeout is 0, read returns immediately, without trying to read any
data.
>> The exit status is 0 if input is available on the specified file
descriptor, non-zero otherwise.
So, it seems that
On 12/18/19 3:13 PM, Greg Wooledge wrote:
> On Wed, Dec 18, 2019 at 03:08:20PM -0500, Eli Schwartz wrote:
>> So all bash needs to do to print {Z..a} is to take Z == ASCII decimal 90
>> and a == ASCII decimal 97, then enumerate the numbers 90-97 and
>> translate them into ascii. No locale awareness
On Wed, Dec 18, 2019 at 03:08:20PM -0500, Eli Schwartz wrote:
> So all bash needs to do to print {Z..a} is to take Z == ASCII decimal 90
> and a == ASCII decimal 97, then enumerate the numbers 90-97 and
> translate them into ascii. No locale awareness is needed, no heuristics,
> no invocation of th
On 12/18/19 2:46 PM, Greg Wooledge wrote:
> Sorting these characters is also possible, once they have been generated.
> This is (I think!) what allows things like [Z-a] to work at all: you
> can check whether $c is >= 'Z' and <= 'a', without knowing what all of
> the characters in between are. But
On Wed, Dec 18, 2019 at 11:15:46AM -0800, L A Walsh wrote:
> On 2019/12/16 08:39, Greg Wooledge wrote:
> > The problem is, it is *not possible* to extract the set of characters
> > out of an arbitrary locale. The locale interfaces simply are not built
> > to allow it.
> >
> > You can do it in the
On 2019/12/16 08:39, Greg Wooledge wrote:
On Sat, Dec 14, 2019 at 02:48:16AM -0800, L A Walsh wrote:
On 2019/12/13 10:42, Greg Wooledge wrote:
There's a larger issue to be addressed first. The man page says,
[...]
sary. When characters are supplied, the expression expands t
This is another report.
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -Wno-parentheses -Wno-format-security
uname output: Linux hp2019 5.2.13-200.fc30.x86_64 #1 SMP Fri Sep 6
14:30:40 UTC 2019 x86_64 x86_6
I found a case that some removed bindings still remain in `bind -X'
after the fix. Here is the report.
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -Wno-parentheses -Wno-format-security
uname output: Linu
> Test case 2:
>
> $ LANG=C bash --norc
> $ bind -x '"\C-t\C-t":echo hello'
> $ bind -x '"\C-t":echo world'
> $ <--
> hello #<-- expected result is "world"
I'm sorry. I found that "Test case 2" has not yet fixed in the
previous patch. This is the patch for the additional fix for "
On 12/17/19 4:00 PM, Dave Taylor wrote:
Bash Version: 4.4
Patch Level: 12
Release Status: release
Description:
I'm trying to do a Cygwin build of the bash git repo at bminor/bash on
github.
The configure (no options) and make (no options) finish successfully, but
the build fails when doing $()
Hi, I have still several patches related to `bind'. My previous
patches are processed now so let me post them.
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -Wno-parentheses -Wno-format-security
uname outp
> I think you misunderstood my response. Wait for the next push to the
> devel git branch.
>
> Chet
I checked the latest push to the devel branch.
Thank you very much for fixing the behavior!
Best regards,
Koichi
13 matches
Mail list logo
