RE: How to monitor web pages for changes?
From: Gary Funck [mailto:[EMAIL PROTECTED]] Can someone recommend a simple, efficient way to monitor a list of various web pages (or in some cases, a hierarchy of pages) for changes, and then Ha! Another one bitten by Netminds end-of-free-service. I'm toying with the same idea, just didn't have time for it (yet). Heiko -- -- PREVINET S.p.A.[EMAIL PROTECTED] -- Via Ferretto, 1ph x39-041-5907073 -- I-31021 Mogliano V.to (TV) fax x39-041-5907087 -- ITALY
WGet 1.8.1
Hello I'm using WGet 1.8.1 for downloading files over FTP protocol. when filename contain spaces url is like that ftp://server.name/file%20name and it saves files also with %20 in file names Prior I was using WGet 1.7 and it saved spaces as the should be. My OS is RedHat 7.2 I tried w32 version also, but it puts @20 into filenames. Is it a bug or just a feature ? Lauri Magi
It's only for you !!
Hyundai Trade corporation is a general trade company and reliable source in korea. We would like to introduce you more attractive products as follows. Please review and let's know your interest at your convenient time. And then we will provide all information without hesitation. ***Business lines*** 1)DVD player 2)Car security system 3)USB flash drive 4)Instant cellphone charger 5)TFT LCD monitor, 18.1 6)LCD PC 7)Fingerprint lock system 8)Helicopter (hobby product) 9)Cordless internet phone 10)Flash memory cards Sincerely Yours, If you are interested in getting sample and entering into business with this product feel free to contact us without hesitation. Mr. Seok-Do Yoo/Manager Hyundai Trade Corporation URL:http://www.hyundaitrade.com Email: [EMAIL PROTECTED] Tel:82-2-459-3123 Fax:82-2-3411-3118 Address:Missy 860 O/T. room No.604, 13-3 Kaepo-Dong, Kangnam-Gu, Seoul, Korea, 135-240 **Note** If you receive email in error, please send us with Remove at subject line.
It's only for you !!
Hyundai Trade corporation is a general trade company and reliable source in korea. We would like to introduce you more attractive products as follows. Please review and let's know your interest at your convenient time. And then we will provide all information without hesitation. ***Business lines*** 1)DVD player 2)Car security system 3)USB flash drive 4)Instant cellphone charger 5)TFT LCD monitor, 18.1 6)LCD PC 7)Fingerprint lock system 8)Helicopter (hobby product) 9)Cordless internet phone 10)Flash memory cards Sincerely Yours, If you are interested in getting sample and entering into business with this product feel free to contact us without hesitation. Mr. Seok-Do Yoo/Manager Hyundai Trade Corporation URL:http://www.hyundaitrade.com Email: [EMAIL PROTECTED] Tel:82-2-459-3123 Fax:82-2-3411-3118 Address:Missy 860 O/T. room No.604, 13-3 Kaepo-Dong, Kangnam-Gu, Seoul, Korea, 135-240 **Note** If you receive email in error, please send us with Remove at subject line.
Files Referenced in JavaScript
wget doesn't seem to recognize allfiles that are referenced in JavaScript and therefore doesn't download them. (For example, when there are mouseover images referenced in JavaScript, like on this site http://www.katenei.com) Is there a way tomake sure these files get downloadedwhen using wget? Johnnie J. Young [EMAIL PROTECTED]
Re: Files Referenced in JavaScript
Johnnie J. Young wrote:
wget doesn't seem to recognize all files that are referenced in
JavaScript and therefore doesn't download them. (For example, when
there are mouseover images referenced in JavaScript, like on this site
http://www.katenei.com) Is there a way to make sure these files get
downloaded when using wget?
I think this would be very hard. Because in this script the Real Patch
is put togehter in some steps.
MM_Image('name','','bild/a.jpg');
MM_Image my use Image.src='bild/a.jpg';
MM_Image my use Image.src=server+'bild/a.jpg';
MM_Image my use Image.src=bild_server+'bild/a.jpg';
so to build the correct adress for wget you need to interpret the
javascript, to find out what is an link an what not.
cu Thomas
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [PATCH] Failed linking on SCO Openserver
On Thu, Jan 17, 2002 at 11:50:32PM +0100, Hrvoje Niksic wrote:
Jeff Bailey [EMAIL PROTECTED] writes:
wget 1.8 fails to link on i686-pc-sco3.2v5.0.6
Does the compiler on that machine really not have alloca()? I'm
usually wary of attempts to compile `alloca.c' because they usually
point out a mistake in the configuration process.
Sadly, I don't know much about the SCO compiler. My experience so far
is that it's broken in some crazy ways. ``find / -name alloca\*
-print'' didn't return any results, however. I can try some tests
today or next week if you can think of some to try.
Here is the relevant section from config.log:
configure:5876: checking for working alloca.h
configure:5888: cc -o conftest -O -belf conftest.c 15
UX:acomp: ERROR: configure, line 5882: cannot find include file: alloca.h
UX:acomp: WARNING: configure, line 5884: improper pointer/integer combination: op =
configure: failed program was:
#line 5881 configure
#include confdefs.h
#include alloca.h
int main() {
char *p = alloca(2 * sizeof(int));
; return 0; }
configure:5909: checking for alloca
configure:5942: cc -o conftest -O -belf conftest.c 15
Undefined first referenced
symbol in file
alloca conftest.o
UX:ld: ERROR: conftest: fatal error: Symbol referencing errors. No output written to
conftest
configure: failed program was:
#line 5914 configure
#include confdefs.h
#ifdef __GNUC__
# define alloca __builtin_alloca
#else
# ifdef _MSC_VER
# include malloc.h
# define alloca _alloca
# else
# if HAVE_ALLOCA_H
# include alloca.h
# else
# ifdef _AIX
#pragma alloca
# else
#ifndef alloca /* predefined by HP cc +Olibcalls */
char *alloca ();
#endif
# endif
# endif
# endif
#endif
int main() {
char *p = (char *) alloca(1);
; return 0; }
configure:5974: checking whether alloca needs Cray hooks
configure:6059: checking stack direction for C alloca
configure:6086: cc -o conftest -O -belf conftest.c 15
configure: failed program was:
#line 6067 configure
#include confdefs.h
find_stack_direction ()
{
static char *addr = 0;
auto char dummy;
if (addr == 0)
{
addr = dummy;
return find_stack_direction ();
}
else
return (dummy addr) ? 1 : -1;
}
main ()
{
exit (find_stack_direction() 0);
}
configure:6111: checking for unistd.h
--
Tofu - The other white meat.
Re: WGet 1.8.1
Lauri Mägi [EMAIL PROTECTED] writes: I'm using WGet 1.8.1 for downloading files over FTP protocol. when filename contain spaces url is like that ftp://server.name/file%20name and it saves files also with %20 in file names Prior I was using WGet 1.7 and it saved spaces as the should be. My OS is RedHat 7.2 I tried w32 version also, but it puts @20 into filenames. Is it a bug or just a feature ? It's supposed to be a feature, but many users dislike that particular feature. Which means it is likely to go away in the next release. (Some dangerous characters will still be encoded to %hh, but space is likely not to be one of them.)
Re: WGet 1.8.1
It's supposed to be a feature, but many users dislike that particular feature. Which means it is likely to go away in the next release. (Some dangerous characters will still be encoded to %hh, but space is likely not to be one of them.) Is it possible to make and default set witch is bad and optional overide it by command line ? Cu Thomas Lußnig smime.p7s Description: S/MIME Cryptographic Signature
Re: Passwords and cookies
On 17 Jan 2002 at 18:17, Hrvoje Niksic wrote: Ian Abbott [EMAIL PROTECTED] writes: I'm also a little worried about the (time_t *)cookie-expiry_time cast, as cookie-expiry time is of type unsigned long. Is a time_t guaranteed to be the same size as an unsigned long? It's not, but I have a hard time imagining an architecture where time_t will be *larger* than unsigned long. I received an email from Csaba Ráduly which I hope he won't mind me quoting here: On 17 Jan 2002 at 12:45, [EMAIL PROTECTED] wrote: Very few may care, but IBM's C/C++ compilers v 3.6.5 typedef time_t as ... double ! Shouldn't cookie-expiry_time be declared as time_t ?
Volleyball t-shirts - Never seen before
An Oddballshirts.com presentation... Check out Oddball Shirts new line of Volleyball t-shirts These Volleyball shirts have NEVER been seen before! You are the first!! Click on the link below to visit the Oddballshirts Volleyball t-shirt gallery View Volleyball T-shirts click here There will be at least one that you will absolutely have to have! Visit the company that brings you these AWESOME shirts http://www.oddballshirts.com If you have received this message in error, we apologize To be sure you never receive another email from us again email us at [EMAIL PROTECTED]
Re: WGet is a very useful program. Writing a program to make the documentation easy
Michael Jennings [EMAIL PROTECTED] writes: The issue centers on the documentation. Philosophically, in my opinion, a program should be written so the documentation is easy to read. In this case a hidden stripping of useless characters means that there is one less thing to explain in the manual. No, it's one *more* thing to explain in the manual. The only characters universally agreed to be useless in the context of parsing are the whitespace characters. *Everything* else is subject to serious considerations. For example, control characters for you might be UTF8-encoded characters for someone else. Not stripping them away without a very good reason to do so is for me a simple matter of correctness. The GNU coding standards seem to suggest the same. (...) Or go for generality. For example, Unix programs often have static tables or fixed-size strings, which make for arbitrary limits; use dynamic allocation instead. Make sure your program handles NULs and other funny characters in the input files. Add a programming language for extensibility and write part of the program in that language. and: Utilities reading files should not drop NUL characters, or any other nonprinting characters _including those with codes above 0177_. The only sensible exceptions would be utilities specifically intended for interface to certain types of terminals or printers that can't handle those characters. Whenever possible, try to make programs work properly with sequences of bytes that represent multibyte characters, using encodings such as UTF-8 and others. There is precedent for this. Microsoft Windows is in some places written to get around shortcomings in the processors on which it runs. Such accommodation puts quirkiness in the code, but it gets the job done. In many cases Wget tries to accommodate to its environment to ensure smoother operation. But with each such accomodation we are forced to weigh the added quirkiness (entropy) of the code against the benefit. In this case, implementing correct support for ^Z is not exactly trivial, and the benefit is minimal -- the ^Z characters don't even appear in files normally created on platforms supported by Wget, which are Unix and Windows. You are trying to convince us otherwise by offering an easier implementation of ^Z, thereby reducing the costs. But unfortunately this easier implementation reduces correctness of the code, and is therefore not an option. Sorry.
