Re: Request to a new feature on read
Any reason to justify this instead of using a simple loop? -- Eduardo Bustamante https://dualbus.me/
Re: Request to a new feature on read
While I was developing a small script, I thought about how to use -N flag to a greater extent. Although -N in its own is very limited. It does serve the purpose but not what I need. I also discussed this in #bash freenode, and got some ideas like: pgas: while read -n1 d;do case $d in '')break;; [0-9])var+=$d;;*) echo error;;esac;done A for loop is probably not such a bad idea either. I'll try and see if I can figure out something. Thanks On Thu, Apr 16, 2015 at 3:55 PM, Eduardo A. Bustamante López dual...@gmail.com wrote: Any reason to justify this instead of using a simple loop? -- Eduardo Bustamante https://dualbus.me/ -- Met vriendelijke groet, Valentin Bajrami
Re: Request to a new feature on read
On Thu, Apr 16, 2015 at 09:39:08AM -0500, Dan Douglas wrote: On Thu, Apr 16, 2015 at 9:32 AM, Greg Wooledge wool...@eeg.ccf.org wrote: On Thu, Apr 16, 2015 at 09:29:56AM -0500, Dan Douglas wrote: I find myself in need of something along the lines of Python's `re.split` and `re.findall` all the time. E.g. splitting an ip into an array of octets. IFS=. read -ra octets $ip Sure, but validation is then separate if needed. There are plenty of applications where you want either a multi-character or non-static delimiter, possibly with pattern matching on the data at the same time. I don't see why such features should be compiled into bash's read builtin. I'd have no problem with adding better splitting/joining/parsing features in a more general context, probably operating on a string variable, but certainly not operating on a file descriptor. Doesn't the underlying C library only guarantee you a single character of lookahead when reading? (Or maybe a single byte. I'm way out of date. My knowledge of C comes from the days when char = byte.) You can't do all this fancy perl-RE-style lookahead stuff on a stream with only a single byte/char of lookahead.
Re: Request to a new feature on read
On Thu, Apr 16, 2015 at 9:50 AM, Greg Wooledge wool...@eeg.ccf.org wrote: I don't see why such features should be compiled into bash's read builtin. I'd have no problem with adding better splitting/joining/parsing features in a more general context, probably operating on a string variable, but certainly not operating on a file descriptor. I don't think they should be part of `read` either. Some way to extend the BASH_REMATCH mechanism would be better. Doesn't the underlying C library only guarantee you a single character of lookahead when reading? (Or maybe a single byte. I'm way out of date. My knowledge of C comes from the days when char = byte.) You can't do all this fancy perl-RE-style lookahead stuff on a stream with only a single byte/char of lookahead. Hm, maybe you're referring to ungetc? IIRC one byte is the only guarantee when dealing with pipes. I don't really care about having it pattern match while reading a stream. To make that work well would probably involve mmap (and even then, only on regular files). Probably the most portable way to support fancier regex is to call into std::regex. Any system with a modern C++ compiler should support ECMAScript regex, which is close to a superset of ERE.
Re: Request to a new feature on read
On Thu, Apr 16, 2015 at 9:32 AM, Greg Wooledge wool...@eeg.ccf.org wrote: On Thu, Apr 16, 2015 at 09:29:56AM -0500, Dan Douglas wrote: I find myself in need of something along the lines of Python's `re.split` and `re.findall` all the time. E.g. splitting an ip into an array of octets. IFS=. read -ra octets $ip Sure, but validation is then separate if needed. There are plenty of applications where you want either a multi-character or non-static delimiter, possibly with pattern matching on the data at the same time.
Re: Request to a new feature on read
On Thu, Apr 16, 2015 at 09:29:56AM -0500, Dan Douglas wrote: I find myself in need of something along the lines of Python's `re.split` and `re.findall` all the time. E.g. splitting an ip into an array of octets. IFS=. read -ra octets $ip
Request to a new feature on read
Hi, According to ''help read'' we can specify -N[chars] to trigger return automatically. Is it possible to approach read differently? For example: $re is some regular expression read -N$re -p Enter two or three digits to continue getInput The above is much of a pseudo-code but I hope you get the idea. -N in this case should be able to handle a range of 2 or 3 chars. If the regex is satisfied then return should be triggered after 2 chars otherwise wait for the third char. Thanks in advance! -- Met vriendelijke groet / Kind regards, Valentin
Re: Request to a new feature on read
On Thu, Apr 16, 2015 at 8:55 AM, Eduardo A. Bustamante López dual...@gmail.com wrote: Any reason to justify this instead of using a simple loop? I find myself in need of something along the lines of Python's `re.split` and `re.findall` all the time. E.g. splitting an ip into an array of octets. On Thu, Apr 16, 2015 at 5:49 AM, Valentin Bajrami valentin.bajr...@gmail.com wrote: Hi, According to ''help read'' we can specify -N[chars] to trigger return automatically. Is it possible to approach read differently? For example: $re is some regular expression FWIW, ksh has two redirect operators that can be used together with `read` to get something like this. They're somewhat difficult to use IMO: #pattern Seeks forward to the beginning of the next line containing pattern. ##patternThe same as # except that the portion of the file that is skipped is copied to standard output. -- Dan Douglas
