Re: portability of xargs

[Bob Friesenhahn]

On Mon, 14 Feb 2022, Mike Frysinger wrote:

> On 14 Feb 2022 19:53, Paul Eggert wrote:
> > On 2/14/22 19:45, Mike Frysinger wrote:
> > > how portable is xargs ?
> >
> > It can be a porting problem, unfortunately. There are several corner
> > cases that various implementations don't get right. I expect this is why
> > the GNU Coding Standards exclude xargs from the list of programs that
> > 'configure' and Makefile rules can use.
>
> are the corner cases known ?  if it's such that xargs doesn't always correctly
> limit itself to the system limit based on other factors, i can live with that
> assuming that the -n option is reliable.

This morning I read this discussion thread and did not see any actual 
problems with current (on systems that people are still using) xargs 
portability mentioned.

Microsoft Windows (e.g. POSIX environments which run under Windows 
such as Cygwin, MSYS, etc.) is surely an existing corner case which 
demands more attention than archaic systems.  It seems that the 
command line length when using Microsoft Windows may depend on the 
number of bytes in the arguments (not the number of arguments) as well 
as the number of bytes in the current environment variable data.

A problem with xargs is that without using the GNU -O or --null 
argument and null-terminated arguments, file names containing spaces 
won't be handled properly.  File names containing spaces is an issue 
for Autotools in general.  This is again an issue under Microsoft 
Windows where users typically are provided with directory paths which 
contain a space and they need to take additional administrative 
measures in order to provide directory paths which work with 
Autotools.

Bob
--
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
Public Key,     http://www.simplesystems.org/users/bfriesen/public-key.txt