Одна строчка bash
Далее идёт изменение расширения файлов и mv для замены:
Но путь к файлу не виден как одно целое, выдаётся сообщение:
и т.д. Как бы без переименования директорий в версию без пробелов решить проблему?
Ему в переменную нужно засунуть.
ls всё равно лишний
Правильный вариант. особенно если файлов очень много (тысячи)
третий вариант, с массивом (обрати внимание на кавычки, они обязательны):
Четвёртый вариант, без массива, потому что он не нужен.
Не знаю, что я мог вставить не так, но все файлы просто. удалились! Хорошо, это копии были. =)
Если вместо mv поставить cp, то всё останется в первозданном виде.
Четвёртый вариант, без массива, потому что он не нужен.
что люди только не придумают, лишь бы не использовать кириллицу и пробелы в названиях!
Это точно. Но при вводе пути к файлу неудобно туда-сюда раскладку менять. )
что люди только не придумают, лишь бы не использовать кириллицу и пробелы в названиях!
Не знаю, что я мог вставить не так, но все файлы просто. удалились!
Поэтому первоначальный вариант должен содержать что-то типа
mv не удаляет файлы, он их может только перезаписывать, поэтому, в подобных скриптах, где одни фалы не должны записываться под именем уже существующих, лучше указывать ″mv″ опцию ″-i″ или ″-n″.
Они мереместились в текущий каталог, откуда запускалдся скрипт сорри, я забыл что basename ест пути
открой для себя двойные кавычки.
мал ты ещё для правильных вариантов.
Не претендуя на правильность дам свой вариант:
а ты поняшка, не умеешь двойные кавычки, вот они у тебя и не работают.
mv не удаляет файлы, он их может только перезаписывать
ЗЫЖ зачем людей путаешь?
Это не ко мне, это к разработчикам ″mv″, у них в докуменации фигурирует термин ″overwrite″.
А использовать опцию ″—backup″ в скриптах, подобных написанному ТС’ом, хуже, чем ″-i″. В случае типовой ошибки, когда все файлы перемещаются под одно имя, ″—interactive″ выдаст предупреждение уже на втором файле и можно ″Ctrl+C″ и искать ошибку.
твой правильный вариант сломается, если в названии файла появится ‘\n’
Это не ко мне, это к разработчикам ″mv″, у них в докуменации фигурирует термин ″overwrite″.
А использовать опцию ″—backup″ в скриптах, подобных написанному ТС’ом, хуже, чем ″-i″. В случае типовой ошибки, когда все файлы перемещаются под одно имя
man страница у разных версий coreutils разная, но вот вывод самой команды mv, вроде, давно неизменный:
Я отвечал на фразу «файлы просто. удалились!» и своим ответом хотел сообщить ТС’у, что ″mv″, в отличии от ″rm″, просто так не удаляет файлы, он может под именем существующего файла записать другой файл и это поведение настраивается. Не знаю, может ″overwritе″ нужно переводить другим словом, но меня и «перезаписывает» устраивает.
ну там только эффект как при перезаписи. На самом деле файл не перезаписывается, а создаётся новый. А вот подтверждение даётся именно в том случае, если эффект операции равносилен перезаписи файлов.
Да только толку от этой опции никакого, если оно для многих файлов. Проще взять mc или ФМ какой-нить. Консоль она для интерактива не предназначена.
Я всё к тому говорил, что в CLI проще постфактум обрабатывать особые случаи. Или предварительно. Но никак не интерактивно.
А в скрипте, который тут ТС писал надо rename юзать, а не mv.
Копирование содержимого одного каталога в другой
если в /p/a/t/h/ лежат только скрытые файлы и папки.
Пишет: cp: не удалось выполнить stat для ‘/p/a/t/h/*’: Нет такого файла или каталога
Нужно СОДЕРЖИМОЕ ОДНОГО КАТАЛОГА скопировать в другой.
В инете нашёл способ с добавлением точки.
Работает, но я его не понимаю. Он какой-то недокументированный. Ни в хелпе, ни в мане про это ничего не сказано.
Как это всё-таки правильно делать?
YuraRimskiy
Он какой-то недокументированный. Ни в хелпе, ни в мане про это ничего не сказано
все файлы кроме скрытых копируются из каталога 1 в каталог 2
копируются только скрытые файлы из каталога 1 в каталог 2
копируются все файлы (скрытые и не скрытые)
YuraRimskiy
Он какой-то недокументированный. Ни в хелпе, ни в мане про это ничего не сказано.
там работает не документация а логика )
Текущий и родитель не попадают, только файлы и папки, в т.ч. скрытые. Не знаю, насколько феншуен вариант в целом, но пользовался много раз и без проблем.
cp –recursive –verbose 1/ <*,.*>2
cp –recursive –verbose 1/. 2
эквивалентны (относительно результата) хотя и работают немного по разному
и раз они делают то что от них ожидается то и «правильными» будут они оба )
Проблемы пробелов в скрипте bash
Пытаюсь написать скрипт типа:
Без кавычек с «\ » тоже самое. Как правильно-то тогда?
Пробелы в имени всё равно экранировать.
Какую функцию призвана выполнять гора скобок <, >?
Пробелы в имени всё равно экранировать.
Пробелы в имени всё равно экранировать.
Уже даже и не помню, тоже от какого-то простреливания ног защищает. Это же баш.
Какую функцию призвана выполнять гора скобок <, >?
чтобы отделять имя переменной от строки, которая должна подклеиваться к значению переменной при подстановке
чтобы отделять имя переменной от строки, которая должна подклеиваться к значению переменной при подстановке
Оберег :3
Вне контекста типа «$arg1_$arg2_$arg3» (где он необходим) он ни от чего не защищает.
Какую функцию призвана выполнять гора скобок <, >?
Вне контекста типа «$arg1_$arg2_$arg3» (где он необходим) он ни от чего не защищает.
Хаотично раскиданные вокруг грабли имеют свойство бить по башке там где ты меньше всего ожидаешь, поэтому лучше убрать их все заранее.
Хаотично раскиданные вокруг грабли имеют свойство бить по башке
Уже даже и не помню, тоже от какого-то простреливания ног защищает.
Грабли возникают вот от второго.
Зачем держать в голове всякий мусор, появившийся в результате жизнедеятельности костылявших шелл наркоманов, если можно сразу писать надёжно-молодёжно™?
если можно сразу писать надёжно-молодёжно
Объясняю. Если убрать все <>, то в вашем скрипте можно смело менять bash на sh, при этом эффект будет тем же самым и даже работать быстрее будет.
Если убрать все <>, то в вашем скрипте можно смело менять bash на sh
Если бы бабушка была бы дедушкой. У ТСа в тегах этого треда и в первой строчке приведённого им скрипта указан bash, значит ему нужен именно он.
Откуда ты знаешь задачу ТСа, экстрасенс что ли? Может у него в стартовом посте кусок тестового скрипта, который он куда-нибудь пытается присобачить, а ты ему советуешь sh вместо баша впендюрить.
Вы лично выкрутитесь от того факта, что bash вы толком не знаете, а советы даёте
Всего знать нельзя и с этим фактом спорить глупо. Однако в данном случае я знаю достаточно.
Какие проблемы с пробелами?
Откуда ты знаешь задачу ТСа, экстрасенс что ли?
У вас? Так я цитировал ваш текст, который вы так и не скоректировали новым ответом по модно-молодёжной моде гордиться своим незнанием.
Нет. Задача ТСа — написать скрипт на баше, в котором в т.ч. должны экранироваться пробелы.
У вас? Так я цитировал ваш текст, который вы так и не скоректировали новым ответом по модно-молодёжной моде гордиться своим незнанием.
Эта личная переписка уже достала.
Чего там парсить? Речь шла о нахождении грабель там где их может найти только незнающий bash.
можно смело менять bash на sh
Но не нужно. И совершенно не надо знать о существовании башизмов (точнее, об информации, что где-то чего-то нет). Зачем забивать себе голову абсолютно ненужной информацией?
Зачем забивать себе голову абсолютно ненужной информацией?
Постараюсь ответить литературно, ибо как выше упоминал — моду гордиться незнанием не приемлю.
Это профессионализм, приходящий с опытом, автоматом. «О, новая версия имеет такую фичу. А я раньше сколько крови на это пролил. » Потом к ней привыкаешь и вдруг оказывается, что надо поадминить какой-нить чпукс, а руки сами вбивают понравившуюся фичу, а мозг судорожно пытается понять, чего же оно ругается. Потом это обрастает пылью и само забывается, как результат, первым делом устанавливается glibc/bash/gcc, а уж потом приступаешь к администрированию.
И нет нет, это не из серии раньше трава была зеленей и прочих сперва добейся. Это из серии, что знать всё не возможно, но выдавать своё незнание за добродетель совершенно идиотское веяние времени. А потом удивляются, откуда на ЛОРе хамство, личная переписка, откровенный мусор за мемами типа «не нужно».
Это было давно. Но не о том была речь. Был вопрос, зачем тут <>? Ответ выдал непонимание.
Ну да. Скобочки нисколько не выключают парсер имени по [A-Za-z0-9_], но включают его сложный вариант для Parameter Expansion. Так что как минимум два символа <> и простой парсер ускорит работу.
моду гордиться незнанием не приемлю
Быстро и решительно мне прочитал Фому Аквинского на средневековом диалекте каталонского.
Нет, это брюзжание некомпетентного непрофессионала.
Потом к ней привыкаешь и вдруг оказывается, что надо поадминить какой-нить чпукс
Потом это обрастает пылью и само забывается, как результат, первым делом устанавливается glibc/bash/gcc, а уж потом приступаешь к администрированию
Ничерта не понял в чём мораль. Это хорошо или плохо? И почему?
Это из серии, что знать всё не возможно, но выдавать своё незнание за добродетель совершенно идиотское веяние времени
Знать устаревшую технологию — это нормально. Когда-то она была не устаревшей.
Гордиться этим знанием — это снобизм. В этом нет повода для гордости.
Изучать устаревшую технологию, потому что она тебе понадобилась — это нормально, профессия археолога, даже айтишного, — тоже профессия.
Заставлять оглядываться на устаревшую технологию только потому, что ты её знаешь, а тот, кто делает, не знает, — это полный распад мозга.
Остальное можно было не писать. Нахамить в три короба с «гарантией» в режиме божественного откровения на весьма вежливый текст и радостно признаться что «ничерта не понял». ЧТД.
Ну да. Скобочки нисколько не выключают парсер имени по [A-Za-z0-9_], но включают его сложный вариант для Parameter Expansion. Так что как минимум два символа <> и простой парсер ускорит работу.
если можно сразу писать надёжно-молодёжно
Объясняю. Если убрать все <>, то в вашем скрипте можно смело менять bash на sh
А зачем вам менять ГНУ Баш такие древние шеллы, у которых даже с этим проблемы?
Заинтересовали, обязательно посмотрю. Логически это странно.
Если вы поменяете #!/bin/bash на sh на системе с /bin/sh-> /bin/bash у вас ничего не изменится, но вам спасибо скажут те, у которых вообще нет /bin/bash
чтобы отделять имя переменной от строки, которая должна подклеиваться к значению переменной при подстановке
в данном примере это не нужно
Заинтересовали, обязательно посмотрю. Логически это странно.
Разве parameter expansion парсером выполняется?
Разве parameter expansion парсером выполняется?
Это не проблемы, это фича)) Баш нужен для коротких однострочников в консоли и как бы сам намекает на необходимость смены инструмента.
Просто пробел в shell является основным управляющим синтаксическим элементом, что почему-то смущает программистов на пыхтонге, хотя у них как ни странно тоже.
проиграл, развел тут срач на тему совместимости и внутреннего устройства шеллов, хотя оп пост совсем про другое. всем насрать на скобочки и скорость баша, такие дела, дедуля
Если вы поменяете #!/bin/bash на sh на системе с /bin/sh-> /bin/bash у вас ничего не изменится, но вам спасибо скажут те, у которых вообще нет /bin/bash
Вот и обтекайте молча
Пакет util-linux пока не настроен
или пункта «Настроить» меню программы dselect: util-linux miscellaneous system utilities
dpkg: ошибка при обработке пакета systemd (—configure): проблемы зависимостей — оставляем триггеры не обработанными При обработке следующих пакетов произошли ошибки: util-linux systemd
Что касается java-8-oracle, установил этот пакет для использования xdebug (как в дальнейшем оказался не нужным). Так что при необходимости хотелось бы избавиться и от Java. Как исправить эти ошибки?
Не помогло. Смотрел в инете разные форумы и инструкции. Ни по одной не получилось, хотя пишут, что у кого то получается.
Так же при попытке переустановки пакета util-linux:
# sudo apt autoremove Чтение списков пакетов… Готово Построение дерева зависимостей Чтение информации о состоянии… Готово обновлено 0, установлено 0 новых пакетов, для удаления отмечено 0 пакетов, и 4 пакетов не обновлено. не установлено до конца или удалено 1 пакетов. После данной операции, объём занятого дискового пространства возрастёт на 0 B. Настраивается пакет util-linux (2.29.2-1+deb9u1) … update-alternatives: ошибка: не удалось выполнить stat для файла «/usr/lib/jvm/java-8-oracle/jre/bin/ControlPanel»: Слишком много уровней символьных ссылок dpkg: ошибка при обработке пакета util-linux (—configure): подпроцесс установлен сценарий post-installation возвратил код ошибки 2 При обработке следующих пакетов произошли ошибки: util-linux E: Sub-process /usr/bin/dpkg returned an error code (1)
Не удалось установить stat / etc / sudoers: нет такого файла или каталога
Эти ошибки происходят из-за того, что эти файлы принадлежат к специальной файловой системе procfs (установленной в /proc). Файловая система proc представляет информацию о процессах в иерархической файловой структуре, поэтому в тот момент, когда find пытается получить доступ к этим специальным файлам, они больше не присутствуют.
-xdev Не спускайте каталоги на другие файловые системы.
4 ответа
Ярлык:
dpkg-reconfigure: Если что-то не так с разрешением файла /etc/sudoers, с правами доступа root: dpkg-reconfigure sudo. что-то вроде pkexec dpkg-reconfigure sudo должно выполнять работу.
dpkg-reconfigure: Если dpkg-reconfigure не работает для вас, просто запустите pkexec visudo, файл sudoers будет открыт в редакторе, а затем просто сохраните и закройте файл, visudo установит для вас разрешение.
В конце концов, если вы изменили права доступа к каталогу sudoers.d, запустите:
Если файлы есть, и их разрешения так же, как и должно быть, но вы все равно получите это сообщение об ошибке, единственная возможность, которая приходит мне в голову, состоит в том, что вы нарушили другие разрешения, а sudo не имеет доступа к /etc/sudoers.
Мы закончили, однако, если вам нужна подробная инструкция для восстановления сломанных или удаленных sudoers файл с испорченными разрешениями, мы будем использовать другой способ исправить ситуацию.
Введение
Я испортил файл /etc/sudoers, чтобы получите аналогичную ошибку, как и вы.
Что я сделал, чтобы исправить эту проблему:
Прежде чем идти дальше, я должен упомянуть, что вы всегда можете использовать живой диск, чтобы сделать chroot в вашей системе, есть много инструкций о chroot, используя live диск, поэтому я не собираюсь снова давать все эти инструкции, вместо этого я предполагаю, что у нас нет живого диска, и мы будем использовать то, что у нас уже есть, чтобы исправить эту проблему. Если вы довольны cheroot, идите так, это тоже будет работать.
Получение доступа root
Теперь вы попадете в оболочку bash с корневым доступом. сначала перемонтируйте файловую систему с доступом для записи:
Затем откройте пользователя root и установите для него пароль:
Теперь, если ваш /etc/sudoers все еще существует /etc, переместите его в другое место:
Поскольку мы собираемся сообщить нашему менеджеру пакетов, что этот файл отсутствует, и он заменит его на правильную, поэтому он должен «Нет».
Вернуть sudoers назад
Мы просто должны переустановить пакет sudo, однако переустановка не возвращает этот файл, мы должны сказать dpkg для исправления отсутствующих файлов конфигурации, например:
Помните, что он попросит вас установить файл /etc/sudoers, вставив y, скажите «да».
Если это не сработало для вас, выполните следующие действия как root:
Теперь может быть несколько разных прав, запустите dpkg-reconfigure sudo, чтобы исправить это. если он не работает, запустите visudo как пользователь root, файл sudoers будет открыт в редакторе, а затем просто сохраните и закройте файл, visudo установит вам разрешение.
[d40 ] Если все пойдет правильно, ваш файл sudoers вернется, и вы сможете использовать sudo, как раньше.
в dpkg-перенастроить: если только что-то не так с разрешения файл [F8] и с корневой доступ: dpkg-reconfigure sudo. что-то вроде pkexec dpkg-reconfigure sudo должно сделать работу.
в dpkg-перенастроить: если на [F11] не работает для вас, то просто запустите pkexec visudo, меню [fайл от f13] будет открыт в редакторе, то просто сохраните и закройте файл, visudo будет исправить разрешение для вас.
в конце концов, если вы слишком изменилась sudoers.d директорию, запустите:
pkexec chmod 755 /etc/sudoers.d
если файлы есть, и их разрешения, как это должно быть но вы все еще получаете это сообщение об ошибке, единственная возможность, которая приходит мне в голову, это то, что вы нарушили другие права и sudo нет доступа [f17 в]. наиболее вероятным предполагаю разрешения /etc/.
pkexec chmod 755 /etc
мы, однако, если вы хотите подробную инструкцию для восстановления поврежденных или удаленных файлов [зг19] с перепутались разрешения следовать вместе, мы будем использовать другой способ, чтобы исправить положение.
Введение
я изменил мой файл [20 фунтов], чтобы получить подобную ошибку, как вы. Я получаю очень близко, так что я полностью удалить шахте, и это стало точно как у вас.
что я делал для устранения проблемы:
корень Мой аккаунт был заблокирован, и это не было пароля, так что это было невозможно для меня, чтобы делать то, что я хотел сделать. однако, если ваша корневая учетная запись активна и имеет пароль, переключитесь на пользователя root с [клавиши f21] и пропустить эту часть. если нет, следуйте инструкциям.
прежде чем идти дальше, я должен отметить, что Вы всегда можете использовать текущий диск сделать chroot в вашей системе, есть много Инструкции о окружения через живой диск, так что я не буду заморачиваться с дачей все эти инструкции снова, а я буду считать, что у нас нет видео диск, и мы собираемся использовать то, что у нас уже есть, чтобы исправить эту проблему. Если вы счастливы с cheroot идти по этому пути, что тоже работа.
[dиода d17]получение root доступа[!dиода d17] перезагрузить систему, когда жратва появится нажмите e, чтобы отредактировать его в конце строки, которая начинается с Linux, добавить init=/bin/bash нажмите Ctrl+х
теперь вы попадете в оболочку bash с правами суперпользователя. первая файловая система монтирования с доступом на запись:
после разблокировки root пользователя и установить пароль на него:
теперь, если ваш [f25 привод датчика] существует /etc, переместите его в другое место:
mv /etc/sudoers /etc/sudoers.broken
, потому что мы собираемся рассказать нашим менеджером пакетов, что этот файл отсутствует, и оно придет ему на смену к нам с правильным, поэтому он не должен быть там.
принесет пользователям использовать sudo? обратно
мы просто должны переустановить пакет sudo, однако переустановка не принесешь его назад, мы должны сказать [f30 с], чтобы исправить слишком недостающие файлы конфигурации, вроде этого:
помните, что он просит Вас об установке файл /etc/sudoers, вставив [f32 из] сказать «да».
если это не работает для вас, выполните следующие действия как root:
теперь там могут быть некоторые отличается от разрешения, выполнять dpkg-reconfigure sudo, чтобы исправить это. если это не работает, запустите visudo в качестве корневого пользователя, меню [fайл ф35] будет открыт в редакторе, то просто сохраните и закройте файл, [f36 в] будет исправить разрешение для вас.
[и D40]если все идет правильно, ваша файлами sudoers вернется и вы сможете использовать sudo, как вы были раньше.[!и D40]