1 |
On Fri, Jun 03, 2022 at 06:09:38AM +0200, Michał Górny wrote: |
2 |
> On Tue, 2022-05-31 at 07:23 -0400, Ionen Wolkens wrote: |
3 |
> > Often preferable to use patches so this happens, but sed have its |
4 |
> > uses/convenience and this intend to help reduce the amount of old |
5 |
> > broken seds causing issues that go unnoticed on bumps. |
6 |
> > |
7 |
> > Inspired by app-portage/iwdevtools' qa-sed (warns on any seds), but |
8 |
> > this is for more deterministic use in ebuilds. |
9 |
> > |
10 |
> > Also slightly shortens sed use, -i is default, and no need to || die. |
11 |
> > (see @EXAMPLE in eclass for a quick usage overview). |
12 |
> > |
13 |
> |
14 |
> To be honest, I strongly dislike this. It really feels like trying to |
15 |
> make an adapter for a square wheel, while the right solution would be to |
16 |
> replace the wheel. On top of that, ton of evals which are pretty much |
17 |
> a huge "no-no". |
18 |
|
19 |
As for using this or not, I don't overly mind ether way. I felt like |
20 |
giving it a try given it's been requested but if there's not much |
21 |
interest that's fine too (there's still qa-sed fwiw, with some |
22 |
limitations). |
23 |
|
24 |
> |
25 |
> Perhaps it would be better to forget about trying to work miracles with |
26 |
> sed and instead write a trivial shell replacement for the most common |
27 |
> use cases. One thing I'd love to see is a simple substitution command |
28 |
> that would work for paths/CFLAGS on RHS without having to worry about |
29 |
> them conflicting with the pattern delimiter. |
30 |
> |
31 |
> -- |
32 |
> Best regards, |
33 |
> Michał Górny |
34 |
> |
35 |
> |
36 |
|
37 |
-- |
38 |
ionen |