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.
