Спустя два года с момента прошлого значительного выпуска состоялся релиз GNU Wget 1.21, программы для автоматизации загрузки контента с использованием протоколов HTTP/HTTPS и FTP. В новой версии:...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=54340
С НГ!
Серёга, не гони!
Алкоголизм делает человека заторможенным.
В смысле?
> Серёга, не гони!Но лингвисты Опеннета почему-то до сих пор не выдвинули предположения о расшифровках второй части этой фразы - ПНФ! Хотя уже почти прошёл целый первый день нового года!
Полный вариант-то звучит не СНГ, а СНГ ПНФ!
Дескать:
- С Новым годом!
- Пошёл на фиг!
как сказал покойный Задорнов, эссен, по-немецки- кушать...
Евреи эту хохму про СНГ на идиш рассказывали задолго до Задорнова.
Всех с "Серёга Не Гони!".
На улице гололёд и магазины закрыты(95%) - Москва
Центральная Украина. Солнце и +8 😜 снега не было ещё
Юг России, Крым, +11, снега не видать
Юг России, не Крым, днём было +13, снег в последний раз видели в прошлом году )
"прошлый год" последний раз был вчера.
Забавный Опеннет, шутку не оценил, а адмирал плюсцов огрёб.
Сочи +15
Серёга Не Гони! :)
Что за мемчик, что я пропустил?
> что я пропустил?Корпоратив в отделении реформаторов инфосреды
Contributions byVyacheslav
Вячеслав ПетрищевMaintainer: DarShit Shah
LMAO
// b.
WTF so funny you see?
В новой версии скрипт configure перестал сам добавлять в CFLAGS опцию -std=gnu99. А без этого оно не собирается. Так что теперь извольте сами вручную.С Новым годом всех!
С новыми граблями!
Тебе сюда: https://savannah.gnu.org/bugs/?func=additem&group=wget
Спокойно ждём 1.21.2
>В некоторых местах в функции указывался размер непроверенных внешних строкВот реальная причина большинства ошибок. А не то, что там говорят хрустанутые.
>внешних строк, передаваемых через командную строки или получаемых с внешнего хостаЯ так понимаю, это библиотечная функция для выделения памяти. Тогда не понял, что за дичь с получаемыми через командную строку или с внешнего хоста данными?
Видимо, где-то использовались буферы фиксированного размера, в которые принимались данные из внешней системы без проверки длины. Ну а дальше наши любимые уязвимости через переполнение буфера.
В предыдущей сборке пакета был, например, такой патчик:http://packages.altlinux.org/ru/sisyphus/srpms/wget/patches/...
--- wget-1.10.1/src/http-ntlm.c.org 2005-10-13 15:29:07 +0300
+++ wget-1.10.1/src/http-ntlm.c 2005-10-13 15:32:16 +0300
@@ -314,7 +314,7 @@
int domoff; /* domain name offset */
int size;
char *base64;
- char ntlmbuf[256]; /* enough, unless the host/domain is very long */
+ char *ntlmbuf;/* point to the address of the pointer that holds the string to sent to the
server, which is for a plain host or for a HTTP proxy */
@@ -334,6 +334,7 @@
default: /* for the weird cases we (re)start here */
hostoff = 32;
domoff = hostoff + hostlen;
+ ntlmbuf = (char *)alloca( 32 + hostlen + domlen);DEBUGP (("Creating a type-1 NTLM message.\n"));
@@ -437,6 +438,8 @@
usr = user;
userlen = strlen(usr);+ ntlmbuf = (char *)alloca( 64 + domlen + userlen);
+
mkhash(passwd, &ntlm->nonce[0], lmresp
#ifdef USE_NTRESPONSES
, ntresp
> enough, unless the host/domain is very longВот понимал же человек, который это писал, что может быть very long! Ну как так:(
Выделение на стеке без ограничения длинны. Хорошо-то как...
> Я так понимаю, это библиотечная функция для выделения памяти.Да, библиотечная. Но она выделяет на стеке. А стек -- хрупкая штука. Во многих проектах alloca вообще под запретом, и за её использование руки отрывают.
> void *alloca(size_t size);
> DESCRIPTION
> The alloca() function allocates size bytes of space in the stack
> frame of the caller. This temporary space is automatically freed
> when the function that called alloca() returns to its caller.
> RETURN VALUE
> The alloca() function returns a pointer to the beginning of the allo‐
> cated space. If the allocation causes stack overflow, program behav‐
> ior is undefined.Чуешь? Тут документированный UB, и (что очень в стиле unix-way) этот UB невозможно гарантированно обойти. Вызывая alloca, ты никогда не знаешь, будет ли переполнение стека или нет. И узнать не можешь. Но alloca -- это очень быстрый способ выделить/освободить память, гораздо быстрее чем malloc. Поэтому возникает соблазн забить на потенциальные проблемы, и использовать alloca вместо malloc. И есть те, кто перед таким соблазном устоять не может.
Если выделять немного, то в принципе ничего плохого не должно случиться. Но что значит "немного"? И это ж надо проверить, так уж ли немного мы собираемся выделить? А если мы проверили, и оказалось много, то что делать?
То есть, "немного" ведь означает не больше N, где N -- известное на этапе компиляции целое число. А если мы можем написать:
char *buf = NULL;
if(size <= 256) {
buf = alloca(size);
} else {
die("Invalid size"); // в смысле die -- это no-return функция
}то мы с тем же успехом можем написать и:
if(size > 256) {
die("Invalid size");
}
char buf[256];Тут выходит, что выделяется 256-size лишних байт, но... и чё с того? Это может иметь значение при рекурсивном вызове, но использовать alloca в рекурсивной функции может только полнейший отморозок.
То есть alloca оказывается не нужен в такой ситуации. А если size может исчисляться мегабайтами, и мы считаем что наша программа должна работать с такими size, то придётся пользовать malloc, потому как условно использовать alloca или malloc в зависимости от размера -- это то же самое, что открывать нараспашку все двери, вешая над ними транспаранты "MEMORY BUGS ARE WELCOME!". Причём, в такой ситуации, скорее всего и выигрыша по скорости не будет никакого существенного: если программа норм работает с мегабайтовыми буферами, выделенными при помощи malloc, она тем более будет норм работать с докилобайтовыми буферами, выделенными при помощи malloc.
Может можно придумать какой-нибудь use-case для alloca, когда это не будет хождениями по граблям переполнения стека AND даст прирост в скорости, но, во-первых, мне не удаётся придумать, во-вторых, это будет очень специальным случаем, и это будет раскладыванием граблей для будущих разработчиков.
> и (что очень в стиле unix-way) этот UB невозможно гарантированно обойтиПричём бы здесь Unix way?
Да и вообще, причём здесь alloca? В C99 можно с точно таким же результатом использовать VLA.
> Да и вообще, причём здесь alloca?Новость не читай, сразу комментируй?
"Проведена чистка кода от использования функции alloca. В некоторых местах в функции указывался размер непроверенных внешних строк, передаваемых через командную строки или получаемых с внешнего хоста."
> В C99 можно с точно таким же результатом использовать VLA.
Можно. С тем же результатом, включая сюда и UB.
Я-то новость прочитал, ещё б ты прочитал вопрос, на который отвечаешь… Попрубуем ещё разик: Причём здесь unix way, да и вообще unix? Аргумент, что alloca есть только в этих ваших юниксах, не канает, потому что VLA есть в стандарте языка.
> Я-то новость прочитал, ещё б ты прочитал вопрос, на который отвечаешь… Попрубуем
> ещё разик: Причём здесь unix way, да и вообще unix?Потому что это вообще очень по юниксовому -- верить в то, что всё пойдёт хорошо, и не оставлять ни единого костылика на случай, если всё пойдёт плохо, чтобы можно было бы ошибку как-нибудь осмысленно обработать.
Мдя? Пяток примеров, специфичных именно для юниксов, тебе ведь не составит труда накидать?
> Мдя? Пяток примеров, специфичных именно для юниксов, тебе ведь не составит труда
> накидать?alloca не канает? Из мана к ней:
> CONFORMING TO
> This function is not in POSIX.1.
> There is evidence that the alloca() function appeared in 32V, PWB,
> PWB.2, 3BSD, and 4BSD. There is a man page for it in 4.3BSD. Linux
> uses the GNU version.Если не канает, попробуй собрать пайпами цепочку команд и когда она обвалится, выяснить где собственно произошла ошибка.
Или взять пути в файловой системе, которые позволяют любые символы, даже несмотря на то, что из тысяч софта, может быть единицы могут справится с любыми символами, при том что в подавляющем большинстве случаев нет никакого смысла совать в имя файла ^C или ^M. Смысла нет, но кого колышет? Надо обязательно разложить граблей, без граблей это будет не юникс.
Локали обсуждали недавно, с их черезжопностью.
Пятый пример... Мне не сообразить сходу. Я подумаю, позже отпишу.
> alloca не канает?Говорят, у золотых рыбок долговременная память всё ж таки работает. А вот у тебя — не особо. Перечитай тред, что ли. Те же грабли есть в стандарте языка, только называются VLA, а посему — нет, не канает. Неспецифично.
> попробуй собрать пайпами цепочку команд и когда она обвалится, выяснить где собственно произошла ошибка.
На сишечке — запросто (ну ладно, не очень запросто, несколько десятков строк кода понадобится написать). В шелле сложнее, да. Но покажи, где подобное реализовано лучше. Да и нужно такое бывает крайне редко.
> Или взять пути в файловой системе, которые позволяют любые символы
Ну с натяжкой это можно назвать граблями, хотя, скорее, из-за засилья рукожопов, привыкших к ограничениям вынь-доса, чем по объективным причинам. Однако напомню твой тезис:
> верить в то, что всё пойдёт хорошо, и не оставлять ни единого костылика на случай, если всё пойдёт плохо, чтобы можно было бы ошибку как-нибудь осмысленно обработать.Где тут может вылезти ошибка, которую *невозможно обработать*? Я что-то такого не вижу.
> Локали обсуждали недавно, с их черезжопностью.
Если ты обсуждал их с голосами в своей голове, это не значит, что все анонимы тоже это слышали. Давай, рассказывай, где там возникают *ошибки, которые невозможно обработать*.
>> alloca не канает?
> Говорят, у золотых рыбок долговременная память всё ж таки работает. А вот
> у тебя — не особо. Перечитай тред, что ли. Те же
> грабли есть в стандарте языка, только называются VLA, а посему —
> нет, не канает. Неспецифично.Ты читать умеешь? Изобретена alloca в unix. vla изобрели резко позже по мотивам этой самой alloca.
>> попробуй собрать пайпами цепочку команд и когда она обвалится, выяснить где собственно произошла ошибка.
> На сишечке — запросто (ну ладно, не очень запросто, несколько десятков строк
> кода понадобится написать). В шелле сложнее, да. Но покажи, где подобное
> реализовано лучше.Где-где, в rust'е вестимо. Когда я пишу file.lines().map(...).filter(...).fold(...).бла-бла-бла, я всегда могу отследить источник ошибки.
> Да и нужно такое бывает крайне редко.
Да, "зелен виноград". Это не нужно, пока ты не начинаешь писать bash-портянки, пытаясь выдавать осмысленные сообщения об ошибках.
>> Или взять пути в файловой системе, которые позволяют любые символы
> Ну с натяжкой это можно назвать граблями, хотя, скорее, из-за засилья рукожопов,Хаха. Попробуй поработать с путями из шелла, попробуй пописать скрипты, которые будут работать с любыми именами файлов. Может после этого у тебя пропадёт желание говорить о жопах с руками.
>> верить в то, что всё пойдёт хорошо, и не оставлять ни единого костылика на случай, если всё пойдёт плохо, чтобы можно было бы ошибку как-нибудь осмысленно обработать.
> Где тут может вылезти ошибка, которую *невозможно обработать*? Я что-то такого не
> вижу.Попробуй из шелла поработать с путями. Где-то на просторах интернета был чувак, который исследовал способы работать с путями из шелла, и его вердикт был -- unix suxx.
>> Локали обсуждали недавно, с их черезжопностью.
> Если ты обсуждал их с голосами в своей голове, это не значит,
> что все анонимы тоже это слышали. Давай, рассказывай, где там возникают
> *ошибки, которые невозможно обработать*.https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02...
Локаль как глобальное состояние -- это то, за что изобретателям её нужно оторвать руки. Знаешь, когда я 20 лет назад, ковыряясь в коде какого-то рогалика, напоролся на замечательный код, который модифицировал глобальную переменную хранящую уровень, с тем чтобы при использовании вещи, чьё действие зависит от уровня, эта вещь сработала согласно тому, на каком уровне она была подобрана, а не тому, на котором уровне она была использована, я подумал, что это бредовый способ справляться с проблемами. Я подумал, что единственная причина простить чувака, который написал этот бред -- это то, что тот чувак такой же безрукий студент, как и я.
Но когда общесистемная хрень -- локали -- проектируются таким же образом, причём без единой задней мысли предоставить клиентскому коду, допустим, стек локалей, куда можно сделать push(locale) а потом pop(). То есть вообще просто взяли, присобачили глобал-стейт к каждому процессу, и хрен с ними со всеми потенциальными проблемами -- это либо полнейшая отмороженность, либо просто отсутствие мозга.
> Ты читать умеешь? Изобретена alloca в unix. vla изобрели резко позже по мотивам этой самой alloca.Умею, а что, есть сомнения? Раз притащили в стандарт, значит не посчитали вредным. Могли и не тащить.
> Где-где, в rust'е вестимо.
А rust разве в юниксах не работает?
> Это не нужно, пока ты не начинаешь писать bash-портянки, пытаясь выдавать осмысленные сообщения об ошибках.
Я не пишу bash-портянки. Я пишу скрипты на POSIX shell. И в них почему-то очень редко встречаются конвейеры более чем из двух-трёх команд, причём источником ошибки, как правило, может быть только одна из них. Смею предположить, это не потому что я пишу только хелловорлды, а потому что худо-бедно научился хорошему стилю скриптинга.
> Попробуй поработать с путями из шелла, попробуй пописать скрипты, которые будут работать с любыми именами файлов.
Да я уже немало лет этим занимаюсь (последний год меньше, но, вроде бы, навык пока не утратил).
> Где-то на просторах интернета был чувак, который исследовал способы работать с путями из шелла, и его вердикт был -- unix suxx.
Много я таких чуваков перевидал. Чего далеко ходить, тут половина анонимусов такие же. Не осилят чего-нибудь и начинают вопить про suxx.
> https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02...
wm4 в своём репертуаре. Чем писать эту хрень, мог бы чуть погуглить, узнать про существование C.UTF-8 и не позориться.
> Локаль как глобальное состояние -- это то, за что изобретателям её нужно оторвать руки.
А за концепцию окружения не надо? То ж самое ведь. Подумали только на пяток ходов вперёд, а не на десять. Бывает. Но ты так и не объяснил, где тут *ошибка, которую невозможно обработать*.
>> Ты читать умеешь? Изобретена alloca в unix. vla изобрели резко позже по мотивам этой самой alloca.
> Умею, а что, есть сомнения? Раз притащили в стандарт, значит не посчитали
> вредным. Могли и не тащить.Наличие чего-либо в стандарте на C -- это не показатель безвредности. Там гумна выше крыши.
>> Где-где, в rust'е вестимо.
> А rust разве в юниксах не работает?Если что-то работает в unix -- это не значит, что оно часть unix. MSO можно в linux запустить, и чо?
>> Это не нужно, пока ты не начинаешь писать bash-портянки, пытаясь выдавать осмысленные сообщения об ошибках.
> Я не пишу bash-портянки. Я пишу скрипты на POSIX shell.Это разные названия для одного и того же.
> них почему-то очень редко встречаются конвейеры более чем из двух-трёх команд,
> причём источником ошибки, как правило, может быть только одна из них.
> Смею предположить, это не потому что я пишу только хелловорлды, а
> потому что худо-бедно научился хорошему стилю скриптинга.Хахахахах. "хороший стиль скриптинга"! Лол. Ты сделал мой день. Да будет тебе известно, что хороший стиль скриптинга -- не писать скриптов.
>> Попробуй поработать с путями из шелла, попробуй пописать скрипты, которые будут работать с любыми именами файлов.
> Да я уже немало лет этим занимаюсь (последний год меньше, но, вроде
> бы, навык пока не утратил).И если ты не знаешь проблем с путями, значит навыка и не было никогда.
>> Локаль как глобальное состояние -- это то, за что изобретателям её нужно оторвать руки.
> А за концепцию окружения не надо?Нет. Концепция окружения позволяет прокидывать в процессы данные, которые в целом read-only для процесса. Их глобальность для процесса не влияет.
> То ж самое ведь. Подумали только на пяток ходов вперёд, а не на десять.
На фоне всего остального, я бы сказал, не "подумали", а повезло.
> Бывает. Но ты так и не объяснил, где тут *ошибка, которую невозможно обработать*.
Я выше дал ссылку. wm4 описывает ошибку, которую невозможно обработать. Весь его баттхёрт из этой ошибки.
> wm4 в своём репертуаре. Чем писать эту хрень, мог бы чуть погуглить, узнать про существование C.UTF-8 и не позориться.
И чем бы ему это помогло?
> Наличие чего-либо в стандарте на C -- это не показатель безвредности.Это показатель неспецифичности для Unix (третий раз повторяю, больше не буду).
> Если что-то работает в unix -- это не значит, что оно часть unix. MSO можно в linux запустить, и чо?
А bash можно в винде запустить. И там будет такая же фигня с конвейерами. И чё?
Выбирай инструмент, которые подходит для твоих целей. В шелле сделано разумно: покрывает 99% потребностей без чрезмерного усложнения.> Это разные названия для одного и того же.
Нет. Bash и POSIX shell — разные вещи. Портянка и скрипт — тоже разные вещи.
> хороший стиль скриптинга -- не писать скриптов.
Желаю тебе освоить хороший стиль комментирования.
> если ты не знаешь проблем с путями, значит навыка и не было никогда.
Я знаю проблемы, которые возникают у нубов. Как они решаются — тоже знаю. Мои навыки устраивают работодателей, а твоё мнение на сей счёт меня не волнует.
> Концепция окружения позволяет прокидывать в процессы данные, которые в целом read-only для процесса. Их глобальность для процесса не влияет.
Не распарсил.
> wm4 описывает ошибку, которую невозможно обработать. Весь его баттхёрт из этой ошибки.
Там слишком много баттхёрта, чтобы найти собственно ошибку. Можно TL;DR?
> И чем бы ему это помогло?
Не стонал бы по поводу того, что локаль C не UTF-8, и что UTF-8 нет в POSIX, а понял бы, что эту проблему активно решают, и решение, глядишь, в обозримом будущем докатится и до POSIX. Я понимаю, что ты мне не ради этого ссылку давал, но там 90% — вот эти вот глупые страдашки.
>> Концепция окружения позволяет прокидывать в процессы данные, которые в целом read-only для процесса. Их глобальность для процесса не влияет.
> Не распарсил.Попробуй пописать на чём-нибудь кроме bash. Я б рекоменовал функциональщину, тогда проблем парсить эти вещи не будет.
> эту проблему активно решают, и решение, глядишь, в обозримом будущем докатится и до POSIX
Хаха. Проблема с программой есть сейчас, а не через 20 лет.
Здрасьте, а чем Вам конвейер не функциональщина? (и, кстати, любимая грабелька с ... | ...; var=val; ... и последующей потерей этой var, которая оказалась в другом экземпляре интерпретатора -- здесь как раз фича "readonly для процесса")
Функциональщина, да. Но она ему не помогает понимать глобальное ридонли состояние. Поэтому лучше не элементы функциональщины использовать, а взять и освоить функциональное программирование в целом, научится думать в этих терминах.
> Попробуй пописать на чём-нибудь кроме bash.Это последний мой ответ тебе, поскольку ты всё равно не утруждаешь себя их чтением. Я не пишу на bash.
>> Попробуй пописать на чём-нибудь кроме bash.
> Это последний мой ответ тебе, поскольку ты всё равно не утруждаешь себя
> их чтением.Чё серьёзно?
> Я не пишу на bash.
Продолжай и дальше заниматься этим буквоедством, я уверен люди к тебе потянутся со временем.
>> Я-то новость прочитал, ещё б ты прочитал вопрос, на который отвечаешь… Попрубуем
>> ещё разик: Причём здесь unix way, да и вообще unix?
> Потому что это вообще очень по юниксовому -- верить в то, что
> всё пойдёт хорошо, и не оставлять ни единого костылика на случай,
> если всё пойдёт плохо, чтобы можно было бы ошибку как-нибудь осмысленно
> обработать.Нормальное ты себе определение придумал. Только зачем эту дичь другим впаривать заправду?
>>> ещё разик: Причём здесь unix way, да и вообще unix?
>> Потому что это вообще очень по юниксовому -- верить в то, что
>> всё пойдёт хорошо, и не оставлять ни единого костылика на случай,
>> если всё пойдёт плохо, чтобы можно было бы ошибку как-нибудь осмысленно
>> обработать.
> Нормальное ты себе определение придумал.Ну вообще-то это не он придумал.
---
I remarked to Dennis that easily half the code I was writing in Multics was error recovery code. He said, "We left all that stuff out of Unix. If there's an error, we have this routine called panic, and when it is called, the machine crashes, and you holler down the hall, 'Hey, reboot it.'"
--- Tom Van Vleck(здесь Dennis -- это Ritchie)
> Можно. С тем же результатом, включая сюда и UB.Явное выделение на стеке? UB!
Временная переменная функции? UB!
Сохранение регистров и вызов функции? UB!!!11Стек Шрёдингера
>> Можно. С тем же результатом, включая сюда и UB.
> Явное выделение на стеке? UB!
> Временная переменная функции? UB!
> Сохранение регистров и вызов функции? UB!!!11
> Стек ШрёдингераВ целом да. C он вообще такой. Разные другие языки выделяют память под стек динамически, или на этапе компиляции вычисляют необходимый размер стека, или разделяют стек на два: control-stack и data-stack. В C же принято полагаться на "авось". Это даже работает в большинстве случаев. Но выделение памяти динамического размера на стеке -- это явно целенаправленная попытка выйти за границы применимости этого "авось".
> Разные другие языки выделяют память
> под стек динамическиman mmap
См. MAP_STACK. Достаточно динамически>или на этапе компиляции вычисляют необходимый размер стека
Implementation-specific. В данном случае это к компилятору.
> или разделяют стек на два: control-stack и data-stack
Implementation-specific. Кстати, есть архитектуры двумя с "аппаратными" стеками. Эльбрусы, например.
> В C же
> принято полагаться на "авось".В Си, если программа чего-то не делает, то считается, что программисту виднее.
> Но
> выделение памяти динамического размера на стеке -- это явно целенаправленная попытка
> выйти за границы применимости этого "авось".Стек весь "авось". Везде.
Вот где годнота - https://github.com/otavio/rsget
Hey, buddy, I think you've got the wrong door. The Rust club is two blocks down!
Сам юзай этот хелловорлд.
Годнота может быть написано только на Го https://github.com/melbahja/got
Или говно.
Гоуно
Говно уже написано на Го https://github.com/nicklasos/govno
но читается не как го, а как гоу.
Го читается так, как его читают, а не так как вы разрешите.Кстати, с питоном то же самое. Однажды слышал как один чел произнёс "пайтхон", потом как-то стыдливо запнулся и начал по нормальному говорить
Вы что, совсем? А как же безопасность?
В Го безопасности сильно больше чем в Храсте. Да даже побольше чем в node.js.
Кто-то успел уже пожаловаться автору программы и он изменил название свое программы с govno на got. Я бы на месте разработчика не поддавался бы на провокации.
got? Global Offset Table?
Растофаны никак не уймутся.
> Повышены требования к версии библиотеки gettext (0.19.3+).Извините, но --diable-nls всегда и везде, никому это ненужно.
Вот кстати да, приятно видеть адеквата в интернете. Ну это до тех пор пока твоё ПО не на китайском/испанском в оригинале, там конечно другие песни начинаются.
> ПО на китайском/испанском в оригинале,Первый раз вообще слышу что такое бывает, разве что предположу что такое ПО скорее всего не нужно.
wget2 еще не довели до ума?
Хз. Есть ещё aria2
Гораздо лучше чем curl от Васяна.
Я, конечно, догадываюсь, что это был сарказм, но программы просто решают несколько разные задачи. Wget эта такая скачивалка сайтов (think teleport pro) и больше от неё ничего не требуется.Хотя, как по мне, если нужен менеджер закачек, лучше бы aria2 пилили -- в ней до сих пор скачивание торрентов поломано, все остальные клиенты уже напихали костылей. Да и с раздачей нескольких хешей одновременно говорят проблемы.
Я догадываюсь, почему на неё забили, с такими то пользователями https://github.com/aria2/aria2/issues/1708Но это могли бы и исправить. Специально нашёл
Exception caught
Exception: [bittorrent_helper.cc:276] errorCode=26 Detected directory traversal directive in *dirname*
wget скачивалка сайтов? Вот это поворот.
Я тоже удивился, когда узнал это (на самом деле нет). При этом, оно плохо справляется со своей основной задачей, httrack лучше. Ну, это считается за менеджер загрузок, но по факту из ценного функционала там только скачивание сайтов (не очень удобное) и для скачивания ссылок aria2 намного предпочтительнее. Видимо, из-за того, что по устаревшим представлениям о сайтах писали.
…httrack…, чувак, ты из какой-то параллельной реальности wget у тебя сайты качать. А гвозди палкой забивать. curl наверно ядро собирать.
Прикинь, да?
$ apropos wget
wget (1) - The non-interactive network downloader.
А если ман откроешь, ваще упадёшь:
Wget can follow links in HTML, XHTML, and CSS pages, to create local
versions of remote web sites, fully recreating the directory structure
of the original site. This is sometimes referred to as "recursive
downloading." While doing that, Wget respects the Robot Exclusion
Standard (/robots.txt). Wget can be instructed to convert the links in
downloaded files to point at the local files, for offline viewing.
wget это просто curl здорового человека не надо тут грязи.
Это wget 2 пытается им стать. Как выйдет — поглядим, насколько успешно.
> wget это просто curl здорового человека не надо тут грязи.открой уже ман по вгету что ли. ты и так уже тонну ереси написал, а все продолжаешь гнуть свое.
wget - просто качалка файлов. и он таки может целиком (рекурсивно) качать сайты, там есть функция рекурсивного зеркалирования (ключи -r -m и т.д.).
curl - утилита для полноценной работы по протоколу http, умеет в т.ч. обрабатывать формы, отправлять данные НА СЕРВЕР и вообще почти все, что умеет протокол. и качание файлов это лишь ничтожная часть функционала.
именно по этой причине curl несколько сложен для обывателя, вот им и мерещится в wgete аналог, хотя это совершенно разные утилиты как по предназначению, так и по задачам решаемым.
> умеет в т.ч. обрабатывать формы, отправлять данные НА СЕРВЕРНу это-то, положим, и wget умеет, если оно POST-запросом делается. Другое дело, что curl умеет вообще любые типы запросов. И помимо HTTP и FTP ещё пару десятков протоколов знает.
wget --mirror
И что они даже поддержку FTP не удалили? Как они это сумели? Откуда финансирование его поддержки взяли?
Free Software Foundation дало денег.
lftp лучше.
Как изменить имя ,передаваемое при соединении?
> Как изменить имя ,передаваемое при соединении?-O
Хм... https://packages.debian.org/sid/wget2 (GNU Wget2 is the successor of GNU Wget). И чем пользоваться теперь?
Currently GNU Wget2 is being developed.