LINUX.ORG.RU

[wget]имена закачиваемых файлов

 


1

1

Имеется большая файлопомойка (ФП) у прова. ФП входит в пиринговую зону. Ссылки для закачки выдаются вот такие длинные:

http://files.amur.data.cod.ru/?WyIzMTBmNTE4ZjYxYjZiMjU0YTIzODFjMDBhMWRmMWNiMS... Обычно файлы лежат кусками. Файлы обычно имеют вид «имяфайла».partNN.rar. Если я закачиваю по одиночке и сам указываю имя файла -О имя_файла.part01.rar, то закачка идёт хорошо. Если не указываю имя, то выдаёт ошибку «Слишком длинное имя файла».

Поэтому вопросы: Можно ли научить wget определять имя файла по ссылке? Если нет, можно ли указать wget'у имёна файлов, если ссылки записать в отдельный файл?

А если так?

dog --links http://бла-бла-бла | grep rar > linklist ; wget -i linklist

kraftello ★★★★★
()

Не могу пройти по твоей ссылке

Или сначала посмотреть linklist, выкинуть ненужные ссылки и wget -i linklist (ну или как этот файл обзовёшь)

kraftello ★★★★★
()
Ответ на: комментарий от Slavaz

Поясню немного. Эти ссылки, которые я привёл, уже окончательные. Если я прохожу по этой ссылке в броузере (нажимаю кнопку), то броузер начинает скачивать файл с правильным именем. Почему wget так не может?

gingerino
() автор топика
Ответ на: комментарий от Slavaz

--content-disposition Вот самое оно и есть! Большое Вам спасибо!

gingerino
() автор топика
Ответ на: комментарий от gingerino

Поясню в ответ: это не окончательные ссылки. То есть, они выглядят как файлы, лежащие на файловой системе, но на самом деле эти ссылки обрабатываются какой-нибудь CGI-шкой, а сама CGI-шка маскируется через mod_rewrite, например. Если бы так не было, браузер скачивал бы не правильное имя, а то, которое в строке адреса.

Теперь почему браузер скачивает с нормальным именем, а wget не может: дело в том, что есть такая строка ответа браузера: Content-Disposition. Обычно эту строку пишут CGI-шки и прочие пехепе с перлами, прикидывающимися окончательным файлом.
В этой строке ответа и может указываться реальное имя скачиваемого файла. Браузера по умолчанию обращают внимание на этот ответ сервера и поэтому сохраняемое имя нормальное. wget же по умолчанию выполняет свои прямые функции: скачивать из интернета указанную информацию. При этом он по умолчанию же не обращает внимания на ответ «Content-Disposition».
Чтобы wget «научить» уважать этот ответ сервера, нужно добавить опцию комстроки; или чтобы каждый раз не писать эту опцию, нужно почитать man на предмет wgetrc.

Исчерпывающе?

Slavaz ★★★★★
()
Ответ на: комментарий от Slavaz

> Исчерпывающе? Весьма!

Прописал в .wgetrc строку

content-disposition = on

Еще раз спасибо.

gingerino
() автор топика
Ответ на: комментарий от Slavaz

Тоже спасибо, пригодится.

...experimental (not fully-functional) support, но работает. Век живи, век учись.

kraftello ★★★★★
()
Ответ на: комментарий от Slavaz

Будет ли в этом случае работать скрипт, который вначале запрашивает заголовок через curl -I, берёт имя файла из строки Location:..., затем сохраняет файл с полученным именем через curl -O ? Потребуется ли ещё идти по цепочке редиректов (ключ -L)?

question4 ★★★★★
()
Ответ на: комментарий от pupok

>сказано же что руками через "-O" он указывать имя не хочет.

-O/--remote-name Write output to a file named as the remote file

Иногда лучше жевать… ;)

AX ★★★★★
()
Ответ на: комментарий от question4

> Будет ли в этом случае работать скрипт, который вначале запрашивает заголовок через curl -I, берёт имя файла из строки Location:..., затем сохраняет файл с полученным именем через curl -O ? Потребуется ли ещё идти по цепочке редиректов (ключ -L)?

Скрипт работать будет, редиректы не нужны. Но лучше заюзать опцию -J у curl'а - это ровно то же, что и --content-disposition у wget'а :)


Slavaz ★★★★★
()
Ответ на: комментарий от AX

> Иногда лучше жевать… ;)

ну не читал я man curl, и что ? :) «curl -O» всё равно, как уже объяснили, ответ неправильный.

pupok ★★
()
Ответ на: комментарий от Slavaz

опция -J у curl'а

Вячеслав, спасибо за наводку на опцию -J у curl'a, пол-дня бился с этой проблемой, опция помогла сохранять файлы с правильным именем. Но возникла еще одна проблема, когда я попытался сохранить файл с русским названием curl сохранил его под названием ������� � �������.txt . в консоли название этого файла отображается как ./??????? ? ???????.txt Этот файл теперь невозможно удалить (я так понял, это проблемы с несоответствующей кодировкой имени файла; моя системная кодировка - LANG=ru_RU.UTF-8 ) Возникают два вопроса, как удалять/переименовывать подобные файлы, и как предотвратить их появление при закачке с помощью curl. заранее спасибо за ответ. Сергей

anonymous
()
Ответ на: опция -J у curl'а от anonymous

Как удалять такие файлы разобрался - миднайт коммандер удалил файл без проблем ( у меня версия mc 4.7.0.3) Осталось разобраться с тем, чтобы curl корректно сохранял скачанные файлы с кириллицей в названии. Сергей

anonymous
()
Ответ на: опция -J у curl'а от anonymous

> Но возникла еще одна проблема, когда я попытался сохранить файл с русским названием curl сохранил его под названием ...

Если в mc, то попробуйте ALT-e в панели и выберите кодировку (вдруг будет нужная). Если кодировка та, что надо, то просто скопируйте файл в другое место.

Или посмотрите в сторону утилиты convmv

Slavaz ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.