Re: Adding/removing custom mirror URLs in setup.exe...
OK, convinced! ;-) Using the IE-connection type... Johan Robert Collins wrote: > > On Mon, 2003-01-20 at 21:25, Johan Bezem wrote: > > Maybe it doesn't parse the ftp://... string itself, but in our case it > > *works* nonetheless. > > Can it be that the string is passed to the FTP-server unaltered, and the > > Are you using the IE connection type, or the HTTP proxy type? If so, > then they perform that translation for you. > > Rob > -- > GPG key available at: <http://users.bigpond.net.au/robertc/keys.txt>. > > >Name: signature.asc >signature.asc Type: PGP Armored File >(application/x-unknown-content-type-PGP Armored File) > Description: This is a digitally signed message part -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Adding/removing custom mirror URLs in setup.exe...
Maybe it doesn't parse the ftp://... string itself, but in our case it *works* nonetheless. Can it be that the string is passed to the FTP-server unaltered, and the server knows how to process such a string? Ciao, Johan Bezem CSK Software AG Max Bowsher wrote: > > MB> > > Don't know whether setup understands usernames/passwords. I'll > MB> > >dig in the > MB> > > source tomorrow, if no one has answered by then. > > RC> > It should, Corinna IIRC uses ftp w/passwords. > > CV> No, I don't. > > OK, well I checked briefly in the source, here's the result: > > Setup DOES have *some* support for ftp auth, but DOES NOT understand > ftp://user:passwd@host/. Instead, it tries to pop up a dialog when > anonymous login fails. > > So: the original poster should try without user:pass@ in the URL. > > Max. > > -- > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > Bug reporting: http://cygwin.com/bugs.html > Documentation: http://cygwin.com/docs.html > FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Antw: Online Banking Kaputt?
Gerrit needs to take out the 'Reply-To' for cygwin-mails when sending private emails :-) Johan Bezem CSK Software AG Postbank Online Service wrote: > > Guten Tag, > > vielen Dank für Ihre E-Mail vom 08.11.2002. <...> -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ls -l /usr : where has /usr/bin gone ?
Hi Alex, cf: 'man mount' Ciao, Johan Bezem CSK Software AG Alex Vinokur wrote: > > = > Windows 2000 > CYGWIN_NT-5.0 > = > > Hi, > > Directory /usr/bin exists but missing in ls /usr . > Any explanation ? > - > > Administrator@5AT8S8CQEEX4QHI /usr > $ pwd > /usr > > Administrator@5AT8S8CQEEX4QHI /usr > $ ls -l > total 2 > drwxr-xr-x 11 Administ None0 Sep 30 20:08 X11R6 > drwxr-xr-x4 Administ None0 Sep 30 20:07 autotool > drwxr-xr-x 109 Administ None0 Sep 30 20:07 doc > drwxr-xr-x3 Administ None0 Sep 30 20:07 i686-pc-cygwin > drwxr-xr-x2 Administ None0 Sep 30 20:15 i686-pc-mingw32 > drwxr-xr-x 38 Administ None0 Sep 30 20:07 include > drwxr-xr-x2 Administ None0 Sep 30 20:07 info > drwxr-xr-x3 Administ None0 Sep 30 20:11 libexec > drwxr-xr-x5 Administ None0 Sep 30 20:07 local > drwxr-xr-x2 Administ None0 Sep 30 20:11 logs > drwxr-xr-x 19 Administ None0 Sep 30 20:07 man > drwxr-xr-x4 Administ None0 Sep 30 20:07 sbin > drwxr-xr-x 36 Administ None0 Sep 30 20:07 share > drwxr-xr-x2 Administ None0 Sep 30 20:07 src > drwxr-xr-x6 Administ None0 Sep 30 20:10 ssl > drwxr-xr-x2 Administ None0 Sep 30 20:07 tmp > drwxr-xr-x2 Administ None0 Sep 30 20:08 var > > Administrator@5AT8S8CQEEX4QHI /usr > $ cd bin > > Administrator@5AT8S8CQEEX4QHI /usr/bin > $ pwd > /usr/bin > >== >Alex Vinokur > mailto:[EMAIL PROTECTED] > http://up.to/alexvn >== > > -- > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > Bug reporting: http://cygwin.com/bugs.html > Documentation: http://cygwin.com/docs.html > FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Dos Style path in 3.79.1-7 and -5
Try using forward slahes like d:/utils/print.exe. I don't think the CygWin version of make has ever been equipped to handle unescaped backslahes. You may also try escaping them, like d:\\utils\\print.exe. Regards, Johan Bezem CSK Software AG Rami Mehio wrote: > > I have been using gnu make 3.79 on win32. The shell i use is cmd.exe. > > I have recently upgraded my cygwin tools including make to 3.79.1-5 (and > subsequently to -7). > > I seems that make no longer recognizes Dos style pathnames. So in a rule, if > i have > > target: > d:\utils\print.exe hello.txt > > if i do > > make target --win32 > > make does not recognize the d:\utils\print.exe path. > > This used to work fine for me before. > > Does anybody know anything about this? > > thanks > > -- > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > Bug reporting: http://cygwin.com/bugs.html > Documentation: http://cygwin.com/docs.html > FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [Patch] make 3.79.1-5 vpath directive in file 'read.c'
Hi,
sorry, I've been on vacation for two weeks, and now trying to catch up
with the mailing list.
Since supplying the patch, and already trying 3.79.1-7 in experimental
mode, I've come to an understanding about the FIXME comments, asking
whether such a conversion should only be applied when not in 'unixy'
mode ("unixy_shell != 0").
1. In the file vpath.c, the VPATH variable and the GPATH variable are
handled differently (GPATH only converts when unixy_shell == 0, VPATH in
any case); this is at least inconsequent, I'd suggest to remove the
'unixy_shell' condition in the GPATH case.
2. In the file read.c, the vpath directive includes a check for
"!unixy_shell", which I would like to have removed. The patch I provided
had no such condition, which let me use DOS-like pathnames for
VPATH/GPATH/vpath, whithout the need for explicit conversion, even when
using /bin/sh or bash from the CygWin distribution. This comes
in handy, since my makefiles are to be platform independent for Windows
(using CygWin) and several flavours of Unix where no cygpath/realpath
utilities are available, of course. Yes, ifeq can test for platforms,
but the makefile tends to become less readable if every path
specification must be bracketed with ifeq/else/endif's.
Is there a reason to retain the checks for "!unixy_shell"?
Regards,
Johan Bezem
CSK Software AG
PS: The cygwin website seems to be down at the moment, so I couldn't
check whether the released 3.79.1-7 is exactly the same as the
experimental 3.79.1-7 I downloaded on May 12th.
Christopher Faylor wrote:
>
> On Mon, Apr 22, 2002 at 10:44:05AM +0200, Johan Bezem wrote:
> >### ChangeLog ###
> >2002-04-22 Johan Bezem <[EMAIL PROTECTED]>
> >
> >* read.c (read_makefile) [__CYGWIN__]: Added a check for an empty vpath
> >pathname when converting DOS to canonical pathnames.
>
> There's a test version of make available now (or will be available soon
> on mirrors) which incorporates this patch.
>
> If you can confirm that it works, I'll release it officially.
>
> Send success or failure reports to the mailing list, please.
>
> Thanks for the patch,
> cgf
>
> --
> Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting: http://cygwin.com/bugs.html
> Documentation: http://cygwin.com/docs.html
> FAQ: http://cygwin.com/faq/
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
[Patch] make 3.79.1-5 vpath directive in file 'read.c'
Hi,
After supplying a patch on March 22nd
(http://sources.redhat.com/ml/cygwin/2002-03/msg01323.html), I've found
a bug in my patch, so I'll resubmit the fix. Before checking on zero
pointers, make occasionally crashed...
I checked the vpath.c file, it seems unaffected, so the patch delivered
is still valid.
The ChangeLog entry is new, the diff refers to the original file
'read.c', so this patch will apply both in one turn.
Have fun,
Johan Bezem
CSK Software AG
### ChangeLog ###
2002-04-22 Johan Bezem <[EMAIL PROTECTED]>
* read.c (read_makefile) [__CYGWIN__]: Added a check for an empty vpath
pathname when converting DOS to canonical pathnames.
### vpath.c-patch ###
--- read.orig.c Fri Mar 22 10:51:07 2002
+++ read.c Mon Apr 22 09:57:16 2002
@@ -648,6 +648,24 @@ read_makefile (filename, flags)
else
/* No pattern means remove all previous selective VPATH's. */
pattern = 0;
+
+/* CYGNUS LOCAL Cygwin */
+/* FIXME: should this conversion only take place when in
unixy_mode? */
+#ifdef __CYGWIN__
+if (p != 0)
+ {
+ /* if a win32 VPATH path list, convert to posix path list */
+if (!cygwin_posix_path_list_p (p))
+ {
+register char *posixp = (char *)
+alloca
(cygwin_win32_to_posix_path_list_buf_size (p));
+cygwin_win32_to_posix_path_list (p, posixp);
+p = posixp;
+ }
+ }
+#endif /* __CYGWIN__ */
+/* END CYGNUS LOCAL */
+
construct_vpath_list (pattern, p);
if (pattern != 0)
free (pattern);
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Make 'include' directive with Cygnus bash - path problem
Hi Ronnie, Ronnie Shipman wrote: > > > I have encountered a problem including makefiles. > > # Including this works > > include c:/RIS/Software/3G_Platform_2_5_make/makefile.test > > > > # Including this fails > > #include /cygdrive/c/RIS/Software/3G_Platform_2_5_make/makefile.test > > PATH='/usr/local/bin:/usr/bin:/bin:.:/cygdrive/c/ris/bin:/cygdrive/c/ti/bi > > n:/cygdrive/c/ti/c6000/cgtools/bin:/cygdrive/c/Tornado/host/x86-win32/bin: > > /cygdrive/c/gcc-2.95.2/bin:/cygdrive/c/mks/mkssi:/cygdrive/c/mks/mksnt:/cy > > gdrive/c/WINNT/system32:/cygdrive/c/WINNT:/cygdrive/c/WINNT/System32/Wbem: > > /cygdrive/c/oracle/ora81/bin:/cygdrive/c/Program > > Files/Oracle/jre/1.1.7/bin:/cygdrive/c/WINNT/system32:/cygdrive/c/WINNT:/c > > ygdrive/c/WINNT/System32/Wbem:/cygdrive/c/PROGRA~1/COMMON~1/Autodesk > > Shared/:/cygdrive/c/vslick/win' > > ROOTDIR=c:/mks > > GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. > > Built for Windows32 You seem to be running a non-cygwin version of GNU make 3.79.1. The CygWin version says: GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. Built for i686-pc-cygwin --^^ That version will not know about /cygdrive/... Try the cygwin version. Regards, Johan Bezem CSK Software AG -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Strange behaviour of vpath with dos paths
Christopher Faylor wrote:
> That means you send the ChangeLog entry (not the diff of a ChangeLog
> entry) and patch in clear text so that the barrier to inspecting your
> work is minimal. This is standard across every project that I am
> aware of.
Sorry for the attachment then. Here it's once again.
Regards,
Johan Bezem
CSK Software AG
### ChangeLog ###
2002-03-20 Johan Bezem <[EMAIL PROTECTED]>
* vpath.c (build_vpaths_list) [__CYGWIN__]: Added conversion of DOS-like pathname for
GPATH variable to canonical form.
* read.c (read_makefile) [__CYGWIN__]: Added conversion of DOS-like pathname for vpath
directive to canonical form.
### vpath.c-patch ###
--- vpath.orig.cFri Mar 22 10:50:38 2002
+++ vpath.c Wed Mar 20 16:50:35 2002
@@ -144,6 +144,20 @@ build_vpath_lists ()
will still be nil if P contains no existing directories. */
vpaths = 0;
+ /* CYGNUS LOCAL Cygwin */
+ /* FIXME: should this conversion only take place when in unixy_mode? */
+#ifdef __CYGWIN__
+ /* if a win32 VPATH path list, convert to posix path list */
+ if (!cygwin_posix_path_list_p (p))
+{
+ posixp = (char *)
+ alloca (cygwin_win32_to_posix_path_list_buf_size (p));
+ cygwin_win32_to_posix_path_list (p, posixp);
+ p = posixp;
+}
+#endif /* __CYGWIN__ */
+ /* END CYGNUS LOCAL */
+
/* Parse P. */
construct_vpath_list ("%", p);
### read.c-patch ###
--- read.orig.c Fri Mar 22 10:51:07 2002
+++ read.c Wed Mar 20 16:51:36 2002
@@ -648,6 +648,21 @@ read_makefile (filename, flags)
else
/* No pattern means remove all previous selective VPATH's. */
pattern = 0;
+
+/* CYGNUS LOCAL Cygwin */
+/* FIXME: should this conversion only take place when in unixy_mode? */
+#ifdef __CYGWIN__
+/* if a win32 VPATH path list, convert to posix path list */
+if (!cygwin_posix_path_list_p (p))
+ {
+register char *posixp = (char *)
+alloca (cygwin_win32_to_posix_path_list_buf_size (p));
+cygwin_win32_to_posix_path_list (p, posixp);
+p = posixp;
+ }
+#endif /* __CYGWIN__ */
+/* END CYGNUS LOCAL */
+
construct_vpath_list (pattern, p);
if (pattern != 0)
free (pattern);
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Strange behaviour of vpath with dos paths
Christopher Faylor wrote: > >So, my question: Where can I find the repository of the CygWin make > >package? Or otherwise, how to proceed from here? > > You can't. Use the make source tarball and submit ChangeLog + patch > here. OK, here it goes. I'm not aware of standard testing procedures or requirements for CygWin, so maybe someone could double-check. I used diff -up .orig.c .c > .c-patch 2>&1 for both vpath.c and read.c, files attached. HTH, Johan Bezem CSK Software AG dospathpatch.tar.bz2 Description: Binary data -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Strange behaviour of vpath with dos paths
Hi, OK, so I think I fixed the problem with the vpath directive, I fixed another related problem on the way (the GPATH variable shows the same symptoms), I tested both fixes on my machine, and wrote a ChangeLog entry. Now, I want to contribute these fixes into the development chain for CygWin make. The GNU make project (http://savannah.gnu.org/projects/make) does not contain the CygWin enhancements in its main development tree, but in order to provide a valid diff, I'd have to incorporate my changes into the latest CVS version and perform a diff, rather than using the sources from the latest CygWin distribution. I checked the CVS repository sources.redhat.com, but it seems to contain only the core of the CygWin DLL's sources. So, my question: Where can I find the repository of the CygWin make package? Or otherwise, how to proceed from here? Thanks, Johan Bezem CSK Software AG Colm Aengus Murphy wrote: > > Hi folks, > > I am seeing strange behaviour when using dos paths in a gnu make vpath > directive. > The makefile I am using to test this funny is as follows: > > --- > vpath %.out c:/make_test/out > #vpath %.out /cygdrive/c/make_test/out > > #VPATH = c:/make_test/out > #VPATH = /cygdrive/c/make_test/out > > test.out : \ >test.input\ >; echo test.input > out/test.out > --- > > What I find is that vpath doesn't work when given a dos path. > VPATH on the other hand does. > > For out application we need to use a dos path. > The work around is for us to use VPATH but it seems a bit funny that > vpath and VPATH behave differently under given dos paths. > > Has anyone any ideas about this ? > > Cheers > > Colm A > > P.S. I am using gnu make 3.79.1-4 and 1.3.5-2 of the cygwin dll. > > -- > - > Colm Aengus Murphy,Tel : +353 1 2911000 > Senior Hardware Design Engineer, Direct Tel: +353 1 2911373 > Silicon & Software Systems,Fax : +353 1 2911001 > South County Business Park, > Leopardstown, E-mail: [EMAIL PROTECTED] > Dublin 18. WWW : www.s3group.com > Ireland > - > > -- > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > Bug reporting: http://cygwin.com/bugs.html > Documentation: http://cygwin.com/docs.html > FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Strange behaviour of vpath with dos paths
Soren Andersen wrote: > > On 28 Feb 2002 at 11:24, Colm Aengus Murphy wrote: > > > Hi Johan, > > > > I took a quick look at source code for make 3.79.1-5. > > > > It looks to me like vpath.c (build_vpath_lists) does conversion of Win32 > > paths to posix ones for the VPATH variable but not for vpath. Not being a > > software programmer I'm not in a position to provide a patch, but maybe > > someone else could ? > > > > Colm A > > I am not a software programmer either ;-) (irregardless of the apparent assumptions >made > about me in the past on this List) -- at least not really a "C" programmer (rather, >japh-er) but > I will take a look at this and see if I can fix it. Mind you, I wouldn't hold my >breath or base > my plans for a major product roll-out on my quick success; I have not yet ever tried >to build > `make' from source, so that's the first and possibly not trivial hurdle. Maybe >somebody else > will therefore get there before me, but I thought I'd offer you assurance now that >at least > one pair of eyeballs out here will be looking into this. > > Luck, > Soren Andersen OK, here's some help. I suppose I dare call myself a programmer :), even though I haven't tried creating make from it's sources... In vpath.c lines 103-112 the CygWin specific path conversion is taken care of in the VPATH variable case. In the GPATH variable case (line 138-154), it looks like GPATH is not converted either. This would need some testing, but I suppose GPATH is hardly a regularly used feature... Copying lines 101-114 after line 146 should take care of that omission; the variable 'posixp' has been defines and used previously, but should still be in scope (lines 64-66), so it may be doubly used (unclean, but workable). The vpath directive is processed somwhere else. The only occurrence of the function 'construct_vpath_list' outside of vpath.c (and make.h for a prototype) is read.c In read.c lines 637-656, the directive is processed. And, alas, no CygWin processing of DOS-like paths there. Copying the same lines from vpath.c into read.c after line 652 might be all that's needed, but without actually doing the work+test, it's hard to tell whether everything is in scope. Be sure to define a variable 'posixp' in this case, however. If I find a few free minutes, I'll continue from here, but maybe this is enough input for you already. HTH, Johan -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Strange behaviour of vpath with dos paths
Hi, Colm Aengus Murphy wrote: > > Hi folks, > > I am seeing strange behaviour when using dos paths in a gnu make vpath > directive. > The makefile I am using to test this funny is as follows: > > --- > vpath %.out c:/make_test/out Error! > #vpath %.out /cygdrive/c/make_test/out Works. > > #VPATH = c:/make_test/out Works. > #VPATH = /cygdrive/c/make_test/out Works. > > test.out : \ >test.input\ >; echo test.input > out/test.out > --- > > What I find is that vpath doesn't work when given a dos path. > VPATH on the other hand does. Thanks, this is exactly the same problem I've seen just yesterday. > P.S. I am using gnu make 3.79.1-4 and 1.3.5-2 of the cygwin dll. Here: 3.79.1-5 and 1.3.9-1 respectively. After upgrading to 1.3.10-1 just yet, the problem persists. I'd say, this is a real candidate for a bug. Anyone else? Thanks, Johan Bezem CSK Software AG -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin 1.3.9 - gcc isn't working!
[EMAIL PROTECTED] wrote: > > Here goes: > 701k 2001/12/04 C:\WINNT\cygwin1.dll - os=4.0 img=1.0 sys=4.0 > "cygwin1.dll" v0.0 ts=2001/9/13 0:54 > Cygwin DLL version info: > DLL version: 1.3.3 > 751k 2002/01/21 C:\cygwin\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0 > "cygwin1.dll" v0.0 ts=2002/1/21 14:48 > Cygwin DLL version info: > DLL version: 1.3.9 Get rid of the second cygwin1.dll in your WINNT directory (version 1.3.3). This has the potential of causing all kinds of trouble... Ciao, Johan Bezem CSK Software AG -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
