On Aug 23 09:52, nu774 wrote:
> Thanks, 4.1.11-2 is now working fine.
>
> (2013/08/22 23:12), Corinna Vinschen wrote:
> >Since our bash maintainer Eric is currently extremly busy, I took a stab
> >at it and created a new bash-4.1.11-2 64-bit package. It picked up the
> >Cygwin getcwd and didn't h
Thanks, 4.1.11-2 is now working fine.
(2013/08/22 23:12), Corinna Vinschen wrote:
Since our bash maintainer Eric is currently extremly busy, I took a stab
at it and created a new bash-4.1.11-2 64-bit package. It picked up the
Cygwin getcwd and didn't have the reported problem in my quick test.
On Aug 22 21:48, nu774 wrote:
> Hi,
>
> It seems that getcwd() of bash continues the following approach
> until it reaches /.
>
> 1) readdir() on the parent directory.
> 2) for each dirent returned by readdir(), find the entry that
> matches the current dirctory (by comparing inode or something).
Hi,
It seems that getcwd() of bash continues the following approach until it
reaches /.
1) readdir() on the parent directory.
2) for each dirent returned by readdir(), find the entry that matches
the current dirctory (by comparing inode or something).
3) set parent dir as current, and contin
On Aug 22 11:27, nu774 wrote:
> Hi,
>
> Thanks, I see.
> And I noticed bash.exe of cygwin32 is also using it's own getcwd
> WITHOUT issue.
Still, why does it fail on 64 bit but not on 32 bit? Cygwin's path
handling code is identical for both platforms.
Corinna
--
Corinna Vinschen
On Aug 22 06:21, LRN wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 22.08.2013 06:04, nu774 wrote:
> > Hi, I've experienced the same issue. From what I can see:
> > Current bash.exe of cygwin64 seems to be improperly built with
> > HAVE_GETCWD disabled, which result in using it's
Hi,
Thanks, I see.
And I noticed bash.exe of cygwin32 is also using it's own getcwd WITHOUT
issue.
(2013/08/22 11:21), LRN wrote:
1) It's not improperly disabled. Cygwin's getcwd does not behave the way
bash wants it to (when called with 0 buffer and 0 buffer length, it
fails, instead of allo
Hi, I've experienced the same issue. From what I can see:
Current bash.exe of cygwin64 seems to be improperly built with
HAVE_GETCWD disabled, which result in using it's own getcwd
implementation in the bash source package.
This can be indirectly observed by inspecting bash.exe with dependency
wal
t; create a desktop shortcut.
> - Edit /etc/fstab to change the cygdrive prefix to /.
> - Double click 'Cygwin64 Terminal' desktop shortcut.
> Result: a bunch of errors before the bash prompt.
> shell-init: error retrieving current directory: getcwd: cannot access
> parent dir
nd let it
> create a desktop shortcut.
> - Edit /etc/fstab to change the cygdrive prefix to /.
> - Double click 'Cygwin64 Terminal' desktop shortcut.
>
> Result: a bunch of errors before the bash prompt.
>
> shell-init: error retrieving current directory: getcwd: ca
e cygdrive prefix to /.
- Double click 'Cygwin64 Terminal' desktop shortcut.
Result: a bunch of errors before the bash prompt.
shell-init: error retrieving current directory: getcwd: cannot access
parent directories: Bad file descriptor
job-working-directory: error retrieving current direc
11 matches
Mail list logo
