X-Recipient: archive-cygwin AT delorie DOT com DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:to:from:subject:date:message-id:references :mime-version:content-type:content-transfer-encoding; q=dns; s= default; b=phIgvkzxzIj5GSMYwY9wpZas3XF6d07jNC9GFqOfWskO4IwHWgAEN oWPcxGgjjlL3h+6o5qVVAom/wSben0xyTYxUZXai9yHUxZYVKUnURz9qCnrcJJuT VCDDVml5jSLn4VsmidiWbi4stwaeHahqYLINlTfY3My/byedf2gE5o= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:to:from:subject:date:message-id:references :mime-version:content-type:content-transfer-encoding; s=default; bh=Rp3bcyUeV95Nq0SIL682qpezvDY=; b=Q+C5NPBt4LJeasIGnMXzYIFooF52 bm8KQp7OFozOUP3SEkR/wd9LqOC9KsDPkFfkFj0YfF/JKAR5D7USX1fKVHArZozb c6LA3aMxyuMy6OHeCrbKpkiJTNFHravojXLgpywnzo820qwr7nfp1uFOPcvJe2t6 kVnCnk/oIZlHrAU= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: 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 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_40,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=cap, fat, ufs, career X-HELO: plane.gmane.org To: cygwin AT cygwin DOT com From: Brian Inglis Subject: Re: cygstart.exe can't open file:///C:/ Date: Thu, 7 Jul 2016 17:01:08 +0000 (UTC) Lines: 29 Message-ID: References: <85901248 DOT 20160707173235 AT yandex DOT ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit User-Agent: Loom/3.14 (http://gmane.org/) X-IsSubscribed: yes Andrey Repin writes: >Brian Inglis writes: >> cygstart file://C:/ works - read the MS DN and MS KB articles on file URIs >> and shlwapi > Which isn't quite right. "file:" is a protocol, "//" is the foreign host mark, "[.]/" is "current host's filesystem root". > So, I guess, the CORRECT solution (or, rather, workaround) would be an explicit "." in host name. > cygstart "file://./C:/" > Works here. Please try it yourself. MS approach makes some sense, as the RFCs e.g. 3986 define what you call the the "host" as the namespace authority. In Unix systems, you have only one unified local namespace (even though the mounted filesystems can have radically different namespace rules e.g. fat, ufs, ext?, and the RFCs state the authority may be delegated, so the rules can change along the path), whereas on Windows, each device represents (possibly virtual e.g. subst) separate filesystem namespaces. Where MS approach makes no sense, is that . is a (MS) kludge which works, but other local synonyms: null/nothing, localhost, 127.0.0.1, [::1] do not, whereas $BROWSER file://{,.,localhost,127.0.0.1,::1}/C{:,\|} displays identical contents, differing only in whether a : or | follows the drive letter in the address for each tab. I dealt with a Windows product where file: (but not ftp, http, or https) had to have an initial cap File: to work. The vendor accepted a bug report but made it a doc issue rather than doing a non-compliance fix. The company and/or products were traded annually like an end of career player! -- 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