Re: wget bug?
On Mon, 9 Jul 2007 15:06:52 +1200 [EMAIL PROTECTED] wrote: wget under win2000/win XP I get No such file or directory error messages when using the follwing command line. wget -s --save-headers http://www.nndc.bnl.gov/ensdf/browseds.jsp?nuc=%1class=Arc; %1 = 212BI Any ideas? hi nikolaus, in windows, you're supposed to use %VARIABLE_NAME% for variable substitution. try using %1% instead of %1. -- Mauro Tortonesi [EMAIL PROTECTED]
Mirroring
I need to mirror ftp site including case when some file disapperared from ftp server - I need to delete this local file too. But ftp server keeps only e.g. 3 months so I need to restrict downloaded file by date . Is it possible with WGET ? Thanks. Miroslav
Re: wget bug?
Mauro Tortonesi schrieb: On Mon, 9 Jul 2007 15:06:52 +1200 [EMAIL PROTECTED] wrote: wget under win2000/win XP I get No such file or directory error messages when using the follwing command line. wget -s --save-headers http://www.nndc.bnl.gov/ensdf/browseds.jsp?nuc=%1class=Arc; %1 = 212BI Any ideas? hi nikolaus, in windows, you're supposed to use %VARIABLE_NAME% for variable substitution. try using %1% instead of %1. AFAIK it's ok to use %1, because it is a special case. Also the error would be a 404 or some wget error in that case the variable gets substituted in a wrong way or not? (actually even than you get a 200 response with that url) I just tried using the command inside a batch-file and came across another problem: You used a lowercase -s wich is not recognized by my wget-version, but a uppercase -S is. i guess you should change that. I would guess wget is not in your PATH. Try using c:\path\to\the dircetory\wget.exe instead of just wget. If this too does not hel at explicit --restrict-file-names=windows to your options, so wget does not try to use the ? inside a filename. (normally not needed) So a should-work-for-all-means-version is c:\path\wget.exe -S --save-headers --restrict-file-names=windows http://www.nndc.bnl.gov/ensdf/browseds.jsp?nuc=%1class=Arc; Of course just one line, but my dump mail-editor wrapped it. Greetings Matthias
Re: Mirroring
Hi Miroslaw, AFIAK there is no option to get wget deleting files it did not download in that turn. So if you want to use wget for mirroring you would need to redownload the whole server to a local dir and than do something like --- CUT here --- cd new_dir find . ../new_files cd .. cp -af new_dir/* old_dir/ cd old_dir find . -ctime -$DaysOnMirror ../old_files rm $(cat ../new_files ../old_files | sort | uniq -u) cd .. rm -rf new_dir --- CUT here --- I didn't try, so it may be buggy, but i guess it works, just keep your files in old_dir, downlaod new files to new_dir, replace $DaysOnMirror by the appropriate number (leaving e.g. -5 there), cross your fingers and old_dir should be up to date. I would suggest that tools like rsync are more appropriate for the task. Greetings Matthias MK schrieb: I need to mirror ftp site including case when some file disapperared from ftp server - I need to delete this local file too. But ftp server keeps only e.g. 3 months so I need to restrict downloaded file by date . Is it possible with WGET ? Thanks. Miroslav
wget.dotsrc.org going away
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The sunsite.dk-hosted secondary web site will be redirecting to http://www.gnu.org/software/wget shortly; I did not want the hassle of maintaining two separate sites, especially when it did not appear that they served different purposes. The GNU site will be updated at some point, though I'm not sure when, as 1.11 development is currently the priority (probably, the bulk of the updates will take place during the next prerelease testing cycle for 1.11). If there was anything particular and useful on the dotsrc site that isn't on the GNU site, please bring it to my attention. The only thing that pops out at me was the dotsrc site's planned development page, which I'll probably want to cull from; but since maintainership has changed, priorities for what will come in what release probably has too, so the specifics on that page are not really applicable anymore. Still, there may have been a few things highlighted there that aren't yet on the bugtracker radar, so I'll tend to that shortly. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGknlZ7M8hyUobTrERCHIKAJsGm/wqVrq2WZJVUFuf/bKuKsvZngCdEmmX 8jHzXwhJvEirLNZHJfEaM8M= =oEvL -END PGP SIGNATURE-
Re: wget.dotsrc.org going away
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Micah Cowan wrote: Micah Cowan wrote: The sunsite.dk-hosted secondary web site will be redirecting to http://www.gnu.org/software/wget shortly; I did not want the hassle of maintaining two separate sites, especially when it did not appear that they served different purposes. I searched the wget manual and the GNU site, and I can't find any links to the sunsite address. What the heck did I read that directed me there? I seem to remember that it was to http://sunsite.dk/wget or similar, rather than wget.dotsrc.org (which is what the former redirects to), but in order to remove references to the secondary site, I need to _find_ them! I do realize that there is a reference on the bottom of http://www.gnu.org/software/wget/wgetdev.html to the secondary site's CVS repository that needs to be removed. But I can't find the reference to the actual site! (Sorry for the spam) Must be just in the README. Anywhere else that anyone knows of, speak up! :) - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGkoeo7M8hyUobTrERCISFAJ9ANkKrdDEGtkM3wXlt2XnaSU4F6QCfSnFh EV0t9/hNoVfNngMWmWyDAB4= =jAz/ -END PGP SIGNATURE-
Re: wget.dotsrc.org going away
Zitat von Micah Cowan [EMAIL PROTECTED]: Must be just in the README. Anywhere else that anyone knows of, speak up! :) In my memory it used to be the other way around ;-) http://wget.sunsite.dk/ was the primary wget website for many years and nobody cared about the gnu.org page. And many external references pointed to it. See also Mauro's last words about it: http://www.mail-archive.com/wget@sunsite.dk/msg09567.html Jochen Roderburg ZAIK/RRZK University of Cologne Robert-Koch-Str. 10Tel.: +49-221/478-7024 D-50931 Koeln E-Mail: [EMAIL PROTECTED] Germany
Re: wget.dotsrc.org going away
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jochen Roderburg wrote: Zitat von Micah Cowan [EMAIL PROTECTED]: Must be just in the README. Anywhere else that anyone knows of, speak up! :) In my memory it used to be the other way around ;-) http://wget.sunsite.dk/ was the primary wget website for many years and nobody cared about the gnu.org page. And many external references pointed to it. I'm calling it the secondary website, because that is how the GNU site refers to it at the bottom of the Development section. At any rate, the maintainer guidelines asks maintainers to use the www.gnu.org/software/PROJECT as their primary site, except where databases or special requirements enter into play, and while there are several other projects (including high-profile ones) that ignore this requirement, I see no particular need to do so, except where we actually do have special requirements. The reason I'm getting rid of wget.dotsrc.org is: (1) there's no reason to have two sites with nearly identical information, and (2) we _must_ have at least a minimal presence on gnu.org, whereas the same cannot be said for dotsrc. :) - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGko937M8hyUobTrERCH2XAKCQ4JJirLCD+29yVddhtKm9JLbjGgCggDoI 9HZ/NZ+ZDprqNH3UF3JYHIk= =YyVl -END PGP SIGNATURE-
Re: wget.dotsrc.org going away
Zitat von Micah Cowan [EMAIL PROTECTED]: Must be just in the README. Anywhere else that anyone knows of, speak up! :) wget.sunsite.dk is also mentioned in the wget FAQ Jochen Roderburg ZAIK/RRZK University of Cologne Robert-Koch-Str. 10Tel.: +49-221/478-7024 D-50931 Koeln E-Mail: [EMAIL PROTECTED] Germany
Re: Bug update notifications
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Matthew Woehlke wrote: Micah Cowan wrote: The wget-notify mailing list (http://addictivecode.org/mailman/listinfo/wget-notify) will now also be receiving notifications of bug updates from GNU Savannah, in addition to subversion commits. ...any reason to not CC bug updates here also/instead? That's how e.g. kwrite does thing (also several other lists AFAIK), and seems to make sense. This is 'bug-wget' after all :-). It is; but it's also 'wget'. While I agree that it probably makes sense to send it to a bugs discussion list, this list is a combination bugs/development/support/general discussion list, and I'm not certain it's appropriate to bump up the traffic level for this. Still, if there are enough folks that would like to get these updates (without also seeing commit notifications), perhaps we could craft a second list for this (or, alternatively, split off the main discussion/support list from the bugs list)? - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGkrpK7M8hyUobTrERCIMaAKCDG8JN7DmUK7oIuE0fYmgYnZIrlgCghK7n iV8rIDYe1+cxzrQATM43CEM= =PKqt -END PGP SIGNATURE-
Re: Bug update notifications
Micah Cowan wrote: Matthew Woehlke wrote: Micah Cowan wrote: ...any reason to not CC bug updates here also/instead? That's how e.g. kwrite does thing (also several other lists AFAIK), and seems to make sense. This is 'bug-wget' after all :-). It is; but it's also 'wget'. Hmm, so it is; my bad :-). While I agree that it probably makes sense to send it to a bugs discussion list, this list is a combination bugs/development/support/general discussion list, and I'm not certain it's appropriate to bump up the traffic level for this. Still, if there are enough folks that would like to get these updates (without also seeing commit notifications), perhaps we could craft a second list for this (or, alternatively, split off the main discussion/support list from the bugs list)? I guess a common pattern is: foo-help foo-devel foo-commits ...but of course you're the maintainer, it's your call :-). (The above aren't necessarily actual names of course, just the categories it seems like I'm most used to seeing. e.g. the GNU convention is of course bug-foo, not foo-devel.) -- Matthew This .sig is false
No more dev change posts to wget-patches?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I would like for devs to be able to avoid the hassle of posting non-trivial changes they make to the wget-patches list. To my mind, there are two ways of accomplishing this: 1. Make wget-patches a list _only_ for submitting patches for consideration by devs, no longer with the additional purpose of communicating changes from the devs to the users. 2. Have svnmailer post any changes made to trunk or to release branches to wget-patches automatically. This means such announcements will no longer be limited to trivial changes. Note that I've asked dotsrc.org to implement the same non-subscriber authentication measures that are currently employed for the main wget list (as previously discussed), so hopefully the level of spam seen on wget-patches will be dramatically decreased. If using wget-patches to communicate changes that have been made is in fact still a useful thing, then option #2 would be best. However, it's not clear to me that a significant number of people are actually reading wget-patches for this purpose, in which case any that do want to know about such changes are probably better off subscribing to wget-notify to see them, and I should employ option #1. Input welcome. :) - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGks7f7M8hyUobTrERCBgTAJ0VIi4Wd1Xq9DYQY95Hjoo1UXk5owCdECAX mdxQzH7DQD3pfYnM4YP8J8U= =gShz -END PGP SIGNATURE-
Re: wget dev versioning [Re: WGET Dev branch BROKEN]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Micah Cowan wrote: To group: It seems to me that the questions I'm asking Chris right now are going to be common ones, unless we change the trunk Wget's version to give some indication as to when its last update was performed. We could use the output of svnversion in the version string itself, as described in http://subversion.tigris.org/faq.html#version-value-in-source . I'd probably also want to have development versions of svn describe their path, so that it will tell us when it actually came from a bugbranch, etc. What do you think? I've submitted a bug against this at: https://savannah.gnu.org/bugs/index.php?20358 I've done some basic, preliminary work towards this end: http://addictivecode.org/pipermail/wget-notify/2007-July/11.html However, I'm not satisfied with the direction this fix is taking (essentially, include the output of svnversion in the version string). For one thing, it's completely useless if it is built by someone who exported the source, rather than checked it out. For another, it doesn't distinguish between different branches within the same revision. If we do add a --bug option as Tony suggested, then perhaps it would be useful to add: extern const char *FOO_id = $URL$ $Rev$; to the top of every file FOO.c. Then we could have --bug spit out all of these; this would allow us to determine precisely where each file came from, and what branch. As a bonus, we could throw in MD5 checksum strings as well, so we can note if any of the files have been changed (I'm not sure how useful that'd truly be, though, as (a) it'll make dealing with small changes from downstream packagers more cumbersome, and (b) we'll have to do something a little fancy to deal with line-ending discrepancies between platforms). One issue with this is it still doesn't deal with changes to .h files. We could use macros for those, I suppose, but the problem is that this will only tell you what version of the .h file got #included by the module that implements --bug, and none of the other modules: so if some things got recompiled, but not other things, this information may be misleading (though, perhaps, a little better than nothing). It _might_ be nice to have something update the version number (to something like wget-1.11rMMDD[.N]) whenever a change is made. Since, in general, I'll be handling changes to the trunk and release branches in the form of merging bug branches in, it would be easy enough to roll a tool that combines bug merging with updating the version stamp, but I'm not sure that's what I want to do since (a) it makes it harder to deal with really trivial bug fixes, and (b) it removes the opportunity for devs to go ahead and merge their own changes in--say, when I'm on vacation for a few weeks or whatnot, or the change is truly a no-brainer, or... Anyway, these are the things I'm currently pondering, and I'd love to get some feedback or new ideas. Maybe the problem isn't even really big enough to deserve a solution, I dunno... but it would be nice. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGktlR7M8hyUobTrERCF/+AJ9kJvRbqMZMdOK7iPjOD24AEmBETACeNP8H CnaTXk9RMvTz3bwBKOzX9lI= =LjMF -END PGP SIGNATURE-
