Re: bin/57253: xargs wraps lines after ~4k characters

[Marc Daniel Fege <marc%fege.net@localhost>]

The following reply was made to PR bin/57253; it has been noted by GNATS.

From: Marc Daniel Fege <marc%fege.net@localhost>
To: gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost, gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: bin/57253: xargs wraps lines after ~4k characters
Date: Thu, 02 Mar 2023 14:00:44 +0100

 >  Out of curiosity: what value of ARG_MAX would make you happy? :)
 
 Around 10M in one line would be sufficient for me. :-)
 
 Marc.
 
 Am Donnerstag, 2. M=E4rz 2023, 13:35:01 CET schrieb RVP:
 > The following reply was made to PR bin/57253; it has been noted by GNATS.
 >=20
 > From: RVP <rvp%SDF.ORG@localhost>
 > To: gnats-bugs%netbsd.org@localhost
 > Cc:
 > Subject: Re: bin/57253: xargs wraps lines after ~4k characters
 > Date: Thu, 2 Mar 2023 12:31:38 +0000 (UTC)
 >=20
 >  On Thu, 2 Mar 2023, Marc Daniel Fege wrote:
 >  > Indeed, some limit will be there anyway. But do those limits need to be
 >  > (artificially) defined in the userland programs themselves to handle an
 >  > otherwise comming up exception of the programming language or library?
 >=20
 >  You have to remember that the args. you're passing to the program
 >  is on the stack, and while I can see the kernel folks being OK with
 >  a 10MB stack on 64bit archs., I don't think they'll ever go for a
 >  1GB stack just to carry program arguments. There are other methods
 >  to do that. Like the `-f file' option in grep where you can supply
 >  an arbitrary amount of pattern data.
 >=20
 >  > I mean, the boundries between shells and tools have been pushed
 >  > multiple times which I clearly see in the last 20+ years. So why
 >  > not again at least push those limits to the technical/architecture
 >  > maximum and equalize them out?
 >=20
 >  Out of curiosity: what value of ARG_MAX would make you happy? :)
 >=20
 >  -RVP