wget and frames
We received this report on webmasters. Can anyone help Anthony, please? Hi, I really like this utility but was having trouble getting 'framed' data into the output files. It is like when one views the source of the webpage from a browser, this is what I see in my output file. If I go to view Frame source from the webpage, I see the rest of the page html. Is there a way in wget to get this data too without all the pics/images downloaded? Thanks, Anthony
wget maintainer?
Regrettably, Mauro has had to resign the maintainership of wget. (Of course, many thanks to him for his work, and at least as many thanks to Hrvoje for writing it in the first place.) I have asked a few people individually if they'd like to take over the package, but none has had time. Would anyone on this list feel that they have enough time and inclination to be the new maintainer? Please write me if you would like to volunteer. I'll post in various places if no one comes forward, but this seemed like the most likely place ... Thanks, Karl
Re: gettext and charsets
Hrvoje Niksic [EMAIL PROTECTED] writes: Perhaps you could try posting to [EMAIL PROTECTED]? Failing that, you might want to try at the address of the Free Translation Project and/or the Norwegian national team near you. [EMAIL PROTECTED] is the preferred list for reporting gettext bugs. Implementation issues can be discussed at [EMAIL PROTECTED] (also read by Bruno Haible).
Re: some wget patches against beta3
Hrvoje Niksic [EMAIL PROTECTED] writes: As for the Polish translation, translations are normally handled through the Translation Project. The TP robot is currently down, but I assume it will be back up soon, and then we'll submit the POT file and update the translations /en masse/. It took a little bit longer than expected but now, the robot is up and running again. This morning (CET) I installed b3 for translation.
wget -m imply -np?
I wonder if it would make sense for wget -m (--mirror) to imply -np (--no-parent). I know that I, at least, have no interest in ever mirroring anything above the target url(s) -- generally, that leads to the whole Internet. An option to explicitly include the parents could be added. Just a suggestion. Thanks for the great software. [EMAIL PROTECTED]
Re: wget 1.8.x bulgarian translation
Vesselin Markov [EMAIL PROTECTED] writes: I wrote a bulgarian localization of Wget 1.8.1 which i hope you'll accept. I am sending wget-1.8.1-BG/po/bg.po wget-1.8.1-BG/po/bg.gmo wget/share/locale/bg/LC_MESSAGES/wget.mo Thanks a lot -- but please consider to join the Bulgarian translation team: [EMAIL PROTECTED] At the moment, Yassen Roussev is listed to translate wget but I guess will appreciate help! For more info, please visit: Free Translation Project: http://www.iro.umontreal.ca/contrib/po/HTML/ -- Linux frechet 2.4.16-4GB #1 Wed Dec 12 13:42:58 GMT 2001 i686 unknown 8:52am up 26 days, 22:14, 13 users, load average: 1.41, 1.45, 2.33 work: [EMAIL PROTECTED] Karl Eichwalder home: [EMAIL PROTECTED]
Re: wget 1.8.1: po/el.po update
[EMAIL PROTECTED] writes: I translated the few remaining messages in the greek po file. Here are the diffs. Please, try to get in contact with the last translator (cf. the Cc:) to avoid duplicate work. Thanks a lot! Thanks for writing and maintaining such a great tool. -- Linux frechet 2.4.16-4GB #1 Wed Dec 12 13:42:58 GMT 2001 i686 unknown 3:34pm up 21 days, 4:55, 13 users, load average: 0.21, 0.22, 0.20 work: [EMAIL PROTECTED] Karl Eichwalder home: [EMAIL PROTECTED]
Re: Users and languages, was: Uncoupling translations from source
[EMAIL PROTECTED] writes: IMO, a bad translation is only useful, if I speak the original language even worse. I'd rather stick to a precise Oxford English than a German Kauderwelsch created by BabelFish (TM). Just try to translate a middle size program (2-500 message) and you'll see how un-precise original messages are ;-) It takes more of my time to report and discuss inconsistencies than to translate the strings. My point is, that _I_ find it easier to use a manual/prog in good English than in bad German. (And, to admit it, I rarely take the time to report translation bugs...) Additional note, you're not allowed to install programs for your users in some countries when there's no native language support. -- Free Translation Project: Karl Eichwalder http://www.iro.umontreal.ca/contrib/po/HTML/
Re: Uncoupling translations from source
Hrvoje Niksic [EMAIL PROTECTED] writes: Why is unpacking two tar files instead of one a complication? At the moment, it just wont work (gettext limitation); nevertheless we are thinking about the possibility to offer separate translation update packages. For it's still essential to ship most recent translations with every regular package release. (And that's provided you want translations in the first place; many people don't.) These people are experts. They can go directly to the CVS and download what they need. Please note, according to my experiences Americans can stand the translations coming with tar.gz files; only advanced European users (so called experts) don't like them. There are packages that are much more complicated to install than that. The difference is translation are not essential -- thus people will tend to ignore them if additional efforts are involved. This might change in the future but for now that's the truth. -- [EMAIL PROTECTED] (work) / [EMAIL PROTECTED] (home): | http://www.suse.de/~ke/ | ,__o Free Translation Project:|_-\_, http://www.iro.umontreal.ca/contrib/po/HTML/ | (*)/'(*)
Re: English vs Locale
Marc St-Jacques [EMAIL PROTECTED] writes: When I type 'wget --help', only one tenth of it's output is in my locale's language, in this case, French. Now this is a package that came with Mandrake 8.1. Is it an overall problem with wget or is Mandrake at fault here ? The official release 1.7 lacks several translations. By now, it's complete; cf.: http://www.iro.umontreal.ca/contrib/po/HTML/domain-wget.html I'd like to see a new release (1.7.1) with all translations updated. -- Linux frechet 2.4.10-4GB #1 Mon Oct 15 17:27:24 GMT 2001 i686 unknown 11:14am up 3 days, 22:55, 6 users, load average: 0.31, 0.12, 0.08 work: [EMAIL PROTECTED] Karl Eichwalder home: [EMAIL PROTECTED]
Re: wget and seeding random numbers
1 - Use RAND_egd() for reading true random data if such is available (this needs to be checked for in the configure script, as RAND_egd() wasn't introduced until OpenSSL 0.9.5). This would also benefit from a command line option to specify the egd socket. EGD = Entrophy Gathering Daemon. 2 - Use RAND_screen() for windows based systems (gets random data off the screen). 3 - Allow a user-specified file for reading random data from with RAND_load_file() 4 - Use RAND_file_name() to get what default file (if any) to read random data from. (This seems to be done in the lynx code) 5 - *then* you go with the srand(), time and pid seeding stuff. I'm no expert on openssl, but that looks pretty reasonable, and it's probably just a couple more calls, so not hard to do? As long as the srand()all stuff is there as a final default. Thanks, karl
wget and seeding random numbers
About doing the random number seed for ssl, I dug up what lynx does, and
it looks like it wouldn't be difficult to do something similar in wget.
It appears this code was written by Mark Mentovai [EMAIL PROTECTED],
http://www.moxienet.com/.
Hope it helps.
k
if(RAND_status()==0) {
char rand_file[256];
time_t t;
pid_t pid;
long l,seed;
t=time(NULL);
pid=getpid();
RAND_file_name((char *)rand_file,256);
CTRACE((tfp,HTTP: Seeding PRNG\n));
if(rand_file!=NULL) {
/* Seed as much as 1024 bytes from RAND_file_name */
RAND_load_file(rand_file,1024);
}
/* Seed in time (mod_ssl does this) */
RAND_seed((unsigned char *)t,sizeof(time_t));
/* Seed in pid (mod_ssl does this) */
RAND_seed((unsigned char *)pid,sizeof(pid_t));
/* Initialize system's random number generator */
RAND_bytes((unsigned char *)seed,sizeof(long));
srand48(seed);
while(RAND_status()==0) {
/* Repeatedly seed the PRNG using the system's random number generator until it
has been seeded with enough data */
l=lrand48();
RAND_seed((unsigned char *)l,sizeof(long));
}
if(rand_file!=NULL) {
/* Write a rand_file */
RAND_write_file(rand_file);
}
}
Re: wget 1.7, linux, -rpath
Replacing -rpath with -Wl,rpath It has to be -Wl,-rpath, not -Wl,rpath (with the - on rpath too). All I can say is that after I made that change, the ssl test worked for me on redhat 7.1 (and so did the ssl functionality :). I can see how your other changes might be needed in other cases, though. On another topic, you might consider upgrading to autoconf 2.50. It has a number of nice new features, and at least for me (i.e., Texinfo), the upgrade was pretty much painless. Thanks, karl
Re: wget/src/ftp-ls.c: tiny typo
R.I.P. Deaddog [EMAIL PROTECTED] writes: For separating translation as another tarball, there's another risk of people putting different versions of source and translation together, not to mention the additional time needed for packaging. Yes, this disaster happens for manpages all the time ;-( But of course it's up to developers to decide which method costs less and which costs more. Yes. Using the TP and its defaults isn't mandatory. Of course it helps to reduce the organizational(?) overhead if you try to use the TP setup. Hrvoje Niksic [EMAIL PROTECTED] writes: I didn't mean that the translators were lazy or anything like that. By too late I meant that `wget.pot' in the current tree is already different from `wget-1.7-pre1.pot'! That's life and translators are used to it. From pre-release to pre-release the message will stabilize. Whenever there are message string related changes we can install a new .pot file; just announce it to us ([EMAIL PROTECTED]). For the moment we still have to approve such a request; it's on the improvement list to let install maintainers new versions on their own. Even if a language file isn't 100% complete a translation is useful. Another unfortunate misunderstanding: your asking for the POT file was perfectly fine, and I am grateful that you did. Thanks :) The problem on my side is that I don't know what to do with 1.6 translations, Hard to tell. Put them into the wget CVS please. And if you think it's useful, release them together with wget 1.6 as wget-1.6.1 (like some GNOMErs do; KDE people do the same AFAIK). just like I don't know what to do with 1.7-pre1 translations which are already out of date. Add them to the CVS, please, and distribute them together with the next wget release.. Next time I'll wait whether you'll send an request to [EMAIL PROTECTED] I didn't even know about that address. I'll have to, once again, read up on the exact TP procedures. Good idea. You can start here: http://www.iro.umontreal.ca/contrib/po/HTML/maintainers.html -- work : [EMAIL PROTECTED] | ,__o : http://www.suse.de/~ke/ | _-\_, home : [EMAIL PROTECTED] |(*)/'(*)
Re: wget/src/ftp-ls.c: tiny typo
Hrvoje Niksic [EMAIL PROTECTED] writes: But... The Wget 1.6 branch exists, and contains minor bugfixes, including changed strings. (I gave up on 1.6.1 because of the imminent 1.7 release.) Reasonable. Then there's no need to care about still incoming translations for 1.6. If I were to release 1.6.1 with the 1.6 translations, they would once again be incorrect. You could ask [EMAIL PROTECTED] to ask the translations team to have a look at the 1.6.1 message files. -- work : [EMAIL PROTECTED] | ,__o : http://www.suse.de/~ke/ | _-\_, home : [EMAIL PROTECTED] |(*)/'(*)
Re: wget/src/ftp-ls.c: tiny typo
Hrvoje Niksic [EMAIL PROTECTED] writes: The strategy of re-releasing the whole package shares many of the flaws with the strings freeze strategy. Specifically, I would be tempted to include bug fixes and string changes into such a re-released package. Would be okay with me. Just increase the version number (reserve the first 3 numbers for programming realated issue and the 4th number for translations): 1.7 The normal forthcoming release. Then 1.7.0.1 Only translations added or 1.7.1 Release with bug fixes (and with new translations) If it was needed to release 1.7.1 and further translations will arrive, release 1.7.1.1 That's the bug fix release with new translations. Unbundling translations has the additional benefit that people who don't care about translations (*gasp*) never need to deal with them. We'll go this way sooner or later; IMO, the time doesn't have come. I really cannot understand how an additional TAR file would be an irritation to *everyone*. The programmers, the translators, and the users would never even notice it! Might be part of the problem. programmers just get familiar with how it works; maybe, they are not fond of the idea to maintain additional tar files. At the moment it's guaranteed it just works (widely supported by automake, autoconf and gettext plus the robot). Compare that to the current situation where all of Wget's translations except the Croatian one are *guaranteed* to be incomplete! Not necessarily. Interested parties can have a look at www.iro.umontreal.ca and fetch updated files. Francois Pinard has dismissed my idea out of hand. Sometimes I get the feeling that the Translation Project is extremely closed to new ideas. No, not at all. But it's a lot of work to arrange all the infrastructure for all the i18n/l10n business. At the moment we (Martin v. Löwis and me, with background support by François) are trying to get the whole project fly again: we've to test gettext, support the teams, support new translators who want to establish a new team, sort out copyright issues, add new software packages, keeping track of changing email addresses and web and FTP references, update/fix the robot software. Then we'll have to update the texts of François' website and we've to work out a scheme to hand out more work to the so called team leaders (that's a big permission/security problem). If this is done we can start to change the workflow. Of course, we can start now to collect all ideas and to assign priorities. Several years ago when I decided to not bundle gettext with Wget, it was considered almost unthinkable. Today it is becoming an established practice. ;) For Linux this might work... Sometimes I wish the TP people would listen to suggestions with a more attentive ear. Be assured, we do. Of course, François also did listen. Actually, he collected and sorted all the different mails (proposals, support requests, etc.); all things are in a pretty good condition as handed out by François. Now we're trying to cut down the backlog. I'm sure this will not take too long. I guess I can start to think seriously about improvement proposals the next month. This doesn't mean the improvement will come true 2 months later ;) Hope this helps for the moment. -- work : [EMAIL PROTECTED] | ,__o : http://www.suse.de/~ke/ | _-\_, home : [EMAIL PROTECTED] |(*)/'(*)
Re: wget/src/ftp-ls.c: tiny typo
Hrvoje Niksic [EMAIL PROTECTED] writes: Maybe a more in-depth investigation is needed? I really don't see a single reason why the ls/sed trick Wget employs shouldn't work for any other Autoconf-based tool. Using wildcards is inherently dangerous. I think all source files and all installable files ought to be listed explicitly. -- work : [EMAIL PROTECTED] | ,__o : http://www.suse.de/~ke/ | _-\_, home : [EMAIL PROTECTED] |(*)/'(*)
wget/src/ftp-ls.c: tiny typo
2001-06-03 Karl Eichwalder [EMAIL PROTECTED] * ftp-ls.c (ftp_parse_ls): Fix typo. --- wget/src/ftp-ls.c.~1.18.~ Sun Jun 3 07:32:03 2001 +++ wget/src/ftp-ls.c Sun Jun 3 07:33:39 2001 @@ -785,7 +785,7 @@ return ftp_parse_unix_ls (file, TRUE); default: logprintf (LOG_NOTQUIET, _(\ -Usupported listing type, trying Unix listing parser.\n)); +Unsupported listing type, trying Unix listing parser.\n)); return ftp_parse_unix_ls (file, FALSE); } } Diff finished at Sun Jun 3 07:34:43 -- work : [EMAIL PROTECTED] | ,__o : http://www.suse.de/~ke/ | _-\_, home : [EMAIL PROTECTED] |(*)/'(*)
translations 1.7? (Re: Question)
On 30 May 2001, Hrvoje Niksic wrote: Yes, but you need the version 1.7, which is about to be released. If a pre-release is available I'd like to install the .pot file of this pre-release package on the Translation Robot site (http://www.iro.umontreal.ca/contrib/po/HTML/). Of course, I can wait if you think it's too early. Karl
Re: wget.pot and translations
Hrvoje Niksic [EMAIL PROTECTED] writes: Since the other methods have obviously failed, here is the pot file: http://jagor.srce.hr/~hniksic/wget/wget.pot I'm very sorry about all the trouble you all have had with the Translation Robot. Now I've learnt from François how to feed this nice system (at least, it looks as if I'm able to update existing projects). I just run wget-1.6 through the robot (mainly for real live testing). Now it should be possible to submit .pot files as usual (human intervention by me (or Martin v. Löwis) is still needed to put those files in place -- we'll try our best). Martin will mainly take care about the technical details; I'll try to do the paper work, files processing and the like. Thanks again to François Pinard for implementing and establishing this great system (he's still acting in the background; this will help a lot!). All the best, Karl -- Linux Frechet 2.2.18 #1 Fri Jan 19 22:10:35 GMT 2001 i686 unknown 7:54pm up 5 days, 2:27, 11 users, load average: 0.04, 0.03, 0.00 work: [EMAIL PROTECTED] Karl Eichwalder home: [EMAIL PROTECTED]
Re: Support for DESTDIR while installing
Hrvoje Niksic [EMAIL PROTECTED] writes: Only if you haven't run `make' before. With Wget, it's perfectly safe to say: $ make # assumes regular prefix ... build finishes ... $ make install prefix=/something/different # same as DESTDIR=... Okay, but it isn't userfriendly to ask the user to use different values for the same variable at different stages of the configuration, compilation and installation precess. Yes, I admit wget fulfills the Coding Standards as written; but I see possibilities to improve it even more. -- work : [EMAIL PROTECTED] | ,__o : http://www.suse.de/~ke/ | _-\_, home : [EMAIL PROTECTED] |(*)/'(*)
