command -x utility ... can be used as a built-in alternative for xargs. In contrast to xargs implementations it tries to max out the getconf ARG_MAX buffer to reduce the number of utility executions and thus might be faster.
However, its available buf size calculation is wrong: ignores terminating \0 and last char of argv[]/env[]/auxv[] strings. Also, most execve implementations (Solaris, Linux, Darwin, NetBSD, OpenBSD) add a pointer for all related strings to the buffer, so they need to be taken into account as well (FreeBSD seems to be the only exception here).
Furthermore the related error handler does not expect, that execve may return with E2BIG as well, which causes an endless loop if E2BIG occures.
Finally, the command should be enhanced, so that it tries to fail early, if there is no sufficient buf space available and it should try much harder to avoid failing with E2BIG.
See also https://github.com/ksh93/ksh/commit/acf84e9633f03b10da7d674773ca831dc4b9d88e - however, this commit is wrong wrt. space calculation, wastes a lot of space, gives up to early, dropped the error handling and thus is not reliable/usable. In contrast to its headline it does definitely not fix the problem on Solaris. Also the alignment statement is wrong - the string section[s] (argv, env, auxv) and str pointer section might be aligned to sizeof(void *) - so max. 4*15 = 60 bytes on 64bit (but there is no alignment for each string). IMHO there is no need to take this into account because the calculation already reserves 1024 bytes (POSIX suggests 2048 bytes) for implementation details like this.
command -x utility ...can be used as a built-in alternative forxargs. In contrast toxargsimplementations it tries to max out thegetconf ARG_MAXbuffer to reduce the number of utility executions and thus might be faster.However, its available buf size calculation is wrong: ignores terminating
\0and last char of argv[]/env[]/auxv[] strings. Also, most execve implementations (Solaris, Linux, Darwin, NetBSD, OpenBSD) add a pointer for all related strings to the buffer, so they need to be taken into account as well (FreeBSD seems to be the only exception here).Furthermore the related error handler does not expect, that execve may return with E2BIG as well, which causes an endless loop if E2BIG occures.
Finally, the command should be enhanced, so that it tries to fail early, if there is no sufficient buf space available and it should try much harder to avoid failing with E2BIG.
See also https://github.com/att/ast/issues/1048
See also https://github.com/ksh93/ksh/commit/acf84e9633f03b10da7d674773ca831dc4b9d88e - however, this commit is wrong wrt. space calculation, wastes a lot of space, gives up to early, dropped the error handling and thus is not reliable/usable. In contrast to its headline it does definitely not fix the problem on Solaris. Also the alignment statement is wrong - the string section[s] (argv, env, auxv) and str pointer section might be aligned to sizeof(void *) - so max. 4*15 = 60 bytes on 64bit (but there is no alignment for each string). IMHO there is no need to take this into account because the calculation already reserves 1024 bytes (POSIX suggests 2048 bytes) for implementation details like this.