Am 13.06.2025 um 07:38 schrieb Yuyi Wang via Cygwin:
If the CWD
is /proc (so something without a Windows CWD), it seems to fall back to
referring to '/a/b' again?!?
Oh, no. That makes me nearly impossible to determine whether a path is absolute
without getting the current PWD.
That distinction
> If the CWD
> is /proc (so something without a Windows CWD), it seems to fall back to
> referring to '/a/b' again?!?
Oh, no. That makes me nearly impossible to determine whether a path is absolute
without getting the current PWD.
--
Yuyi Wang
--
Problem reports: https://cygwin.com/problem
On Wed, 11 Jun 2025, Jeremy Drake via Cygwin wrote:
> While making some tests for a path parser in rust
> (https://github.com/rust-lang/rust/pull/141864), an interesting corner
> case in Cygwin path handling came to light:
>
> Works:
> \\.\C:
> //.\C:
> //./C:\foo
>
> Doesn't work:
> //./C:
> //./
On 2025-06-11 18:57, Jeremy Drake via Cygwin wrote:
On Thu, 12 Jun 2025, Sam Edge via Cygwin wrote:
I would think that if you're building something against Cygwin, it's probably
best to assume it's POSIX where only forward-slash is special and not try to
second-guess.
This is unsafe, and actu
On 12/06/2025 01:57, Jeremy Drake wrote:
On Thu, 12 Jun 2025, Sam Edge via Cygwin wrote:
I would think that if you're building something against Cygwin, it's probably
best to assume it's POSIX where only forward-slash is special and not try to
second-guess.
This is unsafe, and actually where
On Thu, 12 Jun 2025, Sam Edge via Cygwin wrote:
> I would think that if you're building something against Cygwin, it's probably
> best to assume it's POSIX where only forward-slash is special and not try to
> second-guess.
This is unsafe, and actually where the rust PR started out. If you only
t
On 12/06/2025 00:01, Jeremy Drake via Cygwin wrote:
While making some tests for a path parser in rust
(https://github.com/rust-lang/rust/pull/141864), an interesting corner
case in Cygwin path handling came to light:
Works:
\\.\C:
//.\C:
//./C:\foo
Doesn't work:
//./C:
//./C:/foo
It appears to
Greetings, Ulli Horlacher!
> I want to start a cygwin program via a cmd batch script.
> I have:
> C:\cygwin>type runcmd.bat
> @echo off
> C:
> chdir C:\cygwin\bin
> bash --login -c "%*"
Try
bash --login -c '%*'
> echo.
> pause
> But when I start it I get:
> C:\cygwin>runcmd.bat xxx \cyg
Greetings, John Norris!
> Hi,
> I am running cygwin 1.7.x on Windows 2008. I realise this may be out of
> date but this is what we are using.
> I have noticed that the path variable for our build user is dependent
> on where "cmd /C" is run from.
> Please see below - I have cut back the PATH so
On Jun 30 18:27, John Norris wrote:
> Hi,
> I am running cygwin 1.7.x on Windows 2008. I realise this may be out of date
> but this is what we are using.
> I have noticed that the path variable for our build user is dependent on
> where "cmd /C" is run from.
> Please see below - I have cut back the
On 06/30/2015 02:27 PM, John Norris wrote:
Hi,
I am running cygwin 1.7.x on Windows 2008. I realise this may be out of date
but this is what we are using.
I have noticed that the path variable for our build user is dependent on
where "cmd /C" is run from.
Please see below - I have cut back the PA
Greetings, Robert Klemme!
> C:\Users\rklemme>C:\cygwin64\bin\bash.exe -i -x -c exit >bash-log.txt 2>&1
> First line that contains PATH looks like this:
> ++ PATH='/cygdrive/c/PROGRAM FILES (X86)/NVIDIA
> CORPORATION/PHYSX/COMMON:/cygdrive/c/PROGRAM FILES (X86)/INTEL/ICLS
> CLIENT:/cygdrive/c/PRO
On 3/6/2014 05:29, Robert Klemme wrote:
The phenomenon persists, for these executions:
c:\cygwin64\bin\bash.exe --norc --noprofile -i
c:\cygwin64\bin\bash.exe --norc --noprofile
c:\cygwin64\bin\bash.exe -i -l
Actually I could not find a commandline with bash that did not lead to
the dot appended
Hi,
Matthew Blakley pointed out to me that he noticed that under Windows 7
several processes have the dot added - not only Cygwin processes. I
checked with ProcessExplorer and indeed PATH of chrome.exe ends with
";.;". So it could be an OS "feature" but I could not find any
documentation about th
If it is of any use, the versions I have installed,
bash/sh 4.1.10(4), have the same length and differ
in two byte positions, by one bit in each case.
These differences may just reflect the different
name or a slightly different time at which the .exe
was constructed as part of a build process.
Folks,
sorry for the delay, I was sick in the meantime. Now, I try to
summarize all my finding in the hopes that bash package maintainer can
pick up from here.
When starting a terminal on my Windows 7 64 bit system $PATH contains
a dot at the end. The dot is not present in my Windows environment
On 2/20/2014 10:41 AM, Ken Brown wrote:
On 2/20/2014 9:12 AM, Robert Klemme wrote:
2. only bash invoked as bash shows it - it's not shown when invoked as sh.exe
This fact should enable you to track down the problem. The bash manual
explains how it behaves
differently when invoked as sh.exe.
On 2/20/2014 9:12 AM, Robert Klemme wrote:
2. only bash invoked as bash shows it - it's not shown when invoked as sh.exe
This fact should enable you to track down the problem. The bash manual
explains how it behaves differently when invoked as sh.exe. I don't
remember the details, but I thi
On Thu, Feb 20, 2014 at 03:12:47PM +0100, Robert Klemme wrote:
>Thanks to all who helped so far!
>
>On Wed, Feb 19, 2014 at 11:23 PM, Andrey Repin wrote:
>
>> So far, I'm not convinced that issue is Cygwin-specific. The fact that it
>> doesn't manifest in Windows is actually because of it's (windo
On 2/20/2014 9:12 AM, Robert Klemme wrote:
Thanks to all who helped so far!
On Wed, Feb 19, 2014 at 11:23 PM, Andrey Repin wrote:
So far, I'm not convinced that issue is Cygwin-specific. The fact that it
doesn't manifest in Windows is actually because of it's (windows) native
ignorance for th
Thanks to all who helped so far!
On Wed, Feb 19, 2014 at 11:23 PM, Andrey Repin wrote:
> So far, I'm not convinced that issue is Cygwin-specific. The fact that it
> doesn't manifest in Windows is actually because of it's (windows) native
> ignorance for this matter.
I sent a lengthy email with
Greetings, Larry Hall (Cygwin)!
> It's certainly possible that there is a pathological case where the Windows
> path isn't handled properly because of size, content, or other unforeseen
> case.
I can offer one idea of where this problem could originate from, which is in
no way pathological (i mea
On 2/19/2014 3:27 PM, Achim Gratz wrote:
Cliff Hones writes:
So there is no dot at the end of PATH as seen in cmd - and (I assume,
since this was also discussed) no duplicated semicolons or trailing
semicolon at the end of the cmd PATH. But the very first PATH printed
by bash does contain a tra
Cliff Hones writes:
> So there is no dot at the end of PATH as seen in cmd - and (I assume,
> since this was also discussed) no duplicated semicolons or trailing
> semicolon at the end of the cmd PATH. But the very first PATH printed
> by bash does contain a trailing dot. I assume this is before
On 19/02/2014 19:32, Larry Hall (Cygwin) wrote:
> On 2/19/2014 2:10 PM, Andrey Repin wrote:
>> Greetings, Larry Hall (Cygwin)!
>>
>>> From the Windows "Run..." or "Search programs and files" edit box,
>>> type "cmd.exe". From the console window that opens as a result, type
>>> the following.
>>
On 2/19/2014 2:10 PM, Andrey Repin wrote:
Greetings, Larry Hall (Cygwin)!
From the Windows "Run..." or "Search programs and files" edit box,
type "cmd.exe". From the console window that opens as a result, type
the following.
echo %PATH%
c:\cygwin64\bin\bash --norc --noprofile -lix
echo $P
Greetings, Larry Hall (Cygwin)!
> From the Windows "Run..." or "Search programs and files" edit box,
> type "cmd.exe". From the console window that opens as a result, type
> the following.
> echo %PATH%
> c:\cygwin64\bin\bash --norc --noprofile -lix
> echo $PATH
Larry, we walked through exactl
On 2/19/2014 12:51 PM, Robert Klemme wrote:
On Wed, Feb 19, 2014 at 6:23 PM, Larry Hall (Cygwin)
wrote:
On 2/19/2014 12:16 PM, Robert Klemme wrote:
The dot is already in the variable before bash even modifies it.
So that means you need to look in your Windows environment to understand
whe
Greetings, Robert Klemme!
> On Wed, Feb 19, 2014 at 6:23 PM, Larry Hall (Cygwin)
> wrote:
>> On 2/19/2014 12:16 PM, Robert Klemme wrote:
>>> The dot is already in the variable before bash even modifies it.
>>
>> So that means you need to look in your Windows environment to understand
>> where th
On Wed, Feb 19, 2014 at 6:23 PM, Larry Hall (Cygwin)
wrote:
> On 2/19/2014 12:16 PM, Robert Klemme wrote:
>> The dot is already in the variable before bash even modifies it.
>
> So that means you need to look in your Windows environment to understand
> where this comes from.
I did look in window
On 2/19/2014 12:16 PM, Robert Klemme wrote:
On Wed, Feb 19, 2014 at 5:06 PM, Eliot Moss wrote:
As others have said, cygwin does not add . to the path
itself. It must be something in your .bash_profile,
.bashrc, or other script sourced from them.
Going through the output of your login with tra
On Wed, Feb 19, 2014 at 5:06 PM, Eliot Moss wrote:
> As others have said, cygwin does not add . to the path
> itself. It must be something in your .bash_profile,
> .bashrc, or other script sourced from them.
>
> Going through the output of your login with tracing
> enabled, as previously describe
As others have said, cygwin does not add . to the path
itself. It must be something in your .bash_profile,
.bashrc, or other script sourced from them.
Going through the output of your login with tracing
enabled, as previously described, really is a straightforward
way to track this down ...
Reg
On 2/19/2014 3:37 AM, Robert Klemme wrote:
I assume there must be some internal mechanism in Cygwin which causes
this but at the moment I am out of ideas where to look further. Does
anybody else have an idea? Is there maybe some automatism which adds
the dot because on Windows systems the shell
On Tue, Feb 18, 2014 at 7:32 PM, David Boyce wrote:
>> On Thu, Feb 6, 2014 at 4:32 PM, Robert Klemme
>> wrote:
>>
>>> Can anybody make sense of that? I can share the complete log with
>>> individuals if it helps.
>>
>> Nobody?
>
> I haven't read the whole backthread, but you do understand that a
On Thu, Feb 6, 2014 at 4:32 PM, Robert Klemme
wrote:
> Can anybody make sense of that? I can share the complete log with
> individuals if it helps.
Nobody?
Cheers
robert
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
--
Problem reports: ht
On Thu, Feb 6, 2014 at 12:56 PM, Andrey Repin wrote:
> Greetings, Robert Klemme!
Hello Andrey!
>> I should have mentioned that I did just that - to no avail.
>
>> $ echo exit | bash --login -i -x 2>|log
>> $ egrep -n 'PATH=(.:|.*:\.($|:))' log | head
>> 1:+ PATH=/usr/local/bin:/usr/bin:/usr/gnu/b
Greetings, Robert Klemme!
> I should have mentioned that I did just that - to no avail.
> $ echo exit | bash --login -i -x 2>|log
> $ egrep -n 'PATH=(.:|.*:\.($|:))' log | head
> 1:+ PATH=/usr/local/bin:/usr/bin:/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.
> 140:+++
> PATH=/usr/local/bin:/usr/bin
On Thu, Feb 6, 2014 at 10:14 AM, Csaba Raduly wrote:
> Hi Robert,
>
> On Thu, Feb 6, 2014 at 10:01 AM, Robert Klemme wrote:
>> Hi,
>>
>> in cygwin64 on Win 7 64 bit I find "." in $PATH:
>>
>> $ echo "$PATH" | tr : \\n | egrep '^\.$'
>> .
>>
>> However, I was not able to detect where this came from
Hi Robert,
On Thu, Feb 6, 2014 at 10:01 AM, Robert Klemme wrote:
> Hi,
>
> in cygwin64 on Win 7 64 bit I find "." in $PATH:
>
> $ echo "$PATH" | tr : \\n | egrep '^\.$'
> .
>
> However, I was not able to detect where this came from. It's neither
> in the Windows system environment variables nor
On 11/27/2013 4:01 PM, Matthew Lagoe wrote:
Sorry I did not clarify earlier, I have cygin added to my path and I have
not added anything to /cygdrive or otherwise.
C:\tmp>where ls
C:\cygwin\bin\ls.exe
C:\tmp>C:\cygwin\bin\ls.exe /cygdrive
c
I noticed that all the paths that I am having issues
Sorry I did not clarify earlier, I have cygin added to my path and I have
not added anything to /cygdrive or otherwise.
C:\tmp>where ls
C:\cygwin\bin\ls.exe
C:\tmp>C:\cygwin\bin\ls.exe /cygdrive
c
I noticed that all the paths that I am having issues with are setup via a
"subst" in windows
You
On 11/27/2013 3:03 PM, Matthew Lagoe wrote:
im having a problem with paths, when i use /cygdrive/l in the windows shell
it doesn't work however when i use it in the cygwin shell it works fine
/cygdrive/c works fine in both
The windows shell only see's the "C" drive even with ls
C:\>ls /cy
On Wed, Oct 10, 2012 at 9:01 AM, Frank P Esposito wrote:
> I have an issue now that bash can't find script, but "which" locates
> it -- is there a way to debug this?
What does ``ls -l `which FOO`'' report?
--
Earnie
-- https://sites.google.com/site/earnieboyd
--
Problem reports: http://c
On Tue, Mar 22, 2011 at 08:28:49PM +0530, chandan_c9 wrote:
> I have installed Cygwin yesterday.I want to extract a .run file but I am
> getting
> error as PATH environment variables failed to evaluate correctly.
> I am not getting clue by searching on google.
Hello,
Files with a *.run extensio
On Tue, Mar 22, 2011 at 11:01:48AM -0400, Christopher Faylor wrote:
>On Tue, Mar 22, 2011 at 08:28:49PM +0530, chandan...@indiatimes.com wrote:
>>Hello,
>>I have installed Cygwin yesterday.I want to extract a .run file but I
>>am getting error as PATH environment variables failed to evaluate
>>corr
On Tue, Mar 22, 2011 at 08:28:49PM +0530, chandan...@indiatimes.com wrote:
>Hello,
>I have installed Cygwin yesterday.I want to extract a .run file but I
>am getting error as PATH environment variables failed to evaluate
>correctly.I am not getting clue by searching on google.
We're not getting a
Thanks, Vincent,
I did as you told and it worked fine.
Vincent Rivière-2 wrote:
>
> Sunoki wrote:
>> $ printenv PATH
>> ...
>> :/cygdrive/c/Program Files (x86)/Common Files/Symbian/tools:
>> ...
>> $ make
>> cygwin warning:
>>MS-DOS style path detected: /usr/local/bin/C:\Program
>>Pref
Thanks everyone for the very quick reply...
I first did as Vincent advised and installed a make on the cygwin itself...
and removed all the reference to the windows program files folder from the
path. Then it worked, but I think I will try what you've said Dave, if I
find anything useful I will p
Sunoki wrote:
$ printenv PATH
...
:/cygdrive/c/Program Files (x86)/Common Files/Symbian/tools:
...
$ make
cygwin warning:
MS-DOS style path detected: /usr/local/bin/C:\Program
Preferred POSIX equivalent is: /usr/local/bin/C:/Program
CYGWIN environment variable option "nodosfilewarning" t
On 30/01/2011 12:56, Tim Prince wrote:
> On 1/30/2011 6:34 AM, Sunoki wrote:
>>
>> $ make
>> cygwin warning:
>>MS-DOS style path detected: /usr/local/bin/C:\Program
>>Preferred POSIX equivalent is: /usr/local/bin/C:/Program
>>CYGWIN environment variable option "nodosfilewarning" turns o
On 1/30/2011 6:34 AM, Sunoki wrote:
$ make
cygwin warning:
MS-DOS style path detected: /usr/local/bin/C:\Program
Preferred POSIX equivalent is: /usr/local/bin/C:/Program
CYGWIN environment variable option "nodosfilewarning" turns off this
warning.
Consult the user's guide for more de
Greetings, All!
Ok, for those interested, solution for my specific case was found.
macro:post print("view:
Sorry for my terrible english...
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.htm
Greetings, Larry Hall (Cygwin)!
> diff.exe -cdb -x "CVS" -x ".svn" -I "\$Id.*\$" --strip-trailing-cr --
> "C:\...\php-tools\GalleryClass.php"
> "\\REMOTE\C$\...\php-tools\GalleryClass.php"
> diff: \REMOTE\C$\...\php-tools\GalleryClass.php: No such file or directory
>
> Why
On 8/17/2010 2:58 PM, Andrey Repin wrote:
Greetings, Csaba Raduly!
diff.exe -cdb -x "CVS" -x ".svn" -I "\$Id.*\$" --strip-trailing-cr --
"C:\...\php-tools\GalleryClass.php"
"\\REMOTE\C$\...\php-tools\GalleryClass.php"
diff: \REMOTE\C$\...\php-tools\GalleryClass.php: No such file or directory
W
Greetings, Csaba Raduly!
>>> diff.exe -cdb -x "CVS" -x ".svn" -I "\$Id.*\$" --strip-trailing-cr --
>>> "C:\...\php-tools\GalleryClass.php"
>>> "\\REMOTE\C$\...\php-tools\GalleryClass.php"
>>> diff: \REMOTE\C$\...\php-tools\GalleryClass.php: No such file or directory
>>>
>>> Why it ate the leading
On Tue, Aug 17, 2010 at 5:18 AM, Larry Hall (Cygwin) wrote:
> On 8/16/2010 10:03 PM, Andrey Repin wrote:
>> diff.exe -cdb -x "CVS" -x ".svn" -I "\$Id.*\$" --strip-trailing-cr --
>> "C:\...\php-tools\GalleryClass.php"
>> "\\REMOTE\C$\...\php-tools\GalleryClass.php"
>> diff: \REMOTE\C$\...\php-tools
On 8/16/2010 10:03 PM, Andrey Repin wrote:
Greetings, All!
Trying to find differences between local and remote file, I run into an issue:
diff.exe -cdb -x "CVS" -x ".svn" -I "\$Id.*\$" --strip-trailing-cr --
"C:\...\php-tools\GalleryClass.php" "\\REMOTE\C$\...\php-tools\GalleryClass.php"
diff:
Doh!Thanks Andy! I really over-thought that one. I did in
fact have an "oh" instead of the zero.2 hrs :(
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:
2010/1/21 Russ:
> Hello,
>
> I have cygwin installed in the default c:\cygwin location...
>
> I cannot get cygwin to see an executable in my path -- unless I
> change dirs down to the application location or run it with the
> absolute path.
>
> This works:
> r...@mycomputer ~
> $ /c/Apps/apache-
Dave Korn wrote:
> David Billinghurst wrote:
>
>> I won't release a fixed set of gmp packages at present as a new upstream
>> release gmp-4.3.2 is imminent (late December 2009). For the moment,
>> affected users will need to edit the installed libgmpxx.la file.
>
> The /usr/sbin/fix-libtool-sc
David Billinghurst wrote:
>
> I won't release a fixed set of gmp packages at present as a new upstream
> release gmp-4.3.2 is imminent (late December 2009). For the moment,
> affected users will need to edit the installed libgmpxx.la file.
The /usr/sbin/fix-libtool-scripts-for-latest-gcc-runt
On 04/01/2010 08:07, David Billinghurst wrote:
As discussed previously [1], libraries built with libtool that depend on
libstdc++ end up with the full path to the build compiler's libstdc++.la
file in their own *.la file. This becomes a problem when the compiler is
upgraded.
/usr/sbin/fix-libto
The following 2 steps worked for me
1) Use semicolon as path separator
2) Enclose the whole path string inside double quote
Example
javac -classpath ".;poi-3.2-FINAL-20081019.jar" SR.java
--
View this message in context:
http://www.nabble.com/path-separator-tp17704083p22813149.html
Sent from
H Le wrote:
Hello,
I wonder where is this lib located? I have installed cygwin under
^^^
You mean header or include file.
d:\cygwin directory. Thank you for your helps.
I can't answer your question directly but I think I can help you answer
it.
From the main Cygw
> From: samitj
> Subject: Re: path separator
>
>
> hmm... i thought cygwin emulates a unix shell in windows.
> $ echo $PATH
> /usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/cygdrive/c/WINDOW
> S/system32:/cygdri.
>
> anyway, if i use a windows separator (;), it d
hmm... i thought cygwin emulates a unix shell in windows.
$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/cygdrive/c/WINDOWS/system32:/cygdri.
anyway, if i use a windows separator (;), it doesnt work and it considers it
the end of the command as per unix shell behavior.
dont know i
samitj wrote:
what is the path separator in Cygwin for paths, classpaths etc..
this works...
$ java -cp lib/matrix/matrix.jar
com.test.matrix.simulation.SimulationApplication
this fails..
$ java -cp lib/matrix/matrix.jar:bin/
com.test.matrix.simulation.SimulationApplication
Exception in thread
On Fri, Jun 6, 2008 at 9:17 PM, samitj <[EMAIL PROTECTED]> wrote:
>
> Hi,
> what is the path separator in Cygwin for paths, classpaths etc..
>
> this works...
> $ java -cp lib/matrix/matrix.jar
> com.test.matrix.simulation.SimulationApplication
Java is not a Cygwin package. You must be running th
I don't see this package as even been downloaded.
I thought I had set it to download everything... why am I missing it
in the first place? I don't even see it in the local package folder I
had cygwin install download to.
Shai
On Jan 23, 2008 5:29 PM, Dave Korn <[EMAIL PROTECTED]> wrote:
> On 23 J
On 23 January 2008 15:08, Shai wrote:
> Oops... my bad, here is an updated one:
>
> bash-3.2$ cygcheck /bin/cvs.exe
> C:\cygwin\bin/cvs.exe
> Error: could not find cygcrypt-0.dll
Like I guesed, a missing DLL. So re-run setup.exe; it should pick up the
dependency.
If for any reason you don'
Oops... my bad, here is an updated one:
bash-3.2$ cygcheck /bin/cvs.exe
C:\cygwin\bin/cvs.exe
Error: could not find cygcrypt-0.dll
C:\cygwin\bin\cygwin1.dll
C:\WINDOWS\system32\ADVAPI32.DLL
C:\WINDOWS\system32\ntdll.dll
C:\WINDOWS\system32\KERNEL32.dll
C:\WINDOWS\system32\R
bash-3.2$ cygcheck /bin/cvs.exe
bash: cygcheck: command not found
bash-3.2$
:(
Shai
On Jan 23, 2008 4:38 PM, Dave Korn <[EMAIL PROTECTED]> wrote:
> On 23 January 2008 13:59, Shai wrote:
>
> > Could it be that the package/s have been downloaded badly?
> > I've asked Cygwin to first download witho
On 23 January 2008 13:59, Shai wrote:
> Could it be that the package/s have been downloaded badly?
> I've asked Cygwin to first download without installing the packages to
> my local server and only then ran the cygwin installation and asked it
> to install from the local downloaded directory.
> I
Could it be that the package/s have been downloaded badly?
I've asked Cygwin to first download without installing the packages to
my local server and only then ran the cygwin installation and asked it
to install from the local downloaded directory.
If a package was broken, would I know about this?
On 23 January 2008 13:06, Shai wrote:
> when trying
> to run any command I get a "command not found" type result.
> Now, if I cd /bin and type the command ./ls.exe I get the list of the
> directory, but if I try something like ./cvs.exe .. I get the bash
> again. Meaning, no output.
> $ /bin/cv
On Mon, Aug 22, 2005 at 06:42:36AM -0700, Brian Dessent wrote:
>Corinna Vinschen wrote:
>>I don't agree with you that /../ components are actually seldom in path
>>expressions. If you examine typical source trees, you'll find that
>>expressions as -I../../foo/bar or -L/path/to/bin/../lib are used
On Mon, Aug 22, 2005 at 06:40:54AM -0600, Eric Blake wrote:
>How often does the substring /../ actually appear in path name
>resolution?
You're asking questions and arguing without actually looking at the
source code. It doesn't only matter how often something like this
happens. It also matters
Corinna Vinschen wrote:
> I don't agree with you that /../ components are actually seldom in path
> expressions. If you examine typical source trees, you'll find that
> expressions as -I../../foo/bar or -L/path/to/bin/../lib are used quite
> often.
Indeed. Even just "gcc hello.c" has to wade th
On Aug 22 06:40, Eric Blake wrote:
> How often does the substring /../ actually appear in path name resolution?
> I don't think it is all that often, and the penalty for getting that
> corner case POSIXly correct need not affect the common case when /../ is
> not part of the path name. Besides, t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Christopher Faylor on 8/21/2005 9:17 PM:
> I really don't care about POSIX in this case because I don't care about
> slavish adherence to POSIX standards at the expense of decreasing cygwin
> performance, adding a lot of complexity, or rem
Eric Blake wrote:
Cygwin will accept the path "dir/../file" as being the same as "file",
regardless of whether "dir" exists. Apprently, someone decided that a
simple path-trimming rule would speed things up, but it is wrong. For
example, it breaks building of xedit/lisp, where "lisp/../xedit.h"
On Sun, Aug 21, 2005 at 09:58:40PM -0500, Gary R. Van Sickle wrote:
>Cgf wrote:
>
>[snip]
>
>> I think it's a pretty hard problem and I really don't care
>> about POSIX
>
>??? This must be a typo, or you wouldn't be here.
You're right. It wasn't a typo but it was too strongly stated. I
really
Cgf wrote:
[snip]
> I think it's a pretty hard problem and I really don't care
> about POSIX
??? This must be a typo, or you wouldn't be here.
--
Gary R. Van Sickle
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Do
On Sun, Aug 21, 2005 at 10:31:47PM +, Eric Blake wrote:
>>Cygwin will accept the path "dir/../file" as being the same as "file",
>>regardless of whether "dir" exists. Apprently, someone decided that a
>>simple path-trimming rule would speed things up, but it is wrong. For
>>example, it breaks
> Cygwin will accept the path "dir/../file" as being the same as "file",
> regardless of whether "dir" exists. Apprently, someone decided that a
> simple path-trimming rule would speed things up, but it is wrong. For
> example, it breaks building of xedit/lisp, where "lisp/../xedit.h" is
> not
Ross MacGillivray yahoo.ca> writes:
>
>
> I am trying to test KDE 3.4 (and Qt 3.3) on Cygwin.
>
> I have installed the additional packages needed for
> KDE 3.4 and I even did a
> complete re-install of all packages to ensure that I have a clean system.
>
> when I start bash and enter 'echo $
> > when I start bash and enter 'echo $path'. This is the path statement
> > returned.
>
> Not sure how you've got things setup, but `echo $path` should result in
> an empty return statement. the variable is PATH not path, case
> sensitive.
>
Or maybe you are thinking of tcsh syntax, wher
Ross MacGillivray wrote:
> I am trying to test KDE 3.4 (and Qt 3.3) on Cygwin.
>
> I have installed the additional packages needed for KDE 3.4
> and I even did a complete re-install of all packages to
> ensure that I have a clean system.
>
> when I start bash and enter 'echo $path'. This is the
Karl M wrote:
>>> While looking at my PATH environment variable (in response to the
>>> recent postings about sshd and environment variables), I noticed
>>> that "." was included.
>>>
>>> It was caused by a double ; ( a ";;" sequence) in my PATH as
>>> defined in the Windows XP My Computer Proper
On Wed, 25 May 2005 11:58:45 -0700, Yitzchak Scott-Thoennes wrote:
> On Wed, May 25, 2005 at 11:28:43AM -0700, Karl M wrote:
>> Hi All...
>>
>> While looking at my PATH environment variable (in response to the recent
>> postings about sshd and environment variables), I noticed that "." was
>> i
On Wed, May 25, 2005 at 11:28:43AM -0700, Karl M wrote:
> Hi All...
>
> While looking at my PATH environment variable (in response to the recent
> postings about sshd and environment variables), I noticed that "." was
> included.
>
> It was caused by a double ; ( a ";;" sequence) in my PATH as
On Mon, May 16, 2005 at 10:19:34AM -0400, Christopher Faylor wrote:
>On Mon, May 16, 2005 at 06:53:26AM -0600, Eric Blake wrote:
>>According to Stefan Schuerger on 5/15/2005 4:41 PM:
>>>bash: test./test2: No such file or directory
>>>
>>>The trailing dot disappears and cannot be used in paths. Thi
On Mon, May 16, 2005 at 06:53:26AM -0600, Eric Blake wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>According to Stefan Schuerger on 5/15/2005 4:41 PM:
>> bash: test./test2: No such file or directory
>>
>> The trailing dot disappears and cannot be used in paths. This seems to
>> be a DO
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Stefan Schuerger on 5/15/2005 4:41 PM:
> bash: test./test2: No such file or directory
>
> The trailing dot disappears and cannot be used in paths. This seems to
> be a DOS legacy of either NTFS or Windows.
Yes - Windows strips all traili
At 06:41 PM 5/15/2005, you wrote:
>Today I noticed with streamripper that Cygwin appears to have a problem
>with trailing dots in paths:
>
>> mkdir test. ; echo > test./test2
>bash: test./test2: No such file or directory
>
>The trailing dot disappears and cannot be used in paths. This seems to
>be
On 1 Apr, Igor Pechtchanski wrote:
> On Fri, 1 Apr 2005, Luke Kendall wrote:
>
> > On 1 Apr, To: [EMAIL PROTECTED] wrote:
> ^
> Eh? :-)
A peculiarity of my MUA, when used to reply to my own messages. Sorry.
[...]
> > While just checking that, I also discov
Eric Blake <[EMAIL PROTECTED]> wrote:
> How about it - does it make sense to add an --xdev option to all of the
> recursive descent tools (chown, chmod, ls, ...) to force the recursion to
> stop at mount points, or is find/xargs the only supported idiom for this?
It's seductive, but I don't think
Eric Blake wrote:
> [moving feature request portion of thread to bug-coreutils]
>
> According to Luke Kendall on 4/1/2005 12:11 AM:
> find / -xdev -user "$USER" -print0 | xargs -0 chown Administrators.SYSTEM
> >>>
> >>> You must mean 'chown -R --from="$USER" ...' :-)
> >>
> >> Hmm, sound
On Fri, 1 Apr 2005, Luke Kendall wrote:
> On 1 Apr, To: [EMAIL PROTECTED] wrote:
^
Eh? :-)
> > > You must mean 'chown -R --from="$USER" ...' :-)
> >
> > Hmm, sounds better still. :-)
>
> D'oh! Not possible: there's no -xdev option on chown, so that would
> d
1 - 100 of 184 matches
Mail list logo
