This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: PATCH: Avoid long commands in libtool


On Jul  9, 2001, Jeff Sturm <jsturm@one-point.com> wrote:

> Libtool now supports `-objectlist' to read its arguments from a file.
> This didn't work for me, since it evaluates to

> 	for fil in `cat $save_arg`

> resulting in an excessively long shell command, which is the problem that
> -objectlist was supposed to prevent in the first place.

Hmm...  Robert Boehne said he hadn't run into any problems using this
construct, and we conjectured that it was because the shell never had
to exec() a process passing a long argument list: the for command was
expanded in user-space, so it wouldn't run into kernel limits.  On
which system did you get a problem with this, and what was the exact
symptom?

> I suggest using the read builtin command to process objectlist a line at a
> time, taking care that arguments may be separated by whitespace other
> than newlines.

Neither this nor the approach you took in the patch will work.  If you
redirect the input or the output of a command, it may run in a
separate shell, so any assignments in the command won't affect the
enclosing process.

I suppose it would work to redirect the standard input into some other
file descriptor, then redirect the input file into the standard input:

exec 3<&0
exec < $save_arg
while read line; do
  for fil in $line; do
    ...
  done
done
exec 0<&3
exec 3<&- # I don't think this is portable, but we don't really need this


Also, note the nesting of while and for, so that we retain the
semantics of not requiring a file per line, but rather, of applying
word splitting to each line.

Of course, there's still a possibility that a user could exceed line
lengths and run into problems, but I don't see how a shell-script
could recover from this case.  Perhaps running the input file through
the portable equivalent of tr '[ \t]' '\n', then stripping empty
lines out?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]