Re: PCRE mode for sed

[Bob Proulx]

Christoph Anton Mitterer wrote:
> Bob Proulx wrote:
> > For example the pcre
> > library on my system and I am sure many others lives in the
> > /usr/lib tree.  But that isn't available during early boot time
> > before /usr has been assured of being mounted.  This caused various
> > gratuitous bootstrapping problems.  The same problems will be there
> > for sed.
> Well...
> a) at least in Debian (where grep is compiled --with-pcre) all seems to
> work..

It works _now_ only after many problems were fixed.  But it was quite
painful working through that process.

> Haven't checked right now, what they do (static linking) or dlopen and
> just forbid the use of -P in early stages.

I believe they dynamically load the libpcre if -P is given.  And that
may even be in the source code now.  I don't remember.

> b) The /usr/lib, /lib is not so unlikely to go away anyway,...

Right.  The controversy continues.  And continues.  There are miles
and miles of discussion about it.  One group never wants to worry
about the practical considerations of separate filesystems.  Another
group thinks there should only ever be one large filesystem.  Another
group says they just want their system to boot.  Another group wants
to convert the init system to Python.  :-)

It is generally needed to have some type of bootstrap process.  But
everyone wants someone else to do it.  And so the mounting of
filesystems is pushed earlier and earlier in the boot process and is
getting pushed into an initial ramdisk for kernels that support it.

It will probably end up in the initial ram disk area but I don't think
it belongs there.  I think it is harder to deal with there.  But I can
see that I will be out voted on that issue.

> At least under Linux or systems that have some initramfs-like concept
> one should be able to expect that /usr is there after boot...

No.  That is incorrect.  At least not yet.  But it will very soon
likely be pushed there.

But what about all of the kernels which do not support an initial
ramdisk?

> so all you'd need is to put any libs into the early boot-areas
> (e.g. Linux' initramfs) which can even be automated.

Yuck!

> But even if not,... any OS is free to choose then whether to compile sed
> with PCRE or not.

True.  But then scripts using it could never rely upon the feature.
Are they running on a system with it?  Without it?  That is rather
like the bad old days when all of the systems were Unix except that
SunOS was different from HP-UX was different from IBM AIX was
different from BSD was different from AT&T and so on.  No fun.

> > One of the very strong
> > advantages of sed is that it is standard.
>
> True, but when someone wants to have guaranteed functionality, he
> mustn't use anything beyond what POSIX specifies for sed (and it does
> not give a PCRE mode ;) ).

Remember that POSIX was originally created to document and standardize
on the existing behaviors to stop people from creating yet more
differences between the systems and to let people know what behaviors
they could count on being there.  Sure people are using it as design
by committee now.  But I disagree with doing that.  Whether POSIX
agrees or not here doesn't matter so much to me as I consider it a
best practice issue rather than a standards issue.

> If someone uses such fancy stuff he cannot complain afterwards about
> portability issues.

But they still do.  :-)

Bob