public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: stat() and tilde prefix (was bad bash tab completion)
Date: Thu, 07 Feb 2013 16:24:00 -0000	[thread overview]
Message-ID: <20130207162322.GB15210@calimero.vinschen.de> (raw)
In-Reply-To: <5113D1ED.20305@towo.net>

On Feb  7 17:10, Thomas Wolff wrote:
> Am 07.02.2013 16:30, schrieb Eric Blake:
> >...
> >
> >...
> >the fact that cygwin's handling of .. is not POSIX-compliant.  I think a
> >better fix would be to change file_exists() itself instead of adding a
> >misnamed wrapper function; then bashline.c wouldn't even need patching.
> >  The string 'tilde' need not even be in the patch; what you are really
> >after is a function that says that if '..' is found within a string
> >being probed for existence, then add an additional check to see if the
> >prefix of that string exists as a directory.
> >
> >But I don't mind experimenting with the idea - it remains to be seen
> >whether people will complain that bash is noticeably slower because it
> >takes time to double-check instead of rely on cygwin's non-POSIX
> >shortcut.  And the slowdown would only be on paths containing a '..'; I
> >would NOT be checking for symlinks (even though symlinks containing ..
> >are also being interpreted in a non-POSIX manner, it is much more
> >expensive to second-guess if you have to check every name for being a
> >symlink than it is to just check for literal ..).
> Do I interpret correctly that you talk about bash filename completion here?
> Referring to http://cygwin.com/ml/cygwin/2013-01/msg00201.html,
> I'd like to point out that while this ".." thing is a cygwin bug, or
> known downside as Corinna says,
> the same issue occurs on Linux precisely with filename completion
> which isn't consistent there either.
> So it would be "over-fixing" to handle that specifically in bash.
> 
> On the other hand, considering again this "downside":
> If the core cygwin filesystem function would follow this approach,
> simply checking for an occurrence of ".." first before resolving the
> filename,
> wouldn't that be an acceptable fix without inappropriate penalty?

You don't know what you're asking for (can of worms, etc.)

This is some kind of chicken egg problem.

- The path must be normalized, otherwise we can't reliably convert
  the POSIX path prefix to a Windows pathname.

- Only after converting to a Windows path, we can perform file checks.

- Rinse and repeat.

Also, the path normalization is performed in an entirely distinct
function from the mount point conversion, and this in turn is another
function than the path function handling symlinks and devices.
Changing that requires to implement the path conversion functionality
almost from scratch.  Given the age of some of these functions, I'd
like to have done that for a long time, but I'm constantly shying away
since I don't want to break what is working today.  There's, of course,
still the aforementioned chicken-egg problem.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--
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-02-07 16:24 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
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 [this message]
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=20130207162322.GB15210@calimero.vinschen.de \
    --to=corinna-cygwin@cygwin.com \
    --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).