mv: невозможно указать Нет такого файла или каталога в сценарии оболочки
Я написал скрипт для перемещения некоторых файлов из одной папки в другую, но я получил следующую ошибку, я проверил 2 папки и заметил, что для 1 папки есть такие файлы, а для другой нет таких файлов, но почему все они показывают «mv нет статистики Нет таких файлов или каталогов «
Я запустил это в /home/esolve/project/capture/tcp_50x50/
Кавычки ( ‘ ) не позволяют оболочке выполнять сглаживание. Команда * передается буквально mv команде, которая завершается ошибкой, поскольку не находит файлы, вызываемые * в указанных каталогах.
Измените это на:
(Двойные кавычки для предотвращения проблем, если у вас когда-либо есть имя каталога с пробелами в нем. За * пределами кавычек.)
Вы все равно получите ошибки для пустых каталогов. (Такая же причина: если файл не находит соответствия для шаблона, он передает сам шаблон в качестве аргумента команде.)
Есть несколько проблем с вашим кодом:
Вы сохраняете вывод ls без завершающих символов новой строки в $list . ls выводит список имен файлов, разделенных символами новой строки. newline является таким же допустимым символом, как и любой другой в имени файла, поэтому вывод не может быть надежно использован. Например, ls выходные данные для каталога, который содержит a и b такой же, как и для каталога, который содержит один файл с именем a b .
Вы не проверяете провал этой команды. В общем, вам следует проверять состояние выхода команд, но это особенно верно cd , потому что остальные команды предполагают, что вы находитесь в этом новом каталоге, и это может иметь драматические последствия, если вы этого не сделаете.
Оболочки POSIX уже поддерживают (один) путь к текущему каталогу в $PWD переменной, поэтому вам не нужно использовать его pwd здесь (особенно в общем случае, так как подстановка команд удаляет завершающие символы новой строки из пути). Кроме того, mv принимает относительные пути, поэтому вам не нужно создавать абсолютный путь.
Оставляя переменную без кавычек, это оператор split + glob в оболочках. То есть содержимое переменной разделяется (на разделители, упомянутые в $IFS специальных правилах для пробельных символов), и каждый элемент, полученный в результате этого разделения, ищется с подстановочными знаками, чтобы их можно было развернуть в список подходящих файлов.
Здесь вам нужно разделение, но только для символов новой строки, и вы не хотите, чтобы сглаживание происходило, поэтому вам нужно отключить его:
Опять же, оставляя переменную без кавычек, это оператор split + glob . Здесь вы не хотите ни того, ни другого, поэтому вам нужно заключить эти переменные в кавычки.
Как уже упоминалось, подстановочные знаки расширяются только тогда, когда они не * заключены в кавычки, поэтому вам нужно убрать их из кавычек. Если вы ранее отключили глобализацию с помощью set -f , вам нужно будет восстановить ее set +f до вызова этой команды.
Намного лучший способ написать это было бы:
Несколько заметок, хотя:
- Это исключит скрытые папки и не будет перемещать скрытые файлы из data папок.
- Мы не проверяем файлы, перезаписываемые в процессе (вы можете добавить эту -i опцию в mv ).
- Используя */ , мы зацикливаемся только на каталогах , но это включает и символические ссылки на каталоги. Если вы не хотите, вам нужно добавить [ -L «$
- Если там нет скрытой папки, */ она развернется сама по себе, поэтому вы получите сообщение об ошибке, в mv котором говорится, что не удается найти файл с именем */data/* . Точно так же, если в любой из папок нет скрытого файла, вы получите сообщение об ошибке, that-folder/data/* которого не существует.
Источник
Одна строчка bash
Далее идёт изменение расширения файлов и mv для замены:
Но путь к файлу не виден как одно целое, выдаётся сообщение:
и т.д. Как бы без переименования директорий в версию без пробелов решить проблему?
for i in lol*;do echo lol $i; done
Ему в переменную нужно засунуть.
Так уже пытался. )
ls всё равно лишний
Правильный вариант. особенно если файлов очень много (тысячи)
третий вариант, с массивом (обрати внимание на кавычки, они обязательны):
Четвёртый вариант, без массива, потому что он не нужен.
Не знаю, что я мог вставить не так, но все файлы просто. удалились! Хорошо, это копии были. =)
Если вместо mv поставить cp, то всё останется в первозданном виде.
Четвёртый вариант, без массива, потому что он не нужен.
что люди только не придумают, лишь бы не использовать кириллицу и пробелы в названиях!
Это точно. Но при вводе пути к файлу неудобно туда-сюда раскладку менять. )
что люди только не придумают, лишь бы не использовать кириллицу и пробелы в названиях!
Не знаю, что я мог вставить не так, но все файлы просто. удалились!
Поэтому первоначальный вариант должен содержать что-то типа
mv не удаляет файлы, он их может только перезаписывать, поэтому, в подобных скриптах, где одни фалы не должны записываться под именем уже существующих, лучше указывать ″mv″ опцию ″-i″ или ″-n″.
Они мереместились в текущий каталог, откуда запускалдся скрипт сорри, я забыл что basename ест пути
открой для себя двойные кавычки.
мал ты ещё для правильных вариантов.
Не претендуя на правильность дам свой вариант:
а ты поняшка, не умеешь двойные кавычки, вот они у тебя и не работают.
mv не удаляет файлы, он их может только перезаписывать
mv наоборот не может перезаписывать и удаляет. Потому можно и нужно юзать —backup (с ним mv не удаляет старый файл, а только меняет имя).
ЗЫЖ зачем людей путаешь?
Это не ко мне, это к разработчикам ″mv″, у них в докуменации фигурирует термин ″overwrite″.
А использовать опцию ″—backup″ в скриптах, подобных написанному ТС’ом, хуже, чем ″-i″. В случае типовой ошибки, когда все файлы перемещаются под одно имя, ″—interactive″ выдаст предупреждение уже на втором файле и можно ″Ctrl+C″ и искать ошибку.
твой правильный вариант сломается, если в названии файла появится ‘\n’
Это не ко мне, это к разработчикам ″mv″, у них в докуменации фигурирует термин ″overwrite″.
А использовать опцию ″—backup″ в скриптах, подобных написанному ТС’ом, хуже, чем ″-i″. В случае типовой ошибки, когда все файлы перемещаются под одно имя
я разве говорил, что надо обязательно —backup без параметра?
man страница у разных версий coreutils разная, но вот вывод самой команды mv, вроде, давно неизменный:
Я отвечал на фразу «файлы просто. удалились!» и своим ответом хотел сообщить ТС’у, что ″mv″, в отличии от ″rm″, просто так не удаляет файлы, он может под именем существующего файла записать другой файл и это поведение настраивается. Не знаю, может ″overwritе″ нужно переводить другим словом, но меня и «перезаписывает» устраивает.
-i, —interactive prompt before overwrite
ну там только эффект как при перезаписи. На самом деле файл не перезаписывается, а создаётся новый. А вот подтверждение даётся именно в том случае, если эффект операции равносилен перезаписи файлов.
Да только толку от этой опции никакого, если оно для многих файлов. Проще взять mc или ФМ какой-нить. Консоль она для интерактива не предназначена.
Я всё к тому говорил, что в CLI проще постфактум обрабатывать особые случаи. Или предварительно. Но никак не интерактивно.
А в скрипте, который тут ТС писал надо rename юзать, а не mv.
Источник
Вопрос
Добрый вечер,у меня такой вопрос собственно,есть исполняемый файл sh в папке,в консольке ввожу ./pack_bootimage.sh после этого он должен запаковать мне ядро,так вот собственно вопрос,почему он пишет,что у меня нет такого файла и католога если он есть? Выставлял права на исполнение файлов,все равно ничего не дает,причем до этого стояла убунта,навернулась у меня она,там работало все,вчера поставил убунту,не пашет
потому что у тебя нет такого файла или каталога
Есть,в этом все и дело
Докажи что они есть
в том каталоге, где лежит скрипт?
Да,все проверил,проверил в скрипте пути,все правильно указано
Возможно, в строках 1-4 эти файлы должны создаваться, но что-то им мешает. Код скрипта мог бы помочь.
#!/bin/bash #make to bootimage.sh PRJ=s9086b_wet_kk echo » gen out/target/product/tinno89_wet_kk/ boot.img . » mediatek/build/tools/images/acp -uv out/target/product/$
Так ничего не понятно. Лучше использовать теги [code][/code] или сторонний сервис типа pastebin.
Источник
Проблемы пробелов в скрипте bash
Все добрый день.
Пытаюсь написать скрипт типа:
Без кавычек с «\ » тоже самое. Как правильно-то тогда?
А ещё лучше cp — «$
Пробелы в имени всё равно экранировать.
Какую функцию призвана выполнять гора скобок <, >?
Пробелы в имени всё равно экранировать.
Пробелы в имени всё равно экранировать.
Уже даже и не помню, тоже от какого-то простреливания ног защищает. Это же баш.
Какую функцию призвана выполнять гора скобок <, >?
чтобы отделять имя переменной от строки, которая должна подклеиваться к значению переменной при подстановке
чтобы отделять имя переменной от строки, которая должна подклеиваться к значению переменной при подстановке
Оберег :3
Вне контекста типа «$arg1_$arg2_$arg3» (где он необходим) он ни от чего не защищает.
Какую функцию призвана выполнять гора скобок <, >?
Ну как же, модно-молодежно. Зачем экранировать пробелы — не помнят, зачем скобки — тоже. А сказать хочется.
Вне контекста типа «$arg1_$arg2_$arg3» (где он необходим) он ни от чего не защищает.
Хаотично раскиданные вокруг грабли имеют свойство бить по башке там где ты меньше всего ожидаешь, поэтому лучше убрать их все заранее.
Привет, 
vodz .
Хаотично раскиданные вокруг грабли имеют свойство бить по башке
Уже даже и не помню, тоже от какого-то простреливания ног защищает.
Грабли возникают вот от второго.
Зачем держать в голове всякий мусор, появившийся в результате жизнедеятельности костылявших шелл наркоманов, если можно сразу писать надёжно-молодёжно™?
если можно сразу писать надёжно-молодёжно
Объясняю. Если убрать все <>, то в вашем скрипте можно смело менять bash на sh, при этом эффект будет тем же самым и даже работать быстрее будет.
Если убрать все <>, то в вашем скрипте можно смело менять bash на sh
Если бы бабушка была бы дедушкой. У ТСа в тегах этого треда и в первой строчке приведённого им скрипта указан bash, значит ему нужен именно он.
Задача ТСа настолько детсадовская, что тред интересен только как Вы лично выкрутитесь от того факта, что bash вы толком не знаете, а советы даёте. Уж не знаю, что вы вынесли из треда насчёт скобочек, но судя по всему насчёт экранирования пробелов — ничего.
Откуда ты знаешь задачу ТСа, экстрасенс что ли? Может у него в стартовом посте кусок тестового скрипта, который он куда-нибудь пытается присобачить, а ты ему советуешь sh вместо баша впендюрить.
Вы лично выкрутитесь от того факта, что bash вы толком не знаете, а советы даёте
Всего знать нельзя и с этим фактом спорить глупо. Однако в данном случае я знаю достаточно.
судя по всему насчёт экранирования пробелов — ничего
Какие проблемы с пробелами?
Откуда ты знаешь задачу ТСа, экстрасенс что ли?
Задача ТСа — понять как обрабатывать пробелы в скрипте. Всё остальное — такие же измышлизмы.
У вас? Так я цитировал ваш текст, который вы так и не скоректировали новым ответом по модно-молодёжной моде гордиться своим незнанием.
Задача ТСа — понять как обрабатывать пробелы в скрипте
Нет. Задача ТСа — написать скрипт на баше, в котором в т.ч. должны экранироваться пробелы.
У вас? Так я цитировал ваш текст, который вы так и не скоректировали новым ответом по модно-молодёжной моде гордиться своим незнанием.
Если ты о случайно повторившейся цитате — думаю что в отличие от тебя пользователь d_a , которому я отвечал, давно понял что именно я имел в виду.
Эта личная переписка уже достала.
Задача ТС указана в , «в т.ч.» — это ваши измышлизмы, не относящиеся к делу.
Чего там парсить? Речь шла о нахождении грабель там где их может найти только незнающий bash.
можно смело менять bash на sh
Но не нужно. И совершенно не надо знать о существовании башизмов (точнее, об информации, что где-то чего-то нет). Зачем забивать себе голову абсолютно ненужной информацией?
Подскажи оболочку, в которой $ не сработает.
Зачем забивать себе голову абсолютно ненужной информацией?
Постараюсь ответить литературно, ибо как выше упоминал — моду гордиться незнанием не приемлю.
Это профессионализм, приходящий с опытом, автоматом. «О, новая версия имеет такую фичу. А я раньше сколько крови на это пролил. » Потом к ней привыкаешь и вдруг оказывается, что надо поадминить какой-нить чпукс, а руки сами вбивают понравившуюся фичу, а мозг судорожно пытается понять, чего же оно ругается. Потом это обрастает пылью и само забывается, как результат, первым делом устанавливается glibc/bash/gcc, а уж потом приступаешь к администрированию.
И нет нет, это не из серии раньше трава была зеленей и прочих сперва добейся. Это из серии, что знать всё не возможно, но выдавать своё незнание за добродетель совершенно идиотское веяние времени. А потом удивляются, откуда на ЛОРе хамство, личная переписка, откровенный мусор за мемами типа «не нужно».
Подскажи оболочку, в которой $ не сработает.
Это было давно. Но не о том была речь. Был вопрос, зачем тут <>? Ответ выдал непонимание.
Ну да. Скобочки нисколько не выключают парсер имени по [A-Za-z0-9_], но включают его сложный вариант для Parameter Expansion. Так что как минимум два символа <> и простой парсер ускорит работу.
моду гордиться незнанием не приемлю
Быстро и решительно мне прочитал Фому Аквинского на средневековом диалекте каталонского.
Нет, это брюзжание некомпетентного непрофессионала.
Потом к ней привыкаешь и вдруг оказывается, что надо поадминить какой-нить чпукс
Во-первых, на чпуксе есть баш. Во-вторых, трением добывать огонь ты тоже умеешь? А то ВДРУГ бах и голый на необитаемом острове. В-третьих, самое главное — это что, старик Хоттабыч прилетел и все компьютеры на чпукс переделал и ты такой хоп и опа? Если тебя пригласили рулить чпуксом, значит либо ты уже с ним работал (и знаешь, чего там есть, а чего там нет), либо ты считаешься достаточно компетентным специалистом, чтобы с ним справиться, а компетентный специалист способен прочитать документацию, я тебе это гарантирую.
Потом это обрастает пылью и само забывается, как результат, первым делом устанавливается glibc/bash/gcc, а уж потом приступаешь к администрированию
Ничерта не понял в чём мораль. Это хорошо или плохо? И почему?
Это из серии, что знать всё не возможно, но выдавать своё незнание за добродетель совершенно идиотское веяние времени
Знать устаревшую технологию — это нормально. Когда-то она была не устаревшей.
Гордиться этим знанием — это снобизм. В этом нет повода для гордости.
Изучать устаревшую технологию, потому что она тебе понадобилась — это нормально, профессия археолога, даже айтишного, — тоже профессия.
Заставлять оглядываться на устаревшую технологию только потому, что ты её знаешь, а тот, кто делает, не знает, — это полный распад мозга.
Остальное можно было не писать. Нахамить в три короба с «гарантией» в режиме божественного откровения на весьма вежливый текст и радостно признаться что «ничерта не понял». ЧТД.
Ну да. Скобочки нисколько не выключают парсер имени по [A-Za-z0-9_], но включают его сложный вариант для Parameter Expansion. Так что как минимум два символа <> и простой парсер ускорит работу.
dash и busybox sh $<> быстрее раскрывают и заметно это становится при сотнях тысяч parameter expansion.
если можно сразу писать надёжно-молодёжно
Объясняю. Если убрать все <>, то в вашем скрипте можно смело менять bash на sh
А зачем вам менять ГНУ Баш такие древние шеллы, у которых даже с этим проблемы?
dash и busybox sh $<> быстрее раскрывают и заметно это становится при сотнях тысяч parameter expansion.
Заинтересовали, обязательно посмотрю. Логически это странно.
Если вы поменяете #!/bin/bash на sh на системе с /bin/sh-> /bin/bash у вас ничего не изменится, но вам спасибо скажут те, у которых вообще нет /bin/bash
чтобы отделять имя переменной от строки, которая должна подклеиваться к значению переменной при подстановке
в данном примере это не нужно
dash и busybox sh $<> быстрее раскрывают и заметно это становится при сотнях тысяч parameter expansion.
Заинтересовали, обязательно посмотрю. Логически это странно.
Посмотрел. Не правда ваша. При VSNORMAL и subtype=0 парсер намного тупее, что и следовало ожидать, тупо do is_name() . и выход, а при ‘<' там проверяется, есть ли первый '#' а потом все символы не is_name() до '>‘.
Разве parameter expansion парсером выполняется?
Разве parameter expansion парсером выполняется?
Во-первых, parameter expansion тоже парсер. Во-вторых, для $VAR parameter expansion не вызывается вообще, varvalue и вперед.
Это не проблемы, это фича)) Баш нужен для коротких однострочников в консоли и как бы сам намекает на необходимость смены инструмента.
Просто пробел в shell является основным управляющим синтаксическим элементом, что почему-то смущает программистов на пыхтонге, хотя у них как ни странно тоже.
Ошибся и не выполнил присваивание переменной a перед 100500 $ . При прочих равных $ парсится немного быстрее $a .
Я вот посмотрел код, который сам и утаптывал в busybox-ный (d)ash, копирайт мой там на это и стоит. Смотреть пришлось потому что это было давно. Выводы озвучил. А ваши повторения — бездоказательные.
проиграл, развел тут срач на тему совместимости и внутреннего устройства шеллов, хотя оп пост совсем про другое. всем насрать на скобочки и скорость баша, такие дела, дедуля
Если вы поменяете #!/bin/bash на sh на системе с /bin/sh-> /bin/bash у вас ничего не изменится, но вам спасибо скажут те, у которых вообще нет /bin/bash
Я спросил иное. Сколько вообще этих «тех», у каких завалялись такие древние оболочки, что они даже в $<> не умеют?
Вот и обтекайте молча
Вы спросили зачем менять. Я вам ответил. Нет никакого в данной задачи смысла юзать конкретно bash. Скобочки тут совсем не при чём. Ибо как выяснилось срач развели от незнания где и как проявляется пробельный разделитель. Про шеллы без скобочек тоже отвечал — таких не осталось.
Источник
