From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15528 invoked by alias); 19 Jan 2014 21:36:12 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 32291 Received: (qmail 25902 invoked from network); 19 Jan 2014 21:36:05 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 From: Bart Schaefer Message-id: <140119133550.ZM5354@torch.brasslantern.com> Date: Sun, 19 Jan 2014 13:35:50 -0800 In-reply-to: <20140119191048.018a051a@pws-pc.ntlworld.com> Comments: In reply to Peter Stephenson "Re: segfault with exceedingly long path" (Jan 19, 7:10pm) References: <20140118002033.GY27889@sym.noone.org> <140117174902.ZM7366@torch.brasslantern.com> <20140119191048.018a051a@pws-pc.ntlworld.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: segfault with exceedingly long path MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Jan 19, 7:10pm, Peter Stephenson wrote: } } I'm still in favour of reducing dependency on PATH_MAX wherever } possible, since any arbitrary limit we don't actually need we don't } actually want In this particular case even if the shell were able to deal with an "unlimited" directory nesting depth, system calls like chdir(2) would begin to fail. fchdir() sort of works around it by not passing the path name, but you still must somehow obtain a file descriptor to the directory, so it's just pushing the problem up a level.