GNU bug report logs - #19579
Long lines, short awk

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: "Daniel Richard G." <skunk <at> iSKUNK.ORG>
Subject: bug#19579: closed (Re: Long lines, short awk)
Date: Mon, 14 Feb 2022 12:13:02 +0000

[Message part 1 (text/plain, inline)]

Your bug report

#19579: Long lines, short awk

which was filed against the automake package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 19579 <at> debbugs.gnu.org.

-- 
19579: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19579
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Mike Frysinger <vapier <at> gentoo.org>
To: "Daniel Richard G." <skunk <at> iSKUNK.ORG>
Cc: 19579-done <at> debbugs.gnu.org
Subject: Re: Long lines, short awk
Date: Mon, 14 Feb 2022 07:12:38 -0500

[Message part 3 (text/plain, inline)]

On 14 Feb 2022 01:14, Daniel Richard G. wrote:
> On Mon, 2022 Feb  7 23:03-05:00, Mike Frysinger wrote:
> > can you provide an example that reproduces the issue ?  or link to the
> > package you're working on (assuming it's OSS) ?  i checked my own
> > projects and it didn't create a single line, it generated a bunch of
> > independent rm commands.  i looked through the automake source and
> > couldn't quickly identify something that would explain the behavior
> > you're seeing.
> 
> I am currently using Automake 1.16.3, which no longer exhibits the
> issue originally described. As far as I can tell, this was fixed as a
> side effect of Git commit 08849db8, made just ten days before my
> initial report.

ok, thanks for checking
-mike

[signature.asc (application/pgp-signature, inline)]

[Message part 5 (message/rfc822, inline)]

From: "Daniel Richard G." <skunk <at> iSKUNK.ORG>
To: bug-automake <at> gnu.org
Subject: Long lines, short awk
Date: Tue, 13 Jan 2015 01:01:44 -0500

Hello list,

I am building a source package, prepared with Automake 1.15, on HP-UX.
While running the configure script, I get

    [...]
    config.status: creating include/Makefile
    config.status: creating scripts/Makefile
    config.status: creating src/Makefile
    config.status: creating src/lib/Makefile
    awk: Input line         -rm -rf ../../src/l cannot be longer than 3,000 bytes.
     The input line number is 21137.
     The source line number is 235.
    config.status: error: could not create src/lib/Makefile

It so happens that src/lib/Makefile covers a large number of source
files, spread out across many directories. Line 21137 of Makefile.in is
the "-rm -rf" line shown below:

    distclean: distclean-am
            -rm -rf ../../src/lib/libobj/$(DEPDIR) foo/bar/$(DEPDIR) foo/baz/$(DEPDIR) ...

The line includes every single subdir-objects subdirectory known to the
makefile, and is well over 15kB long. The maintainer-clean target also
has an identical line.

I recognize that the usual thing to do here is specify e.g. AWK=gawk,
but other sections of the makefile (e.g. clean-libtool target) avoid
this issue altogether by specifying a series of short "rm" commands
instead of a single giant invocation. (Moreover, even if $AWK didn't
have a line-length limitation, the shell could still balk with an
"Argument list too long" error.) IMO, it is better to have the distclean
and maintainer-clean targets follow this same approach.


--Daniel


-- 
Daniel Richard G. || skunk <at> iSKUNK.ORG
My ASCII-art .sig got a bad case of Times New Roman.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.