On Thu, Feb 07, 2013 at 05:23:22PM +0100, Corinna Vinschen wrote:
>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() itsel
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 would
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 e
On 02/07/2013 12:00 AM, Shaddy Baddah wrote:
> Please find the patch discussed attached. It probably needs to be a bit
> more generic, maybe with some precompiler directives to limit it to
> cygwin? Although if it is just for cygwin, perhaps it can just go in the
> cygports patch?
The build of bas
Hi,
On 15 Jan 2013 23:33, Shaddy Baddah wrote:
From what I make of it, there needs to be a patch that, although can
work generically, adds checks only required for Cygwin. And therefore
is specific to the Cygwin package.
The check would be an extension of the file_exists() function, perhaps
ca
On 1/15/2013 2:39 PM, Andrey Repin wrote:
Greetings, Thomas Wolff!
The first step of converting a POSIX path to a Windows path is to
normalize the path. "." and ".." components are simply dropped:
"a/b/./c" -> "a\b\c"
"a/b/../c" -> "a\c"
which isn't correct already (even if everythi
Greetings, Thomas Wolff!
>> The first step of converting a POSIX path to a Windows path is to
>> normalize the path. "." and ".." components are simply dropped:
>>
>>"a/b/./c" -> "a\b\c"
>>"a/b/../c" -> "a\c"
> which isn't correct already (even if everything exists) because if b is
> a
Hi,
On 15 Jan 2013 03:13, Corinna Vinschen wrote:
It seems to me then that a patch to bash may be in order? I can see how
the bash check is the right thing to do. It doesn't want the special
tilde expansion to mask and disallow referencing of real tilde prefixed
paths. So the stat() check is the
On Jan 14 23:14, Thomas Wolff wrote:
> Am 14.01.2013 11:00, schrieb Corinna Vinschen:
> >...
> >
> >The first step of converting a POSIX path to a Windows path is to
> >normalize the path. "." and ".." components are simply dropped:
> >
> > "a/b/./c" -> "a\b\c"
> > "a/b/../c" -> "a\c"
> which
On Jan 14 16:37, Ryan Johnson wrote:
> 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
> >
Am 14.01.2013 11:00, schrieb Corinna Vinschen:
...
The first step of converting a POSIX path to a Windows path is to
normalize the path. "." and ".." components are simply dropped:
"a/b/./c" -> "a\b\c"
"a/b/../c" -> "a\c"
which isn't correct already (even if everything exists) because i
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
On Jan 14 01:17, Christopher Faylor wrote:
" It is a bug. It's not just "~". Any nonexistent directory will
" work, like "foo/..".
Corinna wrote:
" And it's a bug which isn't easily fixed. Since about the dawn of time,
" Cygwin's core path handling evaluates the path in a non-POSIX manner,
" ma
On Mon, Jan 14, 2013 at 05:04:17PM +0100, Corinna Vinschen wrote:
>On Jan 14 10:27, Christopher Faylor wrote:
>> On Mon, Jan 14, 2013 at 11:00:02AM +0100, Corinna Vinschen wrote:
>> >The first step of converting a POSIX path to a Windows path is to
>> >normalize the path. "." and ".." components a
On Jan 15 01:36, Shaddy Baddah wrote:
> Hi,
>
> On 14/01/13 21:00, Corinna Vinschen wrote:
> >On Jan 14 01:17, Christopher Faylor wrote:
> >>On Mon, Jan 14, 2013 at 04:21:25PM +1100, Shaddy Baddah wrote:
> >>>In investigating this, I believe the issue I am having is due to how
> >>>stat() handles
On Jan 14 10:27, Christopher Faylor wrote:
> On Mon, Jan 14, 2013 at 11:00:02AM +0100, Corinna Vinschen wrote:
> >The first step of converting a POSIX path to a Windows path is to
> >normalize the path. "." and ".." components are simply dropped:
> >
> > "a/b/./c" -> "a\b\c"
> > "a/b/../c" -> "
On Mon, Jan 14, 2013 at 11:00:02AM +0100, Corinna Vinschen wrote:
>On Jan 14 01:17, Christopher Faylor wrote:
>> On Mon, Jan 14, 2013 at 04:21:25PM +1100, Shaddy Baddah wrote:
>> >In investigating this, I believe the issue I am having is due to how
>> >stat() handles tilde prefixed paths. On linux
Hi,
On 14/01/13 21:00, Corinna Vinschen wrote:
On Jan 14 01:17, Christopher Faylor wrote:
On Mon, Jan 14, 2013 at 04:21:25PM +1100, Shaddy Baddah wrote:
In investigating this, I believe the issue I am having is due to how
stat() handles tilde prefixed paths. On linux we see:
linux$ $ python -
On Jan 14 01:17, Christopher Faylor wrote:
> On Mon, Jan 14, 2013 at 04:21:25PM +1100, Shaddy Baddah wrote:
> >In investigating this, I believe the issue I am having is due to how
> >stat() handles tilde prefixed paths. On linux we see:
> >
> >linux$ $ python -c 'import os; print os.stat("~/..")'
>
On Mon, Jan 14, 2013 at 04:21:25PM +1100, Shaddy Baddah wrote:
>In investigating this, I believe the issue I am having is due to how
>stat() handles tilde prefixed paths. On linux we see:
>
>linux$ $ python -c 'import os; print os.stat("~/..")'
>Traceback (most recent call last):
> File "", line
Hi,
On 10 Aug 2012 17:14, Shaddy Baddah wrote:
I've been having this problem with bash for about half a year now. I
can't remember the specific upgrade that caused it, but that's around
the time frame.
So the issue is with tab completion, and looks something like this:
snapshot 1:
$ cd ~/../
On 08/10/2012 01:14 AM, Shaddy Baddah wrote:
> Hi,
>
> I've been having this problem with bash for about half a year now. I
> can't remember the specific upgrade that caused it, but that's around
> the time frame.
>
> So the issue is with tab completion, and looks something like this:
>
> snapsh
Hi,
I've been having this problem with bash for about half a year now. I
can't remember the specific upgrade that caused it, but that's around
the time frame.
So the issue is with tab completion, and looks something like this:
snapshot 1:
$ cd ~/../
snapshot 2 (after tab-tab):
$ cd \~/../
s
23 matches
Mail list logo
