Yeah, all the permissions are 644 on the batch files. In my particular case,
the folder in question is a VMware shared folder from my host with a symbolic
link under Windows to a project folder under the C: drive. I tried changing the
permissions to 755 on my Mac host but they persist as 644 und
On 1/21/2018 4:35 AM, Grant Lewis wrote:
I’m running latest Cygwin under a Windows 10 VM. Tab completion for batch files
is not functioning. I have the bash-completion package installed. Batch file
completion does work under the zsh. Is there anything I can do to get it
working under the bash
I’m running latest Cygwin under a Windows 10 VM. Tab completion for batch files
is not functioning. I have the bash-completion package installed. Batch file
completion does work under the zsh. Is there anything I can do to get it
working under the bash shell?
Thanks,
Grant
--
Problem repo
Anyone else have this problem or is it just me?
Thanks
Lee
-- Forwarded message --
From: Lee
Date: Sat, 6 Aug 2016 12:36:25 -0400
Subject: bash tab completion
To: cygwin@cygwin.com
I have
# No over-writing files
set -o noclobber
in my .bash_profile, so if I want to redirect
I have
# No over-writing files
set -o noclobber
in my .bash_profile, so if I want to redirect output to an already
existing file I have to use " >| "
What I recently noticed is that tab completion doesn't work after >|
For example:
$ ls /tmp/xc*
/tmp/xcompile.diff
$ diff > /tmp/xc[tab]
and
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
On Tue, Jul 27, 2010 at 9:40 PM, John Cromartie wrote:
> I did 'set -vx', according to Eric Blake's advice.
>
> Tab completion appears to get hung up for a very long time on 'read -r
> tmp', but only on certain paths...
Disclaimer: I am not a shell programmer.
"read" reads from stdin (or a file
I did 'set -vx', according to Eric Blake's advice.
Tab completion appears to get hung up for a very long time on 'read -r
tmp', but only on certain paths...
I have no idea why or how to do anything about it, though. 'read -r
tmp' works as expected when I run it from the shell.
-John
--
Problem
On Feb 8 19:58, Ronald Landheer-Cieslak wrote:
> Corinna Vinschen wrote:
> >On Feb 8 07:19, [EMAIL PROTECTED] wrote:
> >>Recent remarks ("I have an idea about how to fix the race but it would
> >>introduce a destabilizing change that I'd rather not chance before 1.5.13
> >>is
> >>released") sugg
Corinna Vinschen wrote:
On Feb 8 07:19, [EMAIL PROTECTED] wrote:
Recent remarks ("I have an idea about how to fix the race but it would
introduce a destabilizing change that I'd rather not chance before 1.5.13 is
released") suggest that an updated cygwin1.dll might be imminent.
Please could I ment
On Feb 8 07:19, [EMAIL PROTECTED] wrote:
> Recent remarks ("I have an idea about how to fix the race but it would
> introduce a destabilizing change that I'd rather not chance before 1.5.13 is
> released") suggest that an updated cygwin1.dll might be imminent.
> Please could I mention a minor but
Recent remarks ("I have an idea about how to fix the race but it would
introduce a destabilizing change that I'd rather not chance before 1.5.13 is
released") suggest that an updated cygwin1.dll might be imminent.
Please could I mention a minor but annoying glitch described along with
Corinna's imm
On Wed, May 12, 2004 at 05:43:32PM +0200, Corinna Vinschen wrote:
> On May 12 16:17, Dave Korn wrote:
> > I reckon you could quote
> > http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_0
> > 4_11
> > to support the claim that what bash is doing is actually an invalid
> >
On May 12 16:17, Dave Korn wrote:
> I reckon you could quote
> http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_0
> 4_11
> to support the claim that what bash is doing is actually an invalid
> transformation and should be considered a bug. That page says
>
> "A pathna
> -Original Message-
> From: cygwin-owner On Behalf Of Corinna Vinschen
> Sent: 12 May 2004 15:09
> In bash, the path "/" is accidentally converted to "//"
> before it tries
> to call opendir() on it. On any other POSIX system, that
> doesn't matter
> since "//" has no special meaning.
On May 11 07:25, [EMAIL PROTECTED] wrote:
> Just lately (all recent snapshots including 20040510) I'm noticing a failure
> with tab completion for pathnames beginning /. Thus, I would expect, and in
> the past have achieved
>
> ls /ho
> ls /home/
> or
> md5sum /usloc
> md5
* <[EMAIL PROTECTED]> (2004-05-11 08:25 +0100)
> Just lately (all recent snapshots including 20040510) I'm noticing a failure
> with tab completion for pathnames beginning /. Thus, I would expect, and in
> the past have achieved
>
> ls /ho
> ls /home/
> or
> md5sum /usloc
>
>> Interesting.
>> No problems with tcsh or zsh.
>> Just bash misbehaves.
Corinna,
Couldn't work out whether you were enquiring further into my own experience
or (as I hope and suspect) reporting yours. But yes, I get no problems with
tcsh or zsh, just as reported with bash (and, if it's worth re
On May 11 07:25, [EMAIL PROTECTED] wrote:
>
> Just lately (all recent snapshots including 20040510) I'm noticing a failure
> with tab completion for pathnames beginning /. Thus, I would expect, and in
> the past have achieved
>
> ls /ho
> ls /home/
> or
> md5sum /usloc
>
41 matches
Mail list logo
