coreutils
[Top][All Lists]
Advanced

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

Re: [PATCH] scripts: rewrite dcgen in shellscript


From: Pádraig Brady
Subject: Re: [PATCH] scripts: rewrite dcgen in shellscript
Date: Mon, 27 May 2024 17:21:04 +0100
User-agent: Mozilla Thunderbird Beta

On 26/05/2024 22:09, Christopher Bayliss wrote:
* this makes dcgen work when building corutils on a system without perl

* I also added comments to help the next person who looks at this file

* there is a minor difference in the output between the original dcgen
   and this version, lines that start with a [:blank:] don't have that
   blank in the dircolors header. In practice this means that the line
   starting with '# numerical' doesn't have one space at the start, this
   obviously won't negatively affect dircolors.

* in this situation, the shellcheck warnings SC1003 and SC1143 are false
   positives, remove them to see for yourself. :)

+echo "static char const G_line[] ="
+echo "{"
+# shellcheck disable=SC1003,SC1143
+while read -r line;
+  do echo "$line" |\
+    # match multiple blanks and compact them down to one space
+    sed 's/[[:blank:]]\+/ /g' |\
+    # match each character and wrap it like: '<char>',
+    sed "s/./'&',/g" |\
+    # delete empty lines
+    sed '/^$/d' |\
+    # escape backslashes like: \\
+    sed 's/''\\''/''\\\\''/g' |\
+    # escape single quotes inside single quotes like so: '\''
+    sed "s/'''/'\\\''/g" |\
+    # indent the lines with two spaces
+    sed 's/^/  /g' |\
+    # add a zero terminator for each line
+    sed 's/$/0,/'
+done < "$1"
+echo "};"


To be explicit this is for devs building from git,
not users building from tarballs.
Also for reference src/extract-magic is another dev time perl dependency.
Also help2man is the main dev time perl dependency to generate man pages.
So this would only be a small step to removing the dev time perl dependency.

I agree that sed is a better dependency than perl,
however one of the big advantages that perl has is portability.
I.e. there are many variants of sed which might conflict
with the GNU sed assumed here.

For both these reasons, I'd be slightly against applying this at present.

BTW in regard to ensuring GNU sed is invoked, supporting overriding
the called sed with a $SED env var would be useful.

Another observation of the script, is that it would be more efficient
to present multiple commands to a single sed invocation,
rather than repeatedly invoking the sed command.

cheers,
Pádraig



reply via email to

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