Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com Date: Mon, 22 Aug 2005 10:55:04 -0400 From: Christopher Faylor To: cygwin@cygwin.com Subject: Re: Path processing bug Message-ID: <20050822145504.GC1223@trixie.casa.cgf.cx> Reply-To: cygwin@cygwin.com References: <20050822002413.GE12465@trixie.casa.cgf.cx> <20050822025905.7896213C83C@cgf.cx> <20050822031715.GA17547@trixie.casa.cgf.cx> <4309C7D6.5070906@byu.net> <20050822133158.GD17452@calimero.vinschen.de> <4309D64C.88B2820@dessent.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/