LINUX.ORG.RU
 

GNU Wget 1.13


0

0

Спустя два года после выпуска предыдущей версии состоялся релиз консольного менеджера загрузок Wget 1.13.

Изменения по сравнению с версией 1.12:

  • поддержка HTTP/1.1;
  • улучшена обработка незакрытых HTML-тегов;
  • имя сохраняемого файла при перенаправлении запроса сервером определяется из оригинального URL, прежнее поведение можно включить при помощи ключа --trust-server-names;
  • используется непрерывное соединение с proxy-серверами, поддерживающими такую возможность;
  • ключ --config для указания при запуске конфигурационного файла, отличного от системного;
  • ключ --adjust-extension не изменяет расширение .htm файлов;
  • вновь по умолчанию используется GNU TLS бэкэнд;
  • исправление проблем с портабельностью;
  • отображение общего времени рекурсивных загрузок;
  • передача диагностических сообщений в stderr вместо stdout;
  • прочие мелкие улучшения и исправления.

>>> Исходный код


 ← 1 2 →
[#]  

> поддержка HTTP/1.1;

На дворе шел к концу 2011й год... facepalm.jpg

anonymous ()
[#]  

А насчёт конвенции именования загружаемого файла там ничео не улучшилось? По-прежнему надо вручную переименовывать, дабы злоумышленники ничего не перезаписали/стащили?

Например, sf.net/...project.tar.gz.../download --> download

* ()
[#] Ответ на: комментарий от inst 13.08.2011 15:55:06  
powerpc

Так, это как с "выводом в stdin" наверное ;5
Попутал или нераспарсил пост.

* ()
[#] Ответ на: комментарий от gag 13.08.2011 18:10:53  
powerpc

Не очень понял. Ты хочешь --directory-prefix или --convert-links или, может, --mirror?

* ()
[#] Ответ на: комментарий от gag 13.08.2011 18:10:53  

Если не ошибаюсь, это лечится с помощью ключа --content-disposition

()
[#] Ответ на: комментарий от wisp 13.08.2011 18:59:23  
       --content-disposition
           If this is set to on, experimental (not fully-functional) support
           for "Content-Disposition" headers is enabled. This can currently
           result in extra round-trips to the server for a "HEAD" request, and
           is known to suffer from a few bugs, which is why it is not
           currently enabled by default.

           This option is useful for some file-downloading CGI programs that
           use "Content-Disposition" headers to describe what the name of a
           downloaded file should be.
()
[#] Ответ на: комментарий от gag 13.08.2011 18:10:53  
adriano32

А зачем там /dowload? Оно и так выкачает sf.net/...project.tar.gz

*** ()
[#] Ответ на: комментарий от AGUtilities 13.08.2011 15:04:46  
havelite

АПВС? ВА?

Гражданин Попов - залогиньтесь под своим ником

* ()
[#] Ответ на: комментарий от adriano32 13.08.2011 19:26:34  
havelite

а порнуху ты как вытягивать собрался???

* ()
[#] Ответ на: комментарий от powerpc 13.08.2011 18:57:23  

Загружая (с редиректами) из браузера получаются нормальные имена. А с wget'ом - нет.

* ()
[#] Ответ на: комментарий от wisp 13.08.2011 19:01:30  

До сих пор значит экспериментально?.. Сколько уже лет этим пользуются.. но не пользователи wget. По-моему, curl этим по умолчанию не страдает. Кстати, а тут wget'ом пользуется, похоже, далеко не 99% лоровцев.

* ()
[#] Ответ на: комментарий от adriano32 13.08.2011 19:26:34  

Идём, например, сюда: http://sourceforge.net/apps/mediawiki/sumo/index.php?title=Downloads

И получаем "direct link" для sumo-src-0.13.0.tar.gz: http://downloads.sourceforge.net/project/sumo/sumo/version%200.13.0/sumo-src-0.13.0.tar.gz?r=http%3A%2F%2Fsourceforge.net%2Fapps%2Fmediawiki%2Fsumo%2Findex.php%3Ftitle%3DDownloads&ts=1313253856&use_mirror=freefr

Получаем: 

Saving to: “sumo-src-0.13.0.tar.gz?r=http:%2F%2Fsourceforge.net%2Fapps%2Fmediawiki%2Fsumo%2Findex.php?title=Downloads&ts=1313253856&use_mirror=freefr”

Я вот так постоянно сохраняю, переименовываю. А выходит wget'ом мало кто и пользуется.

* ()
[#] Ответ на: комментарий от gag 13.08.2011 20:50:08  
adriano32

Ну ты и ...! Если не скачиваешь браузером, копируй адрес ссылки, а не содержимое адресной строки браузера: http://prdownloads.sourceforge.net/sumo/sumo-src-0.13.0.tar.gz?download , ?download потом вытри, если не осилил некоторые опции командной строки.

И да, wget на то и консольный, чтоб пользоваться им в консоли, когда доступа к графическому браузеру нет или не надо.

*** ()
[#]  
Linez

pacman всё ещё собирается переходить на curl после таких революционных изменений в wget?

* ()
[#] Ответ на: комментарий от webhamster 13.08.2011 15:47:12  

> правильную кодировку 866

Правильных кодировок в природе ровно две — ASCII и UTF-8. Первой не всегда достаточно, про вторую Винда мало что знает, предпочитая cp866, cp1251 и ucs-2. Что до wget, то команда chcp 1251 спасет отца русской демократии, если, конечно, ему не понадобится, к примеру, вывод команды route print в том же окне

**** ()
[#] Ответ на: комментарий от webhamster 13.08.2011 15:47:12  
question4

> Они уже поставили в виндовой сборке правильную кодировку 866 в консоли, или все так же тупят с 1251?

Пинай тех, кто собирает. Эти сборки все неофициальные, со сторонними патчами.

**** ()
[#] Ответ на: комментарий от mmarkk 13.08.2011 14:40:01  
question4

> а чем вгет лучше курла?

Для простого скачивания одного файла они почти равноценны. Все различия в логике поверх качалки.

Уже сказали про рекурсивное скачивание сайта или его куска, автоматическое возобновление, конвертирование ссылок. Ещё Wget автоматически ставит дату файла на сервере и умеет обновлять только те файлы, которые изменились по дате или размеру. Ещё полезна команда --page-requisites — скачивает страницу со всеми картинками и скриптами, даже если они берутся с других сайтов.

Да, всё это реализуемо и на curl-е. Но придётся писать самому :)

Из достоинств curl-а — возможность задавать адреса в форме http://somesite.com/[1-98].htm Для wget-а придётся писать однострочник на баше, что неудобно под оффтопиком. Всякое шаманство с заголовками, если wget не делает этого автоматически, тоже проще делать в curl-е, имхо.

**** ()
[#] Ответ на: комментарий от gag 13.08.2011 20:42:35  
question4

> Сколько уже лет этим пользуются.. но не пользователи wget. По-моему, curl этим по умолчанию не страдает.

В нём этого просто нет :) Чтобы получить правильное имя, надо сперва прогнать с ключами -L -I, потом качать с -L -o.

**** ()
[#] Ответ на: комментарий от d1337r 13.08.2011 11:13:50  
matumba

> Только закончил собирать 1.12 :(

Руками компилировал штоле? :)

**** ()
[#]  
Kor03d

Оболочками графическими wget красен, имхо.

()
[#] Ответ на: комментарий от Kor03d 14.08.2011 0:51:17  

Это какими же?

anonymous ()
[#] Ответ на: комментарий от adriano32 13.08.2011 20:56:46  

Я от браузерного скачивания отказался, потому что оно там дату с сервера не берёт. Да и дозакачивать в тоже имя, но со сменившимся адресом иначе не получается.

* ()
[#] Ответ на: комментарий от question4 13.08.2011 22:36:40  

Хммм, попробовал сейчас на sf.net - точно не смог, но помнится, что на каком-то сайте работал в отличие от wget'а. Разве что пришлось добавлять опции для такого с моей точки зрения само собой разумеющегося, как получение оригинальноых даты/времени с сервера.

* ()
[#] Ответ на: комментарий от gag 14.08.2011 3:54:43  
question4

> попробовал сейчас на sf.net - точно не смог, но помнится, что на каком-то сайте работал в отличие от wget'а.

Если имя, то где-то может сработать с ключами -L -O , если самая первая ссылка в цепочке перенаправлений содержит правильное имя файла.

Если время, то эту фичу уже много лет просят, но по-моему до сих пор не сделали. Прошлой весной точно не было.

**** ()
[#] Ответ на: комментарий от AGUtilities 13.08.2011 14:53:17  

Один поток далеко не всегда способен загрузить мой канал.

* ()
[#] Ответ на: комментарий от holka 14.08.2011 15:13:37  
AGUtilities

ну дык а за чем его загружать полностью? в каком месте это повысит скорость скачивания, если учесть, что суммарная скорость отдачи сервера будет той же? и к стати, в случае многопоточности, больше полезного труда трафика, будет растрачено на сервисные затраты протокола, чем на скачивание, собственно, нужного файла.

** ()
[#]  

Это в этот вгет взяли твой патчик?

* ()
[#] Ответ на: комментарий от holka 14.08.2011 15:13:37  
question4

> Один поток далеко не всегда способен загрузить мой канал.

А несколько потоков способны перегрузить сервер, поэтому за них в некоторых местах до сих пор сохранили привычку банить.

Чаще просто ограничивают число потоков и суммарную скорость отдачи, так что многопоточность сейчас не столь полезна, как во времена появления всяких ReGet-ов.

**** ()
[#] Ответ на: комментарий от Linez 13.08.2011 22:07:56  
muhas

pacman wget и не использовал, libfetch был, теперь хотят curl

** ()
[#] Ответ на: комментарий от question4 15.08.2011 1:06:36  
>>-----Цитата---->>

А несколько потоков способны перегрузить сервер, поэтому за них в некоторых местах до сих пор сохранили привычку банить.

Чаще просто ограничивают число потоков и суммарную скорость отдачи, так что многопоточность сейчас не столь полезна, как во времена появления всяких ReGet-ов.

<<-----Цитата----<<

Иди-ка не смеши-ка сисадмина. Несколько потоков это не множество - сервер они не перегрузят. В теории - может быть, на практике едва ли. Число потоков и суммарную скорость отдачи тоже нынче почти никто не ограничивает. Либо только однопоточная, либо без ограничений вовсе. Приведи в пример несколько сайтов, где ограничены количество потоков и суммарная скорость отдачи, если это частое явление.

* ()
[#] Ответ на: комментарий от holka 15.08.2011 12:47:32  
question4

> сисадмина

Насколько богат и разнообразен твой опыт? Приходилось ли тебе в этом году админить сервера на Windows 2000?

Даже если ты и твои знакомые ведут себя разумно и в ногу со временем, это не значит, что нет серверов, где конфиги не менялись последние 5 лет :)

> Несколько потоков это не множество - сервер они не перегрузят.

Перегрузят если много народу качает в несколько потоков. Если сервер не справляется, и приходится ограничивать скорость отдачи, то пользователи, которые тянут несколько потоков, будут нежелательны.

> Число потоков и суммарную скорость отдачи тоже нынче почти никто не ограничивает.

Согласен. Поэтому я и сказал "сохранили привычку" :)

> Приведи в пример несколько сайтов, где ограничены количество потоков и суммарная скорость отдачи, если это частое явление.

Сейчас это перестало быть частым явлением. Обычно этим занимаются достаточно старые (лет 5-8 и старше) и не слишком доходные сайты с большим файловым архивом. Например, редкая старая музыка и abandonware. Или чьи-то личные FTP-архивы. Проверять лень, но в прошлом году это видел на файловых архивах olddisco.da.ru, на old-games.ru или каком-то из его клонов и на HotU.

Встречный вопрос: какие сайты не могут заполнить твой канал в 1 поток, но заполняют при большем числе потоков?

**** ()
[#] Ответ на: комментарий от question4 16.08.2011 0:46:36  

Опыта достаточно, чтобы распознать 4.2. Нет, я не администрирую windows. Нежелательны - может быть, но перегрузят только в теории. Не случается такого на практике, не случается =)

"Сохранили привычку" ты говорил про баны, а про ограничения ты сказал "чаще ограничивают".

Понятно, короче, ты сам не нашел таких сайтов. Днем с огнем их уже не сыщешь. Привести пример ты не осилил.

По http я качаю только tube видео, поэтому примеры будут соответствующие. jizzhut.com, tnaflix.com, xnxx.com, redtube.com, youporn.com и так далее. Могу еще с десяток подсказать. И ни одного не припомню, который бы заполнил канал в один поток.

wget "http://fck-c05.tnaflix.com/dev5/0/000/158/0000158415.fid?key=eb03af8126e70cd0..." - 104K/s

axel -n 12 "http://fck-c05.tnaflix.com/dev5/0/000/158/0000158415.fid?key=eb03af8126e70cd0..." 1,7MB/s

* ()
[#] Ответ на: комментарий от holka 18.08.2011 13:27:15  
question4

Полез проверять. Все сайты, где меня когда-либо банили за многопоточность, закрылись.

Убедил.

**** ()
[#]  
powerpc

Ого, нашёл эту новость. В общем, Giuseppe грохнул 1.13 и даже 1.13.1. Буквально 12 часов назад. Больше нет 1.13.

* ()
[#] Ответ на: комментарий от question4 22.08.2011 0:30:13  

Вот видишь, фиг таких найдешь, а если найдешь, то они никому и не нужны :D

* ()
 ← 1 2 →
GNU's Not Unix