From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20481 invoked from network); 3 Jun 1999 03:44:05 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 3 Jun 1999 03:44:05 -0000 Received: (qmail 2797 invoked by alias); 3 Jun 1999 03:43:32 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6441 Received: (qmail 2790 invoked from network); 3 Jun 1999 03:43:29 -0000 To: zsh-workers@sunsite.auc.dk Path: mason From: mason@primenet.com.au (Geoff Wing) Newsgroups: lists.zsh.workers Subject: Re: export limit in zsh and other shells? Date: 3 Jun 1999 03:43:17 GMT Organization: PrimeNet Computer Consultants Distribution: local Message-ID: References: <199906030250.TAA19950@news.idiom.com> Reply-To: mason@primenet.com.au NNTP-Posting-Host: coral.primenet.com.au X-Trace: coral.primenet.com.au 928381397 20473 203.43.15.2 (3 Jun 1999 03:43:17 GMT) X-Complaints-To: usenet@coral.primenet.com.au NNTP-Posting-Date: 3 Jun 1999 03:43:17 GMT User-Agent: slrn/0.9.5.6 (UNIX) Nik Gervae typed: :Here at PDI we use a TON of environment variables to control many aspects of :our animation jobs. Just today a user came to me complaining that when he :loaded *all* of these variables into his zsh session he got output like :this: : % ls : zsh: arg list too long: ls :I did a little research and have discovered that just about every shell we :have here--sh, bash, csh, tcsh, and zsh--exhibit this behavior when presented :with a couple hundred exported/environment variables. Many of these variables :are strings, by the way, so I suspect this might cause some kind of memory :buffer overrrun. Don't quote me on that, though. And all the shells spew out the same message. It's an operating system limit on argument lists. Some systems may let you alter this while up (though I don't know of any), some need a kernel recompile (I've a vague memory of doing this on my system once though I would have to rework out how), some don't let you alter it at all. My NetBSD system has a read-only value (queried with 4.4BSD-based ``sysctl''): % sysctl kern.argmax kern.argmax = 262144 which is described as "The maximum bytes of argument to execve(2)." Regards, -- Geoff Wing Mobile : (Australia) 0413 431 874 Work URL: http://www.primenet.com.au/ Ego URL: http://pobox.com/~gcw/