Re: Request to a new feature on read

[Greg Wooledge]

On Thu, Apr 16, 2015 at 09:39:08AM -0500, Dan Douglas wrote:
> On Thu, Apr 16, 2015 at 9:32 AM, Greg Wooledge <wooledg@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.