public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Ryan Johnson <ryan.johnson@cs.utoronto.ca>
To: cygwin@cygwin.com
Subject: Re: stat() and tilde prefix (was bad bash tab completion)
Date: Mon, 14 Jan 2013 21:37:00 -0000	[thread overview]
Message-ID: <50F47A8B.5050001@cs.utoronto.ca> (raw)
In-Reply-To: <c040ca2ce35648f99318ee341647c241@BN1PR03MB087.namprd03.prod.outlook.com>

On 14/01/2013 3:24 PM, Stephan Mueller wrote:
> Perhaps (as you may well have already considered):
>
> - replace the path prefix by the mount point first?  (this may be naïve
>    on my part, but it's not clear to me that .. early in a path should be able
>    to influence which mount point is substituted)
If I mount something at /foo/bar/baz, then /foo/bar/baz/../../blah 
definitely shouldn't end up inside baz.

> - test directory existence of the component preceding .. before collapsing
>    (in the example above) b/.. to nothing.
> - trust that for a/b3/b2/b/../../../c, the existence test of a/b3/b2/b
>    before collapsing b/.. to nothing implies existence of b2 and b3 so no
>    further tests are needed for 'runs' of .. components with enough
>    components before them
>
> Understood that this is still going to cause a slowdown because paths with
> .. are not uncommon, but it would reduce the number of additional
> existence checks from one-per-path-component to one-per-run-of-..,
> which means none in the case of paths without .. in them.
The rest seems totally reasonable to me, FWIW.

I wouldn't put it past a Makefile (esp. one generated by autotools) or a 
gcc header search path to generate paths like: 
/a/b/c/d/../e/../f/../../../g/h (which resolves to a/g/h, if I counted 
dots correctly). Even then, though, it's "only" three checks to achieve 
posix-compliant behavior.

Ryan


--
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

  reply	other threads:[~2013-01-14 21:37 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-10 14:25 bad bash tab completion Shaddy Baddah
2012-08-10 16:54 ` Eric Blake
2013-01-14  5:21 ` stat() and tilde prefix (was bad bash tab completion) Shaddy Baddah
2013-01-14  6:17   ` Christopher Faylor
2013-01-14 12:23     ` Corinna Vinschen
2013-01-14 14:37       ` Shaddy Baddah
2013-01-14 16:13         ` Corinna Vinschen
2013-01-14 20:29           ` Stephan Mueller
2013-01-14 21:37             ` Ryan Johnson [this message]
2013-01-15  8:44               ` Corinna Vinschen
2013-01-15 12:33           ` Shaddy Baddah
2013-02-07  7:00             ` Shaddy Baddah
2013-02-07 15:32               ` Eric Blake
2013-02-07 16:10                 ` Thomas Wolff
2013-02-07 16:24                   ` Corinna Vinschen
2013-02-07 16:26                     ` Christopher Faylor
2013-01-14 15:27       ` Christopher Faylor
2013-01-14 16:05         ` Corinna Vinschen
2013-01-14 17:00           ` Christopher Faylor
2013-01-14 22:15       ` Thomas Wolff
2013-01-15  8:56         ` Corinna Vinschen
2013-01-15 19:50         ` Andrey Repin
2013-01-15 20:03           ` Larry Hall (Cygwin)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50F47A8B.5050001@cs.utoronto.ca \
    --to=ryan.johnson@cs.utoronto.ca \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).