bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PCRE mode for sed


From: Christoph Anton Mitterer
Subject: Re: PCRE mode for sed
Date: Tue, 06 Nov 2012 00:51:35 +0100

On Mon, 2012-11-05 at 16:07 -0700, Bob Proulx wrote:
> It works _now_ only after many problems were fixed.  But it was quite
> painful working through that process.
Ok, I see... admittedly I haven't followed that when it was
introduced...



> 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.  :-)
Yeah I agree...
And I suggest to shoot people who want the later ;-)


> 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.
All right...

But question is,... does sed need to deal with this?!
I mean,... if sed would provide a simply way to chose between static
linking, dynamic linking and dynamic loading at build time,... one can
easily delegate any further responsibilities to the distros.
They can decide then whether they want to support PCRE at all,... and
how they want to do it.


> But what about all of the kernels which do not support an initial
> ramdisk?
Well you're right that there's always a scenario that could cause
problems... but I think it's then the responsibility of the user to see
what to do... in that case probably static linking...


> 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.
In principle you're right,... but I personally wouldn't have gone that
far to "declare" this feature portable.
One never knows which implementations of sed exist...


> > If someone uses such fancy stuff he cannot complain afterwards about
> > portability issues.
> 
> But they still do.  :-)
*G* ;-)


Cheers,
Chris.

Attachment: smime.p7s
Description: S/MIME cryptographic signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]