Re: Fwd: read -t 0 fails to detect input.
On Fri., 20 dec. 2019 at 3:57, Martin Schulte () wrote: > Hello! > > > Could you please comment about this assertions: > > > > 1.- bash will either do a select() or an ioctl(FIONREAD), or neither > > of them, but not both, as it should for it to work. read -t0 is broken. > > 2.- Conclusion: read -t0 is *broken* in bash. Don't use it. – > > No. It works as intended. It's not usable in a pipe in the way you try, > but this is caused by the principles of a pipe, not by a bug in read. > > Hello Martin! I am not the one making those comments. I don't have enough C expertise to neither confirm or deny them. But that also makes me unable to answer to the author of the comments in the proper way. I intended to receive something to correct his (incorect?) opinion. In any case, thanks. Best regards, Isaac
Re: Fwd: read -t 0 fails to detect input.
On Fri, Dec 20, 2019 at 10:40:26AM -0400, Bize Ma wrote: > I am not the one making those comments. I don't have enough C expertise > to neither confirm or deny them. But that also makes me unable to answer to > the > author of the comments in the proper way. I intended to receive something to > correct his (incorect?) opinion. It's not your job to correct someone else's erroneous statements. Don't waste your time acting as a middleman, or trying to clean up all of the misinformation on the Internet. There's too much of it for anyone to handle. If you have a specific goal you're trying to accomplish, tell us what that goal is, and maybe we can help you get it done. If there's something you don't understand, tell us what that is, and maybe we can help you understand it.
Re: Fwd: read -t 0 fails to detect input.
On 12/19/19 3:07 PM, Bize Ma wrote: > To: Chester Ramey > > On thu., dec. 19 of 2019 at 12:40, Chet Ramey () wrote: > >> On 12/18/19 6:40 PM, Bize Ma wrote: >> > > > The exit status is 0 if input is available on the specified file >>> descriptor, non-zero otherwise. >> >> Bash-5.0 uses select/FIONREAD to determine whether or not there is input >> available on the file descriptor. Those don't wait; they test whether or >> not there is input on the specified file descriptor at the point they are >> called. >> > > Thanks Chet. > > Could you please comment about this assertions: >From an eight-year-old message? > 1.- bash will either do a select() or an ioctl(FIONREAD), or neither of > them, but not both, as it should for it to work. read -t0 is broken. Do not > use it – mosvy. It doesn't matter. You can use both and not change the inherent race condition at all. The only difference in their behavior is what happens at EOF (select returns success, ioctl(FIONREAD) returns failure). If you want to see whether or not there is input on stdin, read stdin. If you want to test whether a write-only file descriptor that you opened is ready for reading, it's programmer error. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Crash when moving full-width glyphs across lines
On 12/16/19 10:37 AM, Christian Dürr wrote: Bash Version: 5.0 Patch Level: 11 Release Status: release Description: Bash will crash when moving full-width unicode glyphs like `こ` across line boundaries. Repeat-By: Paste `https://こんにち` into bash and add whitespace before it until it is in the next line. Then start deleting that whitespace until it is on the previous line again. It should crash as soon as only `https://` is on the original line. I have not been able to reproduce this using Mac OS X/Terminal and Fedora 31/Gnome Terminal. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Crash when moving full-width glyphs across lines
On 12/19/19 2:00 PM, Kirill Chibisov wrote: I was able to capture the stack trace under gdb. However you should probably use the following command in it to repro the issue. `set disable-randomization off` The issue happens quite randomly, however the important thing is exit code from bash (139). So there's something with memory access, I guess. (gdb) info stack #0 0x7fe30e6955ba in _rl_col_width (flags=, end=1735628519, start=, str=0x557e988c691a "/こんにち") at /usr/src/debug/sys-libs/readline-8.0_p1-r1/readline-8.0/display.c:3206 #1 _rl_col_width (str=0x557e988c691a "/こんにち", start=, end=1735628519, flags=) Well, the values for `end' are obviously suspicious, but you can't really tell too much from this traceback, especially since other values of interest are optimized out. The value of `end' is computed in the caller, from `oe - old'. Since those are pointers into the same string, the value shouldn't be that far out of whack. The values of `old' and `new' are helpful, though. I'll see if I can find it. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Unicode range and enumeration support.
On 2019/12/18 11:46, Greg Wooledge wrote:
To put it another way: you can write code that determines whether
an input character $c matches a glob or regex like [Z-a]. (Maybe.)
But, you CANNOT write code to generate all of the characters from Z to a
This generates characters from decimal 8300 - 8400 (because that range
includes raised and lowered digits which have the number and value
properties equivalent to 0-9.
No? 8300, 8400 arbitrary code points that contain raised and lowered numbers
that have the number property (as does 0..9):
perl -we' use strict; use v5.16;
my $c;
for ($c=8300;$c<8400;++$c) {
my $o=chr $c;
printf "%s", $o if $o=~/\pN/; #match unicode property "is_num"
};printf "\n"'
⁰⁴⁵⁶⁷⁸⁹₀₁₂₃₄₅₆₇₈₉
Q.E.D.
Is that sufficient proof?
