Re: Calculate download sizes rather than hardcoding them (issue 567340043 by address@hidden)

[David Kastrup]

David Kastrup <address@hidden> writes:

> There is in stepmake/stepmake/texinfo-vars.make
>
> # Recursively scan the file $(1) for @include and @verbatiminclude, search for
> # included files within the texinfo include dirs, and return all dependencies.
> scan-texi = \
> $(foreach f, $(shell test -f $(1) && sed -ne
> "/^@\(verbatim\)\?include[[:space:]]/s/@\(verbatim\)\?include//p"
> $(1)), \
>         $(call find-texi,$(f)) \
>         $(call scan-texi,$(call find-texi,$(f))) \
> )
>
> which contains several GNUisms in the sed script.  And of course,
> nothing but GNU Make will work for the Makefiles.
>
> In short: I have no idea whether GNU sed might be prescribed already or
> not.

But then if it _is_ prescribed, I have no business complicating things
like

+            sed 's/^[  ]*\([^  ]*\)[   ]*\([^  ]*\)[   ]*$/'\

instead of using \+.  Wait, I didn't complicate the expression as
required.  This works by accident (or rather the longest match rule)
rather than anything else.  I think I did this properly in some
iteration, but not this one.  It needs to be rather something more
tedious like

+            sed 's/^[  ]*\([^  ][^  ]*\)[      ][   ]*\([^     ][^  ]*\)[   
]*$/'\

So I have the choice to use \+ here (and frankly, then \s and \S for
space and non-space character classes also make sense, leading to

+            sed 's/^\s*\(\S\+\)\s\+\(\S\+\)\s*$/'\

) or forego -i .

But the current "some GNU sed" state does not make a whole lot of sense.

-- 
David Kastrup