[Top][All Lists]

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

Re: portability of xargs

From: Bob Friesenhahn
Subject: Re: portability of xargs
Date: Tue, 15 Feb 2022 08:29:31 -0600 (CST)
User-agent: Alpine 2.20 (GSO 67 2015-01-07)

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 Friesenhahn,
GraphicsMagick Maintainer,
Public Key,

reply via email to

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