Re: Design issue
Herold Heiko wrote: I think the most straightforward mapping would also be the most attractive: ftp/site/dir/file http/site/dir/file Wget should certainly have an option to make it behave this way. In fact, I'd prefer it to behave that way by default, for the reasons you mention, and introduce an option to leave off the protocol. I agree. What about https ? What about answering on more than one port like java.sun.com used to do where :80 had a java menu and :81 not. This is a bad example as it was mostly the same web-site The files could be either in a separate https directory (logically more correct) or reside in the http directory in order to minimize ../../../../dir/dir/dir/something url rewriting (since I suppose those pages could share lots of inline pics and other links with the http structure). Speaking of https, I got exactly one report (in private mail) of successfully testing of the windows ssl enabled binary, nothing else. Could you commit the patch as http://www.mail-archive.com/wget@sunsite.dk/msg00142.html ? The changes in gen_sslfunc.c could be needed anyway for other operating systems (the are mirrored from similar code in sysdep.h and http.c, although I just noticed a inconditional include of time.h in ftpparse.c), while the changes in the VC makefile are as default commented out. Heiko -- -- PREVINET S.p.A.[EMAIL PROTECTED] -- Via Ferretto, 1 ph x39-041-5907073 -- I-31021 Mogliano V.to (TV) fax x39-041-5907087 -- ITALY Hack 8-)
Re: publishing the output of a JSP page to a static HTML file
Roberto Viana [EMAIL PROTECTED] writes: Hi there, I'm using wget to mirror(convert) the output of a dynamic site that only contains JSP pages to a static site that serves only HTML files. The -E option give me the opportunity to convert *.jsp extensions into *.html extensions, however this brings me into another problem. Most of the pages contains links (embedded in the html) pointing to *.jsp files. So when I want to publish the wget generated HTML files, the links inside these pages are still pointing to *.jsp files that no longer exist, because of course all the extensions were changed from *.jsp to *.html. - Is it possible for wget to convert these internal links to *.html ones? Thanks for any ideas you can provide me. Roberto. Sorry, Roberto. More coding is simply needed in that area. --- Dan Harkless| To help prevent SPAM contamination, GNU Wget co-maintainer | please do not mention this email http://sunsite.dk/wget/ | address in Usenet posts -- thank you.
Re: Spaces in the filenames
[EMAIL PROTECTED] writes: Hi, I downloaded some files from a non unix system where the name of these files contains some spaces (blank character) too. My problem is that when I look at my downloaded files (on my unix system) I see %20 instead of the spaces in the filenames ! Is there an option to download the file without changing the spaces into %20, or anything else to solve this problems ? Not at the moment, other than downloading the files one-by-one and using the -O option. It's a known issue and a fix is planned. --- Dan Harkless| To help prevent SPAM contamination, GNU Wget co-maintainer | please do not mention this email http://sunsite.dk/wget/ | address in Usenet posts -- thank you.
windows binary (was wget 1.5.2 query)
On Thu, 8 Feb 2001, Hack Kampbjrn wrote: + Note that the latest version is 1.6. Take a look at the web-site + http://sunsite.dk/wget I can't see 1.6 as a windows binary anywhere? Both windows binary links are still showing 1.5.3. Does anyone have 1.6 available as a windows binary? regards, Malcolm. [EMAIL PROTECTED] http://users.ox.ac.uk/~malcolm/
Re: Design issue
Jan Prikryl [EMAIL PROTECTED] writes: Quoting Dan Harkless ([EMAIL PROTECTED]): I don't see why we would use an '_' instead of a ':' on the second version (except on Windows if the ':' character is a no-no there). The colon is a relict of DOS path notation (C:\) so it cannot appear in a filename. Fine, but I'm not really up for obfuscating the URLs on UNIX just to make DOS/Windows happy. Already the Windows port has to deal with more characters being non-allowed in filenames than on UNIX. This is just another one. --- Dan Harkless| To help prevent SPAM contamination, GNU Wget co-maintainer | please do not mention this email http://sunsite.dk/wget/ | address in Usenet posts -- thank you.
Re: Design issue
On Fri, 9 Feb 2001, Dan Harkless wrote: Jan Prikryl [EMAIL PROTECTED] writes: The colon is a relict of DOS path notation (C:\) so it cannot appear in a filename. Fine, but I'm not really up for obfuscating the URLs on UNIX just to make DOS/Windows happy. Already the Windows port has to deal with more characters being non-allowed in filenames than on UNIX. This is just another one. Clearly, the non-unix ports can be modified to deal with incompatible filenames. I think this is more a question of whether you intentionally want to create portability problems when creating new code. There is no question that portability comes at a price. In this case it is loss of the exact URL in the new filepath. From a systems viewpoint, it seems much simpler to avoid problem code rather than assume that someone can create a workaround for those systems where it doesn't work. This just adds to the complexity of maintaining the code. The created path is an indication of the origin of the files, not necessarily a full URL. As noted in other posts, the protocol name has not previously been included in the path, so this has never been the full URL. Perhaps I am too used to DOS and Windows ports of unix programs, but the mentioned alternatives to the colon in the filename all looked reasonable and intuitive to me. I didn't perceive any obfuscation. Doug __ Doug Kaufman Internet: [EMAIL PROTECTED]
