On Nov 23 12:34, Pierce Morton wrote:
If you've got a junction point (let's call it JUNC, located at
c:\example\junc ) and a real folder TARG (located at c:\example\TARG )
and your junction point points to TARG:
cygpath -w /cygdrive/c/example/junc
will give you
c:\example\TARG
as your
Greetings, Pierce Morton!
I've recently installed cygwin using the web installer, and have found
an error in the way that cygpath translates junction point paths from
*nix to Windows paths when dealing with a junction point.
If you've got a junction point (let's call it JUNC, located at
c
On Wed, Nov 24, 2010 at 12:09 PM, Andrey Repin anrdae...@freemail.ru wrote:
Greetings, Pierce Morton!
This is expected behavior for cross-links.
I took a look at the behaviour of cygpath when using cygwin symlinks
and I understand now why it does what it does with junction points.
Consistency
I've recently installed cygwin using the web installer, and have found
an error in the way that cygpath translates junction point paths from
*nix to Windows paths when dealing with a junction point.
If you've got a junction point (let's call it JUNC, located at
c:\example\junc ) and a real folder
CVSROOT:/cvs/src
Module name:src
Changes by: cori...@sourceware.org 2010-08-28 11:22:37
Modified files:
winsup/utils : ChangeLog cygcheck.cc cygpath.cc ldh.cc
locale.cc mkgroup.c mkpasswd.c module_info.cc
path.cc ps.cc
Prior to the latest release of cygwin (which translates to cygpath
version 1.6.1), the following command worked fine:
cygpath -d .
With the latest release of cygwin (which translates to cygpath version
1.8 I believe; the build was ~ August 10th), the same command
complains:
cygpath: cannot
On Aug 26 09:59, Matt Hughes wrote:
Prior to the latest release of cygwin (which translates to cygpath
version 1.6.1), the following command worked fine:
cygpath -d .
With the latest release of cygwin (which translates to cygpath version
1.8 I believe; the build was ~ August 10th
On 01/06/2010 09:19, Gary . wrote:
On 5/31/10, Dave Korn wrote:
On 30/05/2010 08:51, Gary wrote:
Since the tool
output is mixed paths and text, I'd hoped cygpath made intelligent
guesses about what was and was not likely to be a path.
Well, that is basically what it does; but, being
On 6/2/10, Dave Korn wrote:
On 01/06/2010 09:19, Gary . wrote:
Since the tool
output is mixed paths and text, I'd hoped cygpath made intelligent
guesses about what was and was not likely to be a path.
...
Okay. So I'm SOL with tool output like
Parse error: syntax error, unexpected '}' in
C
On 5/31/10, Dave Korn wrote:
On 30/05/2010 08:51, Gary wrote:
Since the tool
output is mixed paths and text, I'd hoped cygpath made intelligent
guesses about what was and was not likely to be a path.
Well, that is basically what it does; but, being a POSIX tool, the
consequence
to work, TBH. It goes back to a
previous thread about using DOS tools from inside Cygwin's emacs and
the resulting path-style clash. Someone (I think it was you, actually)
suggested script should handle the paths spewed out from the tool,
converting them to Cygwin/Unix style paths. It looks like cygpath
On 30/05/2010 08:51, Gary wrote:
Since the tool
output is mixed paths and text, I'd hoped cygpath made intelligent
guesses about what was and was not likely to be a path.
Well, that is basically what it does; but, being a POSIX tool, the
consequence is that it assumes that a colon is just
I wrote:
How should cygcheck
cygpath, not cygcheck
/me smacks head
behave when given a PATH list (e.g.,
'/bin:/usr/bin'), *without* the -p option?
For example:
$ cygpath -a -p -C ANSI -w /bin:/usr/bin
C:\cygwin\bin;C:\cygwin\bin
= okay. What I expect from RTFMP.
$ cygpath -a -C ANSI
On 29 May 2010 16:20, Gary wrote:
I wrote:
How should cygcheck
cygpath, not cygcheck
/me smacks head
behave when given a PATH list (e.g.,
'/bin:/usr/bin'), *without* the -p option?
For example:
$ cygpath -a -p -C ANSI -w /bin:/usr/bin
C:\cygwin\bin;C:\cygwin\bin
= okay. What I
On 2010.05.05 21:24, Gary wrote:
I often find myself running a piece of software from within emacs that
expects, and spits out, Windows-style paths (C:\...). Handling sending
it Windows paths based on the Cygwin ones is fine, I just use a
script.
Of course, the tool returning Windows paths is a
I often find myself running a piece of software from within emacs that
expects, and spits out, Windows-style paths (C:\...). Handling sending
it Windows paths based on the Cygwin ones is fine, I just use a
script.
Of course, the tool returning Windows paths is a PITA, because it means
I can't do
On 05/05/2010 19:24, Gary wrote:
I often find myself running a piece of software from within emacs that
expects, and spits out, Windows-style paths (C:\...). Handling sending
it Windows paths based on the Cygwin ones is fine, I just use a
script.
Of course, the tool returning Windows paths
'(lambda (path)
(replace-regexp-in-string \n
(shell-command-to-string (concat cygpath --unix ' path '))
On Wed, May 5, 2010 at 1:00 PM, Dave Korn
dave.korn.cyg...@googlemail.com wrote:
On 05/05/2010 19:24, Gary wrote:
I often find myself running a piece of software from within
-command-to-string (concat cygpath --unix ' path '))
On Wed, May 5, 2010 at 1:00 PM, Dave Korn
dave.korn.cyg...@googlemail.com wrote:
On 05/05/2010 19:24, Gary wrote:
I often find myself running a piece of software from within emacs that
expects, and spits out, Windows-style paths (C
/ diego / tst.c
CYGWIN environment variable option nodosfilewarning turns off this warning.
Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html # using-pathnames
I visited the site, looked over the cygpath, but did not understand.
I'm not good
the cygpath, but did not understand.
I'm not good with Linux, one of the reasons to use cygwin was the ease
of configuring.
Can anyone help me?
Perhaps you can elaborate on what you don't understand and why the
information and references given don't help you resolve the issue.
--
Larry Hall
On Mon, Apr 19, 2010 at 10:29:42PM -0400, Larry Hall (Cygwin) wrote:
Perhaps you can elaborate on what you don't understand and why the
information and references given don't help you resolve the issue.
Uh oh. Larry used the E word.
cgf
--
Problem reports: http://cygwin.com/problems.html
On 4/19/2010 11:19 PM, Christopher Faylor wrote:
On Mon, Apr 19, 2010 at 10:29:42PM -0400, Larry Hall (Cygwin) wrote:
Perhaps you can elaborate on what you don't understand and why the
information and references given don't help you resolve the issue.
Uh oh. Larry used the E word.
:-)
$ cygpath -AO
cygpath: failed to retrieve special folder path
On 3/3/2010 12:13 PM, Nellis, Kenneth wrote:
$ cygpath -AO
cygpath: failed to retrieve special folder path
WJFFM. If you want to report a problem to the list, please see
the problem reporting guidelines found here:
http://cygwin.com/problems.html
--
Larry Hall
From: Larry Hall (Cygwin) [mailto:reply-to-list-only...@cygwin.com]
Sent: Wednesday, March 03, 2010 17:23
To: cygwin@cygwin.com
Subject: Re: cygpath -AO
On 3/3/2010 12:13 PM, Nellis, Kenneth wrote:
$ cygpath -AO
cygpath: failed to retrieve special folder path
WJFFM. If you want
information is superfluous. It's better to
just delete it.
Sent: Wednesday, March 03, 2010 17:23
To: cygwin at cygwin dot com
^
Ditto.
Subject: Re: cygpath -AO
On 3/3/2010 12:13 PM, Nellis, Kenneth wrote:
$ cygpath -AO
cygpath: failed to retrieve special folder path
It seems there's been a change in 'cygpath -w' behaviour. Is this intentional?
On 1.7.1 (with C:\ as Cygwin root):
$ cygpath -w /tmp
C:\tmp
On 1.7.2s(0.222/5/3) 20100219 12:56:31:
$ cygpath -w /tmp
\\?\C:\tmp
The latter breaks scripts that aren't sufficiently careful about
backslash quoting
On Feb 22 15:42, Andy Koppe wrote:
It seems there's been a change in 'cygpath -w' behaviour. Is this intentional?
On 1.7.1 (with C:\ as Cygwin root):
$ cygpath -w /tmp
C:\tmp
On 1.7.2s(0.222/5/3) 20100219 12:56:31:
$ cygpath -w /tmp
\\?\C:\tmp
The latter breaks scripts that aren't
Corinna Vinschen:
On 1.7.1 (with C:\ as Cygwin root):
$ cygpath -w /tmp
C:\tmp
On 1.7.2s(0.222/5/3) 20100219 12:56:31:
$ cygpath -w /tmp
\\?\C:\tmp
The latter breaks scripts that aren't sufficiently careful about
backslash quoting, because \\?\C:\tmp loses a vital backslash during
quote
On Feb 12 17:38, Ilguiz Latypov wrote:
This caused Cygwin to run dumper.exe which pointed to a bug in cygpath.cc.
$ cygpath -p -w ''
I am attaching a patch that seems to have fixed the issue.
Looks good
This caused Cygwin to run dumper.exe which pointed to a bug in cygpath.cc.
$ cygpath -p -w ''
I am attaching a patch that seems to have fixed the issue.
-- Index: cygpath.cc
On Jan 15 23:31, Marco Atzeri wrote:
Hi,
on latest
$ uname -v
20100114 15:57:50
$ cygpath -w /
C:\cygwin2
Aborted (core dumped)
Thanks for the report. I fixed it in CVS.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader
Hi,
on latest
$ uname -v
20100114 15:57:50
$ cygpath -w /
C:\cygwin2
Aborted (core dumped)
no problems on the previous 20100101
Regards
Marco
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com
On Dec 30 16:15, Christopher Faylor wrote:
On Wed, Dec 30, 2009 at 01:18:50PM -0500, Christopher Faylor wrote:
On Wed, Dec 30, 2009 at 01:01:29PM +0100, Corinna Vinschen wrote:
On Dec 29 17:11, Jon Beniston wrote:
cygpath can read a list of paths to convert from a file, when started
On Jan 5 10:03, Buchbinder, Barry (NIH/NIAID) [E] wrote:
Upgrading from 1.5 to 1.7 I started getting an error message from
cygpath where I hadn't previously. This can be exemplified by the
following.
$ cmd /c dir /s /b o:\\ | cygpath -u -f - | wc
cygpath: out of memory
20029 20029
Upgrading from 1.5 to 1.7 I started getting an error message from
cygpath where I hadn't previously. This can be exemplified by the
following.
$ cmd /c dir /s /b o:\\ | cygpath -u -f - | wc
cygpath: out of memory
20029 20029 332488
While I've fixed my problem*, I thought that the cygwin
On Dec 29 17:11, Jon Beniston wrote:
Hi,
cygpath can read a list of paths to convert from a file, when started with
-file. However, how do you specify paths with spaces in them in this mode?
It seems quoting the path or using \ doesn't seem to work. E.g:
No, it doesn't. Space is used
On Wed, Dec 30, 2009 at 7:01 AM, Corinna Vinschen wrote:
No, it doesn't. Space is used as the field separator in the file. I
assume we need an extension like allowing to specify another separator.
Another one for next year...
As a first step, maybe just adding an xargs-style --null/-0 to
-Original Message-
From: Behalf Of Mark J. Reed
Sent: Wednesday, December 30, 2009 8:12
Subject: Re: cygpath and spaces in filenames when reading from a file
On Wed, Dec 30, 2009 at 7:01 AM, Corinna Vinschen wrote:
No, it doesn't. Space is used as the field separator
On Wed, Dec 30, 2009 at 01:01:29PM +0100, Corinna Vinschen wrote:
On Dec 29 17:11, Jon Beniston wrote:
Hi,
cygpath can read a list of paths to convert from a file, when started with
-file. However, how do you specify paths with spaces in them in this mode?
It seems quoting the path or using
On Wed, Dec 30, 2009 at 1:18 PM, Christopher Faylor wrote:
That's an option that I added. I am surprised that it is space delimited
since
I thought I intended to make it newline delimited.
It looks pretty intentional - it reads through the input line by line
using fgets, but then calls
On Wed, Dec 30, 2009 at 01:18:50PM -0500, Christopher Faylor wrote:
On Wed, Dec 30, 2009 at 01:01:29PM +0100, Corinna Vinschen wrote:
On Dec 29 17:11, Jon Beniston wrote:
cygpath can read a list of paths to convert from a file, when started
with -file. However, how do you specify paths
Hi,
cygpath can read a list of paths to convert from a file, when started with
-file. However, how do you specify paths with spaces in them in this mode?
It seems quoting the path or using \ doesn't seem to work. E.g:
$cygpath --windows --file -
/usr/local/my dir/
\usr\local\my
dir\
$ cygpath
When specify --windows or --mixed form, cygpath will append `/' to the
result path when it is a directory, this is unnecessary and
inconformity, for example:
cygpath -u some/dir
some/dir
cygpath -m some/dir
some/dir/
cygpath -w .
x:\some\dir\
The ending `\' is only needed when
With cygdrive prefix = /, from the root directory of a drive (e.g.,
/c = c:\ or /h = h:\), when asking for the absolute unix path with -au,
cygpath doubles the / between the drive letter and the first directory
of the path.
/h echo Home | cygpath -au -f -
/h//Home
/h echo Home | cygpath -aw
On Fri, May 29, 2009 at 03:20:28PM -0400, Buchbinder, Barry (NIH/NIAID) [E]
wrote:
With cygdrive prefix = /, from the root directory of a drive (e.g.,
/c = c:\ or /h = h:\), when asking for the absolute unix path with -au,
cygpath doubles the / between the drive letter and the first directory
to remap ...\Glob.dll to same address as parent ...), it did
produce new-cygwin1.dll. And with that new-cygwin1.dll installed as
/bin/cygwin1.dll, I now get:
$ cygpath -w image.png
e.png
That is, the first four characters are missing.
So my next question is how should I be rebuilding
finish (perl hung -- ... fatal error -
unable to remap ...\Glob.dll to same address as parent ...), it did
produce new-cygwin1.dll. And with that new-cygwin1.dll installed as
/bin/cygwin1.dll, I now get:
$ cygpath -w image.png
e.png
That is, the first four characters are missing
I'm seeing some really weird behavior with cygpath in cygwin 1.7 on Vista
Home Premium. For instance, if I'm in my home directory and there's an
image.png file in it:
$ ls -l image.png
-rwxrwxrwx 1 gregc None 6211 Apr 5 16:00 image.png
$ cygpath -u image.png
--- Mer 15/4/09, Greg Couch ha scritto:
Da: Greg Couch
Oggetto: [1.7] cygpath broken?
A: cygwin@cygwin.com
Data: Mercoledì 15 Aprile 2009, 08:20
I'm seeing some really weird behavior
with cygpath in cygwin 1.7 on Vista Home Premium. For
instance, if I'm in my home directory and there's
On Apr 14 23:20, Greg Couch wrote:
I'm seeing some really weird behavior with cygpath in cygwin 1.7 on Vista
Home Premium. For instance, if I'm in my home directory and there's an
image.png file in it:
$ ls -l image.png
-rwxrwxrwx 1 gregc None 6211 Apr 5 16:00 image.png
Corinna Vinschen wrote:
On Nov 10 16:06, Lee Dilkie wrote:
Hi folks,
If this isn't the list, or the method, how would one go about reporting
a bug in the cygpath utility. It is reporting an absolute path for
windows style in all invocations and ignoring the absence of -a.
$ cygpath
On Tue, Nov 11, 2008 at 01:33:52PM -0500, Lee Dilkie wrote:
Corinna Vinschen wrote:
On Nov 10 16:06, Lee Dilkie wrote:
If this isn't the list, or the method, how would one go about reporting
a bug in the cygpath utility. It is reporting an absolute path for
windows style in all invocations
On Nov 10 16:06, Lee Dilkie wrote:
Hi folks,
If this isn't the list, or the method, how would one go about reporting
a bug in the cygpath utility. It is reporting an absolute path for
windows style in all invocations and ignoring the absence of -a.
$ cygpath -w foo
C:\foo
$ cygpath
Christopher Faylor wrote:
FWIW, it is entirely possible that if you had submitted the requested
cygcheck output the problem would have been more obvious.
--
I don't doubt that for a minute. In fact, I went and gathered all the
cygcheck output and was composing the email when I came
Hi folks,
If this isn't the list, or the method, how would one go about reporting
a bug in the cygpath utility. It is reporting an absolute path for
windows style in all invocations and ignoring the absence of -a.
$ cygpath -w foo
C:\foo
$ cygpath -wa foo
C:\foo
$ cygpath -u foo
foo
$ cygpath
Lee Dilkie wrote:
Hi folks,
If this isn't the list, or the method, how would one go about reporting
a bug in the cygpath utility.
This is the proper place to report Cygwin bugs.
It is reporting an absolute path for
windows style in all invocations and ignoring the absence of -a.
$ cygpath
Larry Hall (Cygwin) wrote:
Thanks for the reply Larry.
It is reporting an absolute path for
windows style in all invocations and ignoring the absence of -a.
$ cygpath -w foo
C:\foo
$ cygpath -wa foo
C:\foo
$ cygpath -u foo
foo
$ cygpath -ua foo
/cygdrive/c//foo
WJFFM. What does
On Mon, Nov 10, 2008 at 06:33:03PM -0500, Lee Dilkie wrote:
Larry Hall (Cygwin) wrote:
Thanks for the reply Larry.
It is reporting an absolute path for
windows style in all invocations and ignoring the absence of -a.
$ cygpath -w foo
C:\foo
$ cygpath -wa foo
C:\foo
$ cygpath -u foo
Christopher Faylor wrote:
On Mon, Nov 10, 2008 at 06:33:03PM -0500, Lee Dilkie wrote:
Larry Hall (Cygwin) wrote:
Thanks for the reply Larry.
It is reporting an absolute path for
windows style in all invocations and ignoring the absence of -a.
$ cygpath -w foo
C:\foo
and ignoring the absence of -a.
$ cygpath -w foo
C:\foo
$ cygpath -wa foo
C:\foo
$ cygpath -u foo
foo
$ cygpath -ua foo
/cygdrive/c//foo
WJFFM. What does 'cygpath --version' report for you? Mine is 1.42.4.1.
Perhaps you're out of date?
$ cygpath --version
cygpath (cygwin
an absolute path for
windows style in all invocations and ignoring the absence of -a.
$ cygpath -w foo
C:\foo
$ cygpath -wa foo
C:\foo
$ cygpath -u foo
foo
$ cygpath -ua foo
/cygdrive/c//foo
Sorry but this WJFFM in cygwin-1.7.0-31 although the double // in the
-ua
it state.
cygpath --help
Will provide you with accurate help.
Thanks, but I guess I was looking for more along the lines of change
logs or something. You know, a headsup along the lines of the faw for
1.5. But as you say, it's still in development.
A change log is nothing like the manual
on latest snapshots 20081012:
strace /usr/bin/cygpath.exe
The procedure entry point _Unwind_SjLj_RaiseException
could not be located in the dynamic library
cyggcc_s.dll
That is obvious as SjLj exception are not any more
used on gcc-4.3.2
Regards
MArco
Unisciti alla community di Io
Hi Folks,
I run the setup-1.7 and upgraded my 1.5 version to try it out and I came
across this.
cygwin 1.5
[EMAIL PROTECTED]: /cygdrive/g/dilkiel_Tug_parallel_1/SmallApps/TUG
$ cygpath -m foo
foo
cygwin 1.7
[EMAIL PROTECTED] ~/views/dilkiel_Tug_parallel_1/SmallApps/TUG
$ cygpath -m foo
C
On Jun 9 16:24, Corinna Vinschen wrote:
On Jun 3 22:18, Reini Urban wrote:
$ mkdir -p t/lib
$ cygpath -aw t/lib
C:\cygwin-1.7\usr\src\perl\perl-5.10.0\builddebug\t\lib
$ cygpath -w t/lib
\ib
Ouch. I'll look into it in the next couple of days.
I've uploaded 1.7.0-17 which
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Reini Urban on 6/13/2008 7:03 AM:
| 1.5 returns in user resp. system /cygdrive,
| but 1.7 returns /cygdrive/
| This is annoying.
But is it wrong? On the other hand, what happens if the user has / as
their cygdrive; does this print //?
On Jun 13 07:13, Eric Blake wrote:
According to Reini Urban on 6/13/2008 7:03 AM:
| 1.5 returns in user resp. system /cygdrive,
| but 1.7 returns /cygdrive/
| This is annoying.
But is it wrong? On the other hand, what happens if the user has / as
their cygdrive; does this print //?
I'll
On Jun 13 15:03, Reini Urban wrote:
1.5$ perl -e'print Cygwin::mount_flags(/cygdrive)'
binmode,cygdrive,/cygdrive
1.7$ perl -e'print Cygwin::mount_flags(/cygdrive)'
binmode,cygdrive,/cygdrive/
Doesn't work for me:
1.7$ perl -e'print Cygwin::mount_flags(/cygdrive)'
Undefined subroutine
On Fri, Jun 13, 2008 at 04:30:51PM +0200, Corinna Vinschen wrote:
On Jun 13 15:03, Reini Urban wrote:
1.5$ perl -e'print Cygwin::mount_flags(/cygdrive)'
binmode,cygdrive,/cygdrive
1.7$ perl -e'print Cygwin::mount_flags(/cygdrive)'
binmode,cygdrive,/cygdrive/
Doesn't work for me:
1.7$ perl
On Jun 13 10:41, Christopher Faylor wrote:
On Fri, Jun 13, 2008 at 04:30:51PM +0200, Corinna Vinschen wrote:
On Jun 13 15:03, Reini Urban wrote:
1.5$ perl -e'print Cygwin::mount_flags(/cygdrive)'
binmode,cygdrive,/cygdrive
1.7$ perl -e'print Cygwin::mount_flags(/cygdrive)'
Corinna Vinschen schrieb:
On Jun 13 15:03, Reini Urban wrote:
1.5$ perl -e'print Cygwin::mount_flags(/cygdrive)'
binmode,cygdrive,/cygdrive
1.7$ perl -e'print Cygwin::mount_flags(/cygdrive)'
binmode,cygdrive,/cygdrive/
Doesn't work for me:
1.7$ perl -e'print Cygwin::mount_flags(/cygdrive)'
Christopher Faylor schrieb:
On Fri, Jun 13, 2008 at 04:30:51PM +0200, Corinna Vinschen wrote:
On Jun 13 15:03, Reini Urban wrote:
1.5$ perl -e'print Cygwin::mount_flags(/cygdrive)'
binmode,cygdrive,/cygdrive
1.7$ perl -e'print Cygwin::mount_flags(/cygdrive)'
binmode,cygdrive,/cygdrive/
On Jun 13 17:01, Reini Urban wrote:
Corinna Vinschen schrieb:
On Jun 13 15:03, Reini Urban wrote:
1.5$ perl -e'print Cygwin::mount_flags(/cygdrive)'
binmode,cygdrive,/cygdrive
1.7$ perl -e'print Cygwin::mount_flags(/cygdrive)'
binmode,cygdrive,/cygdrive/
Doesn't work for me:
1.7$ perl
On Jun 13 17:14, Corinna Vinschen wrote:
char *Cygwin_mount_flags(char *pathname) {
char flags[260]; /* I know, I know. stack vs heap */
[...]
return flags;
And it's returning the content of a local buffer. Ouch!
Corinna
--
Corinna Vinschen Please, send
On Jun 13 16:18, Corinna Vinschen wrote:
On Jun 13 07:13, Eric Blake wrote:
According to Reini Urban on 6/13/2008 7:03 AM:
| 1.5 returns in user resp. system /cygdrive,
| but 1.7 returns /cygdrive/
| This is annoying.
But is it wrong? On the other hand, what happens if the user has /
2008/6/13 Corinna Vinschen:
On Jun 13 17:14, Corinna Vinschen wrote:
char *Cygwin_mount_flags(char *pathname) {
char flags[260]; /* I know, I know. stack vs heap */
[...]
return flags;
And it's returning the content of a local buffer. Ouch!
It was just an example. The real
2008/6/13 Corinna Vinschen:
On Jun 13 17:14, Corinna Vinschen wrote:
char *Cygwin_mount_flags(char *pathname) {
char flags[260]; /* I know, I know. stack vs heap */
[...]
return flags;
And it's returning the content of a local buffer. Ouch!
It was just an example. The real
On Jun 3 22:18, Reini Urban wrote:
conv_posix_to_win relative is wrong in the 1.7 series.
Not only cygpath, also the cygwin1.dll call
cygwin_conv_path(CCP_POSIX_TO_WIN_W | CCP_RELATIVE,..)
I don't want to upload a new perl for release-2 with this failure.
$ uname -a
CYGWIN_NT-5.1 cygwin17
conv_posix_to_win relative is wrong in the 1.7 series.
Not only cygpath, also the cygwin1.dll call
cygwin_conv_path(CCP_POSIX_TO_WIN_W | CCP_RELATIVE,..)
I don't want to upload a new perl for release-2 with this failure.
$ uname -a
CYGWIN_NT-5.1 cygwin17 1.7.0(0.185/5/2) 2008-05-25 20:10 i686
Corinna Vinschen wrote:
Yuk. I guess it would help a lot to reproduce path.cc:check_shortcut(*)
in utils as close as possible. Afaics it doesn't use any code which
would be restricted to Cygwin, except for the call to
mount_table-conv_to_posix_path in the posixify method.
I started down
On Mar 10 21:10, Corinna Vinschen wrote:
On Mar 10 15:08, Christopher Faylor wrote:
However, I don't understand what a mingw app would see when it is started
from Cygwin now. What would a standard windows app think that its cwd would
be if it's cd'ed deep into a 32K long path.
Right
On Mar 11 08:36, Brian Dessent wrote:
Corinna Vinschen wrote:
Given that Cygwin changes to support long path names, I don't really
like to see new code still using MAX_PATH and Win32 Ansi functions
in the utils dir. I know that the Win32 cwd is always restricted to
259 chars. However,
+ static char tmp[SYMLINK_MAX + 1];
so that the following sizes would not need to be SYMLINK_MAX - 1,
+ if (!readlink (fh, tmp, SYMLINK_MAX))
+ strncpy (tmp, cygpath (papp, NULL), SYMLINK_MAX);
+ strncpy (lastsep+1, ptr, SYMLINK_MAX - (lastsep-tmp));
I.e. pure lazyness
Corinna Vinschen wrote:
Urgh. MAX_PATH is defined with trailing 0, SYMLINK_MAX is defined
without trailing 0 (like NAME_MAX). You should better change the
SYMLINK_MAX stuff back, afaics...
D'oh! 'Kay.
On Mar 10 15:08, Christopher Faylor wrote:
However, I don't understand what a mingw app would see when it is started
from Cygwin now. What would a standard windows app think that its cwd would
be if it's cd'ed deep into a 32K long path.
Right now, Cygwin copies its CWD into the user parameter
Hi Brian,
Thanks for your patch. I have a few nits, sorry.
On Mar 8 20:13, Brian Dessent wrote:
Index: cygcheck.cc
===
RCS file: /cvs/src/src/winsup/utils/cygcheck.cc,v
retrieving revision 1.97
diff -u -p -r1.97 cygcheck.cc
. It would be nice if
rel_vconcat() (or really, cygpath()) had an interface that let the
caller supply a CWD instead, as that would bypass the whole issue of
length since what this patch is doing is simply setting CWD just so that
rel_vconcat() can then get it again. I thought about doing it that way
Corinna Vinschen wrote:
I'm wondering if you would like to tweak the readlink functions, too.
Cygwin shortcuts can now have the path name appended to the actual
shortcut data. This hack was necessary to support pathnames longer than
2000 chars. See the comment and code in
On Mar 9 03:32, Brian Dessent wrote:
Corinna Vinschen wrote:
I'm wondering if you would like to tweak the readlink functions, too.
Cygwin shortcuts can now have the path name appended to the actual
shortcut data. This hack was necessary to support pathnames longer than
2000
Corinna Vinschen wrote:
Now that you mention it... did you see the comment in path.cc, line 3112ff?
There's a good chance that Windows shortcuts are not capable of long path
names. I didn't test it so far, but it would be certainly better for
readlink to use the POSIX path in the symlink
On Mar 9 05:02, Brian Dessent wrote:
Corinna Vinschen wrote:
Now that you mention it... did you see the comment in path.cc, line 3112ff?
There's a good chance that Windows shortcuts are not capable of long path
names. I didn't test it so far, but it would be certainly better for
On Sun, Mar 09, 2008 at 10:28:06AM +0100, Corinna Vinschen wrote:
Hi Brian,
Thanks for your patch. I have a few nits, sorry.
On Mar 8 20:13, Brian Dessent wrote:
Index: cygcheck.cc
===
RCS file:
On Mar 9 10:38, Christopher Faylor wrote:
On Sun, Mar 09, 2008 at 10:28:06AM +0100, Corinna Vinschen wrote:
Bash as well as tcsh, as well as zsh (and probbaly pdksh, too) create an
environment variable $PWD. Maybe Cygwin should create $PWD for native
apps if it's not already available
On Sun, Mar 09, 2008 at 04:14:40PM +0100, Corinna Vinschen wrote:
On Mar 9 10:38, Christopher Faylor wrote:
On Sun, Mar 09, 2008 at 10:28:06AM +0100, Corinna Vinschen wrote:
Bash as well as tcsh, as well as zsh (and probbaly pdksh, too) create an
environment variable $PWD. Maybe Cygwin should
Christopher Faylor wrote:
I guess I misunderstood. I thought that the current working directory
could be derived through some complicated combination of Nt*() calls.
I could be wrong here but the way I understood it, there is no concept
of a working directory at the NT level, that is
On Mar 9 11:03, Brian Dessent wrote:
Christopher Faylor wrote:
I guess I misunderstood. I thought that the current working directory
could be derived through some complicated combination of Nt*() calls.
I could be wrong here but the way I understood it, there is no concept
of a
On Sun, Mar 09, 2008 at 08:55:09PM +0100, Corinna Vinschen wrote:
On Mar 9 11:03, Brian Dessent wrote:
Christopher Faylor wrote:
I guess I misunderstood. I thought that the current working directory
could be derived through some complicated combination of Nt*() calls.
I could be wrong
Corinna Vinschen wrote:
The problem is that the cwd is stored as UNICODE_STRING with a
statically allocated buffer in the user parameter block. The
MaximumLength is set to 520. SetCurrentDirectory refuses to take paths
longer than that. In theory it would be possible to define a longer cwd
301 - 400 of 766 matches
Mail list logo
