Re: default PATH
On Sat, February 11, 2006 8:41 pm, Christopher Faylor wrote: > We're > just trying go figure out if removing the ;; translation will affect > many people. We're not looking to add things to the PATH. > > There is a tradeoff here and I don't believe that we really know what > the implications are. You can speculate that thousands of people are > affected by the ;; problem but we haven't had very many complaints about > this and certainly people who are relying on ;; are not going to be > sending email here since Cygwin is working as they expect. > > Also, while skipping empty elements is a trivial operation, it is not > without cost. Every time that we have to guard the user against > something like this, we add another nail to the "cygwin is slow" coffin. Would a reasonable solution would be to make the PATH environment variable a special case and parse it when set? (Appologies if this isn't a reasonable solution) John. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: make: rm: command not found
On Sat, Feb 11, 2006 at 03:15:37AM -0800, Tim Prince wrote: > At 08:40 AM 2/10/2006, JefV wrote: > >-- > >View this message in context: > >http://www.nabble.com/make%3A-rm%3A-command-not-found-t1100243.html#a2873151 > >Sent from the Cygwin Users forum at Nabble.com. > > > > > >-- > >Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > >Problem reports: http://cygwin.com/problems.html > >Documentation: http://cygwin.com/docs.html > >FAQ: http://cygwin.com/faq/ > > > > > > > >SPAM: -- Spamnix Spam Report -- > >SPAM: Spamnix identified this message as spam. > >SPAM: Score: 52 > >SPAM: Action: Quarantine > >SPAM: --- End of Spamnix Spam Report -- > > How many of us do you expect to be viewing your message with spam > filtering off? Why should your spam filtering be of any concern to anyone posting to the list? Perhaps if you were to figure out what contributed to that 52 score and make a concrete suggestion, it would be helpful. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: default PATH
On Feb 11 15:24, Stephan Mueller wrote: > cgf wrote: > " So, I don't think this really answers Corinna's question. I believe that > " she was looking for documentation which stated that ;; was ignored, not > " reasoning which implies it. > > In the absence of the former, I'd hope the latter would be better than > nothing. > I'd also consider that the text from PATH ? counts as documentation, and > conclusions drawn from the results of doing exactly what it says to be worth > something. It's interesting but the real conclusion drawn from that is still by guessing. I'm still curious if there exists some piece of description from Microsoft as to how empty paths in %PATH% are handled. > Right now, sloppy Windows paths with ;; happen to result in dot getting added > to Cygwin paths, as you say. This leads to Windows users with sloppy paths > having their expectations being met but in a roundabout, somewhat arbitrary > way. I won't speculate on how many people have problems with ;;. What I > do think is that translating ;; as empty and explicitly prepending . is > straightforward, faithful to Windows users expectations and more > deterministic, > since it doesn't rely on the side effects of sloppy installers. > > However, as is often the case where backwards compatibility is paramount, > doing nothing is a fine approach too. Me, I have my dots in my paths where > I want them, and don't have a sloppy Windows path anywhere. > > " Also, while skipping empty elements is a trivial operation, it is not > " without cost. Every time that we have to guard the user against > " something like this, we add another nail to the "cygwin is slow" coffin. > > Performance matters, but I hesitate to invoke it against correctness. That > is, > if there were consensus that skipping empty elements is the right answer, then > I'd hope that Cygwin would skip empty elements, even if it is an extra if and > a few more cycles in a common code path. If there's no consensus on skipping > empty elements, and absolutely everything else is equal, then sure, go with > what's faster. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: default PATH
On Feb 12 08:44, John Morrison wrote: > On Sat, February 11, 2006 8:41 pm, Christopher Faylor wrote: > > We're > > just trying go figure out if removing the ;; translation will affect > > many people. We're not looking to add things to the PATH. > > > > There is a tradeoff here and I don't believe that we really know what > > the implications are. You can speculate that thousands of people are > > affected by the ;; problem but we haven't had very many complaints about > > this and certainly people who are relying on ;; are not going to be > > sending email here since Cygwin is working as they expect. > > > > Also, while skipping empty elements is a trivial operation, it is not > > without cost. Every time that we have to guard the user against > > something like this, we add another nail to the "cygwin is slow" coffin. > > Would a reasonable solution would be to make the PATH environment variable > a special case and parse it when set? (Appologies if this isn't a > reasonable solution) Er... how does this match the question? %PATH% always exists and so it has always to be parsed to create $PATH. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: default PATH
On Feb 11 20:22, Eric Blake wrote: > I strongly oppose option 3 - cygwin should never add '.' implicitly to the > front of a POSIX path - if you are crazy enough to want dot there, put > it there yourself explicitly. But I like option 2, of squeezing ';;' into a > single ':' (avoiding the implicit dot of $PATH '::'), and ignoring trailing > ';' > (again, avoiding the implicit dot of $PATH trailing ':'). If the user wants > dot in the middle or at the end, automagically converted from > the Windows %PATH%, then they can explicitly use ';.;' or trailing > ';.' to make their intent clear. And since Windows always implicitly > prepends '.' to %PATH%, this might cut down on the traffic to this > list of "how did . get on my $PATH?". (Although it will probably > increase the traffic of "why did ;; get turned into : instead of ::?") That's unavoidable. Whatever you do, somebody will complain. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: make: rm: command not found
Yitzchak Scott-Thoennes wrote: On Sat, Feb 11, 2006 at 03:15:37AM -0800, Tim Prince wrote: At 08:40 AM 2/10/2006, JefV wrote: -- View this message in context: http://www.nabble.com/make%3A-rm%3A-command-not-found-t1100243.html#a2873151 Sent from the Cygwin Users forum at Nabble.com. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ SPAM: -- Spamnix Spam Report -- SPAM: Spamnix identified this message as spam. SPAM: Score: 52 SPAM: Action: Quarantine SPAM: --- End of Spamnix Spam Report -- How many of us do you expect to be viewing your message with spam filtering off? Why should your spam filtering be of any concern to anyone posting to the list? Perhaps if you were to figure out what contributed to that 52 score and make a concrete suggestion, it would be helpful. You don't think that the nabble URL and ad have any effect on spam filter triggering? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.5.19: timeval struct not correct defined
On Feb 11 19:59, Johnny Willemsen wrote:
> Hi,
>
> In sys/time.h the timeval struct is defined as:
>
> struct timeval {
> long tv_sec;
> long tv_usec;
> };
>
> It should be
>
> struct timeval {
> time_t tv_sec;
> suseconds_t tv_usec;
> };
>
> See the following link for the opengroup standard
> http://www.opengroup.org/onlinepubs/007908799/xsh/systime.h.html
>
> The type suseconds_t and useconds_t are also not there with Cygwin
useconds_t is defined in sys/types.h, though as signed type, not as
unsigned type as proposed by SUSv3.
As for the other types, I'll prepare a patch for newlib's header files.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: default PATH
On Sun, February 12, 2006 11:58 am, Corinna Vinschen wrote: > On Feb 12 08:44, John Morrison wrote: >> On Sat, February 11, 2006 8:41 pm, Christopher Faylor wrote: >> > We're >> > just trying go figure out if removing the ;; translation will affect >> > many people. We're not looking to add things to the PATH. >> > >> > There is a tradeoff here and I don't believe that we really know what >> > the implications are. You can speculate that thousands of people are >> > affected by the ;; problem but we haven't had very many complaints >> about >> > this and certainly people who are relying on ;; are not going to be >> > sending email here since Cygwin is working as they expect. >> > >> > Also, while skipping empty elements is a trivial operation, it is not >> > without cost. Every time that we have to guard the user against >> > something like this, we add another nail to the "cygwin is slow" >> coffin. >> >> Would a reasonable solution would be to make the PATH environment >> variable >> a special case and parse it when set? (Appologies if this isn't a >> reasonable solution) > > Er... how does this match the question? %PATH% always exists and so > it has always to be parsed to create $PATH. Humm, sorry - sleep deprived. Was thinking that it would only need to be parsed once (don't know the internals of cygwin very well) rather than the (possibily, if I read correcly, implied) multiple times. J. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: default PATH
On Feb 12 13:52, John Morrison wrote: > On Sun, February 12, 2006 11:58 am, Corinna Vinschen wrote: > > On Feb 12 08:44, John Morrison wrote: > >> Would a reasonable solution would be to make the PATH environment > >> variable > >> a special case and parse it when set? (Appologies if this isn't a > >> reasonable solution) > > > > Er... how does this match the question? %PATH% always exists and so > > it has always to be parsed to create $PATH. > > Humm, sorry - sleep deprived. Was thinking that it would only need to be > parsed once (don't know the internals of cygwin very well) rather than the > (possibily, if I read correcly, implied) multiple times. PATH is always parsed and transformed in the "other" syntax when a Cygwin process is started from a native Win32 process and vice versa, which makes sort of sense, I hope :-) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: default PATH
On Sun, Feb 12, 2006 at 01:03:18PM +0100, Corinna Vinschen wrote: >On Feb 11 20:22, Eric Blake wrote: >>I strongly oppose option 3 - cygwin should never add '.' implicitly to >>the front of a POSIX path - if you are crazy enough to want dot there, >>put it there yourself explicitly. But I like option 2, of squeezing >>';;' into a single ':' (avoiding the implicit dot of $PATH '::'), and >>ignoring trailing ';' (again, avoiding the implicit dot of $PATH >>trailing ':'). If the user wants dot in the middle or at the end, >>automagically converted from the Windows %PATH%, then they can >>explicitly use ';.;' or trailing ';.' to make their intent clear. And >>since Windows always implicitly prepends '.' to %PATH%, this might cut >>down on the traffic to this list of "how did . get on my $PATH?". >>(Although it will probably increase the traffic of "why did ;; get >>turned into : instead of ::?") > >That's unavoidable. Whatever you do, somebody will complain. And that is precisely why I suggested asking for feedback in the mailing list. I was wondering if there might be at least a couple of people who would say "Please don't do this because I rely on this behavior". I don't mind protecting people against the evil 3PP which corrupt the PATH but, as I said, since we don't get that many complaints about the current behavior (which may actually have been in place for a decade) we don't want to necessarily penalize those smart people who have correctly deduced that Cygwin does a one-to-one translation to/from the windows path and have therefore put a ;; in their PATH expecting a translation to :: in the Cygwin path. If we don't get a single person indicating that they rely on the current behavior then I'm ok with changing it. We have a patch ready to be checked in, in fact. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: default PATH
On Sun, Feb 12, 2006 at 11:57:00AM -0500, Christopher Faylor wrote: > If we don't get a single person indicating that they rely on the current > behavior then I'm ok with changing it. We have a patch ready to be > checked in, in fact. I assume that: $ PATH="/foo::$PATH" cmd /c printenv PATH will continue to show /foo:./:yaddayadda with the patch? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] New Package: cairo-1.0.2-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The following packages have been added to the Cygwin net release: *** cairo-1.0.2-1 *** libcairo2-1.0.2-1 Cairo is a vector graphics library with cross-device output support. Currently supported output targets include the X Window System and in-memory image buffers. PostScript and PDF file output is planned. Cairo is designed to produce identical output on all output media while taking advantage of display hardware acceleration when available (eg. through the X Render Extension). This will be a prerequisite for gtk+-2.8 and some newer GNOME packages. Yaakov *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD76bspiWmPGlmQSMRAlo4AJ42C/3wXiiTL554cbbFkxIkb7+xLQCbBJu6 O9CNsVosWmizPwULXZ1QB5g= =e5TC -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: default PATH
On 10 February 2006 19:01, Corinna Vinschen wrote: > On Feb 8 18:59, Dave Korn wrote: >> >> Since POSIX semantics requires an empty path component to be treated as >> $CWD, but Win32 semantics require an empty path component to be ignored, > ^ > > How do you know that? Can you give me a pointer describing that? I > searched MSDN and KB and found not a word about how multiple semicolons > are treated by Win32 functions or cmd/command. This is tricky to test > since, for instance, CreateProcess searches the current directory anyway > before using %PATH% (see MSDN). You're right; it doesn't seem to be documented anywhere I can find. I may be remembering something from way back in DOS days. However, it is /in fact/ the case that empty path components are ignored, rather than treated as meaning "current dir": Microsoft Windows 2000 [Version 5.00.2195] (C) Copyright 1985-2000 Microsoft Corp. G:\>mkdir foo G:\>mkdir bar G:\>path G:\windows\system32;G:\windows;G:\foo;G:\bar;G:\nonexistent;G:\foo;G:\f oo;;G:\bar;G:\bar;G:\nonexistent;G:\nonexistent;;;G:\nonexistent;G:\fo o; G:\bar G:\>unfoundfilename.exe 'unfoundfilename.exe' is not recognized as an internal or external command, operable program or batch file. G:\>path G:\windows\system32;G:\windows;G:\foo;G:\bar;G:\nonexistent;G:\foo;G:\f oo;;G:\bar;G:\bar;G:\nonexistent;G:\nonexistent;;;G:\nonexistent;G:\fo o; G:\bar;.;G:\bar;.;G:\foo;;G:\foo G:\>unfoundfilename2.exe 'unfoundfilename2.exe' is not recognized as an internal or external command, operable program or batch file. G:\> ..as the attached Filemon logs show, all the path components are tested, including the nonexistent ones, but nothing at all is done for the empty path components. cheers, DaveK -- Can't think of a witty .sigline today Filemon.LOG Description: Binary data Filemon2.LOG Description: Binary data -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Gmsh Using Cygwin "Badly"
I just ran across a program, Gmsh (http://www.geuz.org/gmsh/, "an automatic 3D finite element grid generator (primarily Delaunay) with a build-in CAD engine and post-processor"), that does the "multiple cygwin1.dll's" thing. While the README acknowledges the issue, it offers the following incorrect advice on dealing with the situation: "2) About cygwin1.dll: If you plan to use other programs than Gmsh that depend on the cygwin1.dll library, you should keep only one version of this library on your system (i.e., move cygwin1.dll to the Windows system directory--usually C:\Windows\System\--and suppress all other versions of cygwin1.dll). Failing to do so may result in an incorrect behavior of applications sharing the library and running simultaneously." Gmsh folks: Putting cygwin1.dll in "C:\Windows\System\" is bad, don't do it, and don't recommend it to people. Just having cygwin1.dll in your path is sufficient. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
