Re: Why my 'ar.exe' and 'ld.exe' does not work with the inline parameter '@objectslistfile'

[Felix Lee <felix dot 1 at canids dot net>]

Ian Lance Taylor <ian@wasabisystems.com>:
> Nick Clifton <nickc@redhat.com> writes:
> > So if anybody wants to submit a patch to support "@<filename>" in
> > binutils I am willing to review it.
> I kind of think this should be handled by the shell somehow.
> Admittedly I can't think of how it would work right now.

since argv length is a hard limit imposed by an OS,
a program that expects to iterate over the argv list
will always be limited
and the usual workaround is
running the program multiple times (xargs)
which isn't always appropriate.

removing the limit in a particular kernel may be possible
but doesn't help the general case
(POSIX only requires at least 4096 bytes for argv+environ)

the other option is to change the shell->program interface.

indefinitely large argument lists are generally useful
and many programs support some form of
'file containing more args'
so maybe there should be a generalized convention for it
like maybe
    '@file' always means file has a '\n'-separated list
    '@@file' always means file has a '\0'-separated list
or something like that

any such convention will require
a systematic change to all programs that use argv.

you could do a quick form of migration for
any program that uses getopt (or getopt_long)
by teaching getopt to recognize this convention
and modify argv so the caller always sees a normalized argv list.

this would be a rather large change to getopt
(among other things, it will make malloc a requirement)
so it might be better to make a newgetopt function
and do s/getopt/newgetopt/ on a case-by-case basis.

(should you be able to say @file within an @file?
 my gut feeling is 'no'.
 my other gut feeling is 'yes'.)
--