X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Date: Tue, 16 Aug 2011 14:26:02 -0400 (EDT) From: R P Herrold To: Charles Hyder cc: cygwin AT cygwin DOT com Subject: teTeX/dvips In-Reply-To: Message-ID: References: User-Agent: Alpine 1.00 (LRH 882 2007-12-20) X-M: Go Blue X-GnuPG-GPG-Key-ID: 0x9B649644 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: 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 On Mon, 15 Aug 2011, Charles Hyder wrote: > Turns out, the include path for dvips's map files is > /usr/shar/texmf/fonts/map// (!) Here, the "//" means "search all > subdirectories", of course. I have to admit ignorance here of this seeming common knowledge. How does adding a second slash to the end of a path indicate such a search, let alone assuming it to be common 'of course' knowledge Where is this documented, as it severely 'breaks expectation' that a path specification is permitted to have 'extra' adjacent path-separators. An additional expectation is that a directory specification may be 'normalized' at any time, and is NOT overloaded with some 'secret' "search sub-paths" option man 1 dirname http://www.linuxjournal.com/content/normalizing-path-names-bash -- Russ herrold -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple