Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Date: Mon, 22 Aug 2005 10:55:04 -0400 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: Path processing bug Message-ID: <20050822145504.GC1223@trixie.casa.cgf.cx> Reply-To: cygwin AT cygwin DOT com References: <20050822002413 DOT GE12465 AT trixie DOT casa DOT cgf DOT cx> <20050822025905 DOT 7896213C83C AT cgf DOT cx> <20050822031715 DOT GA17547 AT trixie DOT casa DOT cgf DOT cx> <4309C7D6 DOT 5070906 AT byu DOT net> <20050822133158 DOT GD17452 AT calimero DOT vinschen DOT de> <4309D64C DOT 88B2820 AT dessent DOT net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4309D64C.88B2820@dessent.net> User-Agent: Mutt/1.5.8i On Mon, Aug 22, 2005 at 06:42:36AM -0700, Brian Dessent wrote: >Corinna Vinschen wrote: >>I don't agree with you that /../ components are actually seldom in path >>expressions. If you examine typical source trees, you'll find that >>expressions as -I../../foo/bar or -L/path/to/bin/../lib are used quite >>often. > >Indeed. Even just "gcc hello.c" has to wade through all this: > >$ gcc -print-search-dirs install: /usr/lib/gcc/i686-pc-cygwin/3.4.4/ >programs: >=/bin/../lib/gcc/i686-pc-cygwin/3.4.4/:/bin/../lib/gcc/:/usr/lib/gcc/i686-pc-cygwin/3.4.4/:/usr/lib/gcc/i686-pc-cygwin/3.4.4/:/usr/lib/gcc/i686-pc-cygwin/:/usr/lib/gcc/i686-pc-cygwin/3.4.4/:/usr/lib/gcc/i686-pc-cygwin/:/usr/libexec/gcc/i686-pc-cygwin/3.4.4/:/usr/libexec/gcc/i686-pc-cygwin/:/usr/lib/gcc/i686-pc-cygwin/3.4.4/:/usr/lib/gcc/i686-pc-cygwin/:/bin/../lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/i686-pc-cygwin/3.4.4/:/bin/../lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/:/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/i686-pc-cygwin/3.4.4/:/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ >libraries: >=/bin/../lib/gcc/i686-pc-cygwin/3.4.4/:/bin/../lib/gcc/:/usr/lib/gcc/i686-pc-cygwin/3.4.4/:/usr/lib/gcc/i686-pc-cygwin/3.4.4/:/bin/../lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/lib/i686-pc-cygwin/3.4.4/:/bin/../lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/lib/:/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/lib/i686-pc-cygwin/3.4.4/:/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/lib/:/bin/../lib/gcc/i686-pc-cygwin/3.4.4/../../../i686-pc-cygwin/3.4.4/:/bin/../lib/gcc/i686-pc-cygwin/3.4.4/../../../:/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../i686-pc-cygwin/3.4.4/:/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../:/lib/i686-pc-cygwin/3.4.4/:/lib/:/usr/lib/i686-pc-cygwin/3.4.4/:/usr/lib/ Yes, but how often does the normal person run gcc? I think if we should start making a statistical sampling. Once we know the percentage of time that cygwin takes to handle '..' parsing, why, the problem will have been nearly fixed all by itself! The only thing left would be the simple matter of coding. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/