From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: VC and too long command lines Date: Sat, 23 Jul 2011 10:05:26 +0300 Message-ID: <837h79eatl.fsf@gnu.org> References: <4E2821C0.5090409@dogan.se> <4E2834B1.9060508@dogan.se> <83hb6fva64.fsf@gnu.org> <87mxg6jbkx.fsf@spindle.srvr.nix> NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1311404735 29899 80.91.229.12 (23 Jul 2011 07:05:35 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 23 Jul 2011 07:05:35 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 23 09:05:31 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QkWHC-0006Kz-7w for ged-emacs-devel@m.gmane.org; Sat, 23 Jul 2011 09:05:30 +0200 Original-Received: from localhost ([::1]:57087 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QkWHB-0004MO-Aa for ged-emacs-devel@m.gmane.org; Sat, 23 Jul 2011 03:05:29 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:54963) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QkWH8-0004M7-Fv for emacs-devel@gnu.org; Sat, 23 Jul 2011 03:05:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QkWH7-0007lu-72 for emacs-devel@gnu.org; Sat, 23 Jul 2011 03:05:26 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:49268) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QkWH6-0007lp-VS for emacs-devel@gnu.org; Sat, 23 Jul 2011 03:05:25 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LOR00400Y3J3000@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Sat, 23 Jul 2011 10:05:22 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.228.255.122]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LOR004RIYCW2P10@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Sat, 23 Jul 2011 10:05:21 +0300 (IDT) In-reply-to: <87mxg6jbkx.fsf@spindle.srvr.nix> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.172 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:142222 Archived-At: > From: Nix > Cc: Deniz Dogan , emacs-devel@gnu.org > 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 > >> > >> 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.