On BSDs, that's what the -J option is for:

$ seq 3 | xargs -J {} echo {} 4
1 2 3 4

In any case, xargs will still call the command multiple times if the list of arguments is so big that it won't fit within the execve() limit.

With other xargs implementations, as already said you can get sh to reorder the arguments:

$ seq 3 | xargs sh -c 'echo "$@" 4' sh
1 2 3 4

With xargs implementations that don't support the -r option, you can also leverage sh to check that at least one argument was passed:

cmd1 | xargs sh -c '[ "$#" -eq 0 ] || exec cmd2 "$@" additional args' sh

Note the exec that saves a fork in shell implementations that don't do that optimisation automatically.

On BSDs, that's what the -J option is for:

$ seq 3 | xargs -J {} echo {} 4
1 2 3 4

In any case, xargs will still call the command multiple times if the list of arguments is so big that it won't fit within the execve() limit.

With other xargs implementations, as already said you can get sh to reorder the arguments:

$ seq 3 | xargs sh -c 'echo "$@" 4' sh
1 2 3 4

With xargs implementations that don't support the -r option, you can also leverage sh to check that at least one argument was passed:

cmd1 | xargs sh -c '[ "$#" -eq 0 ] || exec cmd2 "$@" additional args' sh

Note the exec that saves a fork in shell implementations that don't do that optimisation automatically. For builtin commands such as echo, in some sh implementations such as bash, using exec causes the external command (if available) to be called instead of the builtin one, making it behave more like when sh is not used (xargs cmd2).