Re: jhalfs can't work with sed-4.9

"Patrick Star" ([email protected] via alfs-discuss Mailing List) <[email protected]>
Newsgroups gmane.linux.lfs.automated
Message-ID <CAHQM782=316J-md9OK0MBR-cwdq_g2ztR1bOAMkx1mEym5hRvg@mail.gmail.com>
On Sun, Dec 18, 2022 at 10:44 PM Pierre Labastie <
[email protected]> wrote:

> On Sun, 2022-12-18 at 14:14 +0100, Pierre Labastie wrote:
> > On Sun, 2022-12-18 at 11:57 +0800, Patrick Star wrote:
> > >
> > >
> > > On Sun, Dec 18, 2022 at 11:43 AM Patrick Star <[email protected]>
> wrote:
> > > >
> > > >
> > > > On Sun, Dec 18, 2022 at 11:08 AM Patrick Star <[email protected]>
> wrote:
> > > > > On Sun, Dec 18, 2022 at 12:31 AM Pierre Labastie
> > > > > <[email protected]> wrote:
> > > > > > On Sat, 2022-12-17 at 14:50 +0800, Patrick Star wrote:
> > > > > > > Error log as below:
> > > > > > > Creating Makefile... START
> > > > > > >         Processing... <Chapter 4>
> > > > > > > sed: -e expression #1, char 17: Invalid range end
> > > > > > >
> > > > > > > <jhalfs> exit
> > > > > > >
> > > > > > > I have located it happend at jhalfs/LFS/master.sh line 69.
> > > > > > >
> > > > > > >  67     # Grab the name of the target
> > > > > > >  68     # This is only used to check the name in
> "opt_override" or
> > > > > > > "BLACKLIST"
> > > > > > >  69     name=`echo ${this_script} | sed -e 's@[0-9]\{3,4\}-@@'
> \
> > > > > > >  70                                     -e 's@-pass[0-9]\{1\}@@'
> \
> > > > > > >  71                                     -e 's@-libstdc++@@' \
> > > > > > >  72                                     -e 's,'$N',,' \
> > > > > > >  73                                     -e 's@-32@@'`
> > > > > > >  74
> > > > > > >
> > > > > > > But I know nothing about sed :-)
> > > > > >
> > > > > > This seems weird: This sed is ok for me with sed-4.9... What are
> your
> > > > > > settings?
> > > > > > Specially that of LANG (in configuration)?
> > > > > >
> > > > >
> > > > >
> > > > > LANG <en_US.UTF-8>
> > > > >
> > > > > Probably my sed-4.9 is broken:
> > > > >
> > > > > sed-4.8 is ok.
> > > > > $ echo 401-creatingminlayout | sed-4.8 -e 's@[0-9]\{3,4\}-@@' -e
> 's@-
> > > > > pass[0-9]\{1\}@@' -e s@-libstdc++@@ -e s,,, -e s@-32@@
> > > > > creatingminlayout
> > > > >
> > > > > but not sed-4.9.
> > > > > $ echo 401-creatingminlayout | sed-4.9 -e 's@[0-9]\{3,4\}-@@' -e
> 's@-
> > > > > pass[0-9]\{1\}@@' -e s@-libstdc++@@ -e s,,, -e s@-32@@
> > > > > sed-4.9: -e expression #1, char 17: Invalid range end
> > > > >
> > > > > Also my  sed-4.9 is much smaller than  sed-4.8 (both stripped).
> > > > > 172K  /usr/bin/sed-4.8
> > > > > 108K  /usr/bin/sed-4.9
> > > > >
> > > > >
> > > >
> > > >
> > > > I've recompiled sed-4.9, but still has the same error.
> > > > Also I found somethings interesting, both the two below commands are
> fine.
> > > > echo 401-creatingminlayout | sed -e 's@[0-8]@@'
> > > > echo 401-creatingminlayout | sed -e 's@[1-9]@@'
> > > > But  sed -e 's@[0-9]@@'  still gave an error of "Invalid range end".
> > > >
> > >
> > > Finally I found out it's a 'LANG' setting issue on my system, unset
> LANG
> > > make
> > > it work again.
> > > $ echo 401-creatingminlayout | LANG= sed -e 's@[0-9]@@'
> > >
> >
> > Somewhat weird: LANG=en_US.UTF-8 is pretty common... And definitely
> works for
> > me
> > with sed-4.9. What is your base distro? You could try running "localedef
> -i
> > en_US -f UTF-8 en_US.UTF-8", and see if there is still the same issue.
>

The base distro is a LFS too, which was built about two months ago.
But glibc in that LFS was built with some weird patches, show as later,
that can explain everything.
Why would I do that ? I was try to trim down the size of finnaly system by
remove some "useless" things.
Obviously, I was wrong, very shy for that. Please forget all about it. ;-)
==========================================================================
diff -Naurp  glibc-2.35.0/localedata/Makefile glibc-2.35/localedata/Makefile
--- glibc-2.35.0/localedata/Makefile
+++ glibc-2.35/localedata/Makefile
@@ -121,6 +121,9 @@ test-input := \
  yo_NG.UTF-8 \
  zh_CN.UTF-8 \
  $(NULL)
+test-input := \
+ en_US.UTF-8 \
+ $(NULL)

 test-input-data = $(addsuffix .in, $(test-input))
 test-output := $(foreach s, .out .xout, \
@@ -313,6 +316,10 @@ LOCALES := \
  zh_CN.UTF-8 \
  zh_TW.EUC-TW \
  $(NULL)
+LOCALES := \
+ en_GB.UTF-8 \
+ en_US.UTF-8 \
+ $(NULL)

 include ../gen-locales.mk

==========================================================================
diff -Naur glibc-2.35.0/localedata/locales/en_GB
glibc-2.35/localedata/locales/en_GB
--- glibc-2.35.0/localedata/locales/en_GB
+++ glibc-2.35/localedata/locales/en_GB
@@ -52,9 +52,9 @@ END LC_IDENTIFICATION
 LC_CTYPE
 copy "i18n"

-translit_start
-include "translit_combining";""
-translit_end
+%translit_start
+%include "translit_combining";""
+%translit_end
 END LC_CTYPE

 LC_COLLATE
diff -Naurpzw --strip-trailing-cr glibc-2.35.0/localedata/locales/en_US
glibc-2.35/localedata/locales/en_US
--- glibc-2.35.0/localedata/locales/en_US
+++ glibc-2.35/localedata/locales/en_US
@@ -41,12 +41,12 @@ LC_CTYPE
 copy "en_GB"
 END LC_CTYPE

-LC_COLLATE
+% LC_COLLATE

 % Copy the template from ISO/IEC 14651
-copy "iso14651_t1"
+% copy "iso14651_t1"

-END LC_COLLATE
+% END LC_COLLATE

 LC_MONETARY
 int_curr_symbol     "USD "
diff -Naurpzw --strip-trailing-cr glibc-2.35.0/localedata/locales/i18n
glibc-2.35/localedata/locales/i18n
--- glibc-2.35.0/localedata/locales/i18n
+++ glibc-2.35/localedata/locales/i18n
@@ -40,7 +40,7 @@ copy "i18n_ctype"

 translit_start

-include "translit_neutral";""
+%include "translit_neutral";""

 default_missing <U003F>

@@ -295,7 +295,7 @@ symbol-equivalence <HORN>              <
 symbol-equivalence <DOT-BELOW>         <POINS>

 % Copy the template from ISO/IEC 14651
-copy "iso14651_t1"
+%copy "iso14651_t1"

 END LC_COLLATE
==========================================================================



> Another possibility is that some LC_xxx variable is set to something
> weird. What
> is the output of "locale"?
>
> I can get the same message with:
> ---
> $ echo 401-creatingminlayout |sed -e 's@[1-0]@@'
> sed: -e expression #1, char 9: Invalid range end
> ---
> So if for some reason 9 is not considered to be after 0 in the collating
> order,
> then the message you see could be explained. Why this might have changed
> for you
> in sed-4.9, I don't know... For me, the above command fails with the same
> message when using either sed-4.8 or sed-4.9.
>
> Pierre
> --
> http://lists.linuxfromscratch.org/sympa/info/alfs-discuss
> Unsubscribe: See the above information page

-- 
http://lists.linuxfromscratch.org/sympa/info/alfs-discuss
Unsubscribe: See the above information page
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.