[Top][All Lists]

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

Re: VC and too long command lines

From: Eli Zaretskii
Subject: Re: VC and too long command lines
Date: Sat, 23 Jul 2011 10:05:26 +0300

> From: Nix <address@hidden>
> Cc: Deniz Dogan <address@hidden>, address@hidden
> Emacs: there's a reason it comes with a built-in psychotherapist.
> Date: Fri, 22 Jul 2011 21:37:50 +0100
> On 21 Jul 2011, Eli Zaretskii said:
> >> Date: Thu, 21 Jul 2011 16:16:17 +0200
> >> From: Deniz Dogan <address@hidden>
> >> 
> >> Do you happen to know of any reliable way to determine the maximum
> >> command line length of the user system?
> >
> > There isn't any, AFAIK.
> There is, but it's time-consuming. Repeatedly retry a longer and longer
> harmless command until one fails. (libtool does it.)

Obviously, such "way" is inappropriate for a facility that is supposed
to run a command of a given size, because the result of that will
still be a failure.  And if you thought of doing this test only once,
then (a) it will be time consuming, and (b) its result will be
unreliable, for the same reasons it is on Unix:

> (Note that just because a command succeeds doesn't mean a later one
> won't fail: many Unix systems have a fixed length for
> cmdline+environment, so if the environment grows then the command-line
> space necessarily must shrink. So this probably isn't actually much use
> because it means we can't check in advance, and it's too slow to check
> at the time. I suppose we could check in advance, and only recheck if
> someone calls `setenv'...)

Except that on Windows, using `setenv' is not the only reason that
could invalidate previous results.  I'm not aware of any documentation
about the specific factors which influence this, but in my experience
there are such factors.  If someone can find this documented (and
verify the accuracy of that documentation), please be sure to post
here, TIA.

reply via email to

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