uscr 08.07.2011 22:02
Скрипты — Скрипт без названия, который никому не нужен.
Здравствуйте!Прошу не обсуждать стиль ведения разработки сайта, о котором пойдет речь - в данном случае всё довольно плохо.
Отнеситесь с юмором.
Начну, как обычно, с предыстории:
есть у нас некоторый проект. Речь пойдёт о веб-сайте этого проекта. В каталоге, в котором лежит этот сайт, много программистов правят различные скрипты (php, perl), дизайнеры заливают новые картиночки. Многие части этого веб-сайта перетащены из других проектов. Итог - сумасшедшая помойка прав на файлы и владельцев файлов. Причём приводить это в порядок - задача не такая уж и тривиальная (хотя, на самом деле, всем просто лень). Многие скрипты, например, работают из-под юзера foo группы bar, а логи пишут в файл, хозяин которого egg из группы spam, а в этот лог пишет ещё и скрипт от имени monroe из группы spam. На самом деле, я привёл плохой пример. Но суть, я думаю, ясна. Неожиданно возникла идея этот проект перевести в git. Проблема в том, что при разворачивании сайта из git'а все файлы станут принадлежать юзеру, из-под которого развёрнут репозиторий. Таким образом, встала необходимость "забекапить" права на файлы. В связи с этим и был написан скрипт.
Как работает?
Скрипт получает вывод команды ls -laR в файл в /tmp, который затем удалит за собой.
Затем он построчно читает полученный файл и парсит каждую строку. Из строки он получает имя файла, права на файл, владельца и группу файла. Кроме того, скрипт "знает" в каком каталоге лежат файлы, с которыми он сейчас работает, так что проблем не будет. На выходе скрипт выплёвывает готовый shell скрипт с перечнем команд chmod и chown. Поэтому, рекомендую передавать скрипту абсолютный путь к каталогу, права которого хотите "забекапить"-так будет проще потом пользоваться полученным скриптом.
Как запускать?
Вот так:
1 |
|
или так:
1 |
|
Опция RUS появилась от того, что в разных локалях разный вывод ls -la.
В буржуйской локали он выглядит так:
drwxr-xr-x 3 root root 4096 2011-05-05 03:56 backup_20110503
а в отечественной так:
-rw-r--r-- 1 nazarovd users 2457260 Апр 26 23:00 backup_20110503
Два лишних пробела ломают всю стройную систему.
Если у вас начнутся глюки - подберите значение под себя. Для этого нужно делать в консоли так:
echo `ls -la somefile`|cut -d ' ' -f9
вместо цифры "9" подставляйте свою, пока не получите имя файла. Затем полученную цифру подставьте в скрипт в выражение let LS_DATE_SPACES=
Скрипт написан под bash. Насколько я знаю, в других оболочках могут быть проблемы с нарезанием строк.
Собственно, сам скрипт:
Результат
Запускаю:
1 |
|
Получаю:
Ну а где его можно применить, кроме как в подобной говноразработке?
Нужно искоренять подобный подход, а не писать скрипты.
Нужно искоренять подобный подход, а не писать скрипты.
Чтобы не бороться с локалями и LC_DATE_SPACES, можно или указать свою переменную среды LC_DATE в скрипте, или указать ls параметр --time-style=STYLE, например.
А зачем touch $TMP_FILE_NAME в строке 64? Stdout redirection в 65 сделает файл самостоятельно.
Вместо калькулятора достаточно сделать stat $filename и прочитать цифровой код в строке Access. Там же и uid/gid есть.
В целом получать список файлов при помощи ls очень странно. Обычно делают find . -print | xargs блабла.
В общем, идея бэкапа прав интересная, но скрипт можно улучшить в сто раз.
А зачем touch $TMP_FILE_NAME в строке 64? Stdout redirection в 65 сделает файл самостоятельно.
Вместо калькулятора достаточно сделать stat $filename и прочитать цифровой код в строке Access. Там же и uid/gid есть.
В целом получать список файлов при помощи ls очень странно. Обычно делают find . -print | xargs блабла.
В общем, идея бэкапа прав интересная, но скрипт можно улучшить в сто раз.
Тэг записи рулит :)
А что, в самом примере скрипт сломался? Почему home-ome вот это:
/home/nazarovd/ome/nazarovd/ ?
А что, в самом примере скрипт сломался? Почему home-ome вот это:
/home/nazarovd/ome/nazarovd/ ?
ЗЗЫ. Git умеет сохранять права на файлы, кстати. Команды git-cache-meta --store и git-cache-meta --apply.
Владельца не умеет же всё равно.
Да и пятница же! Не работу же работать было :)
Да и пятница же! Не работу же работать было :)
Поправил, но надеюсь, этого никто не увидит.
echo $line|sed 's/://g'|sed 's/\/$//g'|sed 's/\/\//\//g'
Буду рад увидеть продвинутую версию. Это написано за 10 минут + 5 минут на исправление ошибок.
Вот, например.
mealsforall, замечу еще что:
а) вы забыли сменить тек. директорию на WORK_DIR;
б) вызывать стоит именно find $PWD или find $(pwd), как в моем варианте, поскольку иначе пути в генерируемом получаться относительными.
а) вы забыли сменить тек. директорию на WORK_DIR;
б) вызывать стоит именно find $PWD или find $(pwd), как в моем варианте, поскольку иначе пути в генерируемом получаться относительными.
По поводу относительных/абсолютных путей спорный вопрос. Может оказаться, что относительные пути в данном случае предпочтительнее, т.к. сохраняются права и владельцы для файлов в гитовской репе. Может статься, что репа может быть склонирована и зачекаутена в совершенно другой каталог или на другой хост (например не в /home/production, а в /home/test, или вообще в склонированную виртуалку) и надо будет восстановить метаданные для файлов с совершенно другого корневого пути.
за подобный for и if elif в calculator надо бить ремнем по жопе. освойте наконец case ... esac, нафиг нужны $@ и что будет делать for без парметров
Мне кажется, что представленный скрипт является слишком целостным примером того, как не надо решать задачи при помощи шелла, поэтому критиковать его отдельные части бессмысленно.
не согласен. пофиг на ценность данного скрипта, но вот определенные техники, применяемые в скриптописании, и их правльное использование обсуждать всегда полезно
А чем это лучше, кроме усиления "правильности" кода? Это повлияет на быстродействие?
P.S.
Это серьёзный вопрос, а не из разряда "не учите меня жить".
P.S.
Это серьёзный вопрос, а не из разряда "не учите меня жить".
tar -zcvpf /backup/path.tgz /some/path
Делает то же самое что и ваш скрипт.
Делает то же самое что и ваш скрипт.
Скрипт-социопат? :)