[humor, unix] touch, rm
хахахаха
Месье мастер плоских шуток? :\
шелл - опасная штука
нет, это юникс вэй - тупая штука
и что произойдёт?
как я понимаю, touch -- отработает, и параметры -rf ен примет, т.к. -- скажет ему о том, что параметры кончились. Получается, что -rf перейдёт к следующей команде?
как я понимаю, touch -- отработает, и параметры -rf ен примет, т.к. -- скажет ему о том, что параметры кончились. Получается, что -rf перейдёт к следующей команде?
нет
%
"If you weren't my teacher, I'd think you just deleted all my files."
-- an anonymous UCB CS student, to an instructor who had typed "rm -i *" to
get rid of a file named "-f" on a Unix system.
%
Это пять!
Маладца 
Сам придумал?
Сам придумал?
нет, это юникс вэй - тупая штукаВиндовз вэй конечно намного лучше в этом смысле. Ты не получал файлы типа my_cool_sexy_foto.jpg.exe по ICQ? Когда последние 4 буквы не влазят в окошко, а иконка файла такая же, какая по дефолту ставится на jpeg.
во всех рекомендациях написано, что вот так писать программы не надо.
и лучше включить показ расширений и в explorer-е.
ps
рекомендаций, что надо делать, чтобы вот так не подставляться с командами в unix-е, я не встречал.
и лучше включить показ расширений и в explorer-е.
ps
рекомендаций, что надо делать, чтобы вот так не подставляться с командами в unix-е, я не встречал.
рекомендаций, что надо делать, чтобы вот так не подставляться с командами в unix-е, я не встречал.Не быть рутом?
типа удаление личных файлов - это нормально?
и подыхание админского скрипта при создание пользователем файла с именем "-rf"?
и подыхание админского скрипта при создание пользователем файла с именем "-rf"?
рекомендаций, что надо делать, чтобы вот так не подставляться с командами в unix-е, я не встречал.Как защититься от конкретно этой беды очевидно. Ответ уже был в этом треде. В рекомендациях я его встречал, тема обсуждённая неоднкратно.
Я же придерживаюсь другой рекомендации, которая применима не только к Unix, и не только к компьютерам - не пользоваться неявными аргументами при использовании опасных инструментов.
и подыхание админского скрипта при создание пользователем файла с именем "-rf"?Не могу представить здравый скрипт, который будет делать rm *.
имхо, правильнее все-таки обеспечивать структурированный доступ к разнородным параметрам.
а на такое, что скажет команда rm?
неизвестный параметр, или отработает?
rm "-rf xxx"
неизвестный параметр, или отработает?
ругнулась на неправильный набор параметров =)
> имхо, правильнее все-таки обеспечивать структурированный доступ к разнородным параметрам.
Он есть. Ответ уже был в этом треде. Просто не все им пользуются.
Он есть. Ответ уже был в этом треде. Просто не все им пользуются.
> а на такое, что скажет команда rm?
> rm "-rf xxx"
Скажет, что опции <пробел> программа не знает.
> rm "-rf xxx"
Скажет, что опции <пробел> программа не знает.
>>нет, это юникс вэй - тупая штука
А если поссать на телевизор, можно получить удар током. Вот такой вот real life way.
А если поссать на телевизор, можно получить удар током. Вот такой вот real life way.
да, согласен, rm - хорошо ведет себя в этом случае.
ps
но ведь все равно получается. что скрипт правильно не работает.
ps
но ведь все равно получается. что скрипт правильно не работает.
Ты не путай
Ссать на телевизор - это запускать такое . А здесь обсуждается случай, когда тебя может убить током от случайного прикосновения к ссущему на телефизор.
Ссать на телевизор - это запускать такое . А здесь обсуждается случай, когда тебя может убить током от случайного прикосновения к ссущему на телефизор.
Виндовз вэй конечно намного лучше в этом смысле. Ты не получал файлы типа my_cool_sexy_foto.jpg.exe по ICQ? Когда последние 4 буквы не влазят в окошко, а иконка файла такая же, какая по дефолту ставится на jpeg.А что ты здесь считаешь частью виндовс вэй - то, что имя не влезает в окошко, то, что иконка такая же или то, что оба типа файлов можно сразу "запустить"?
А что ты здесь считаешь частью виндовс вэй - то, что имя не влезает в окошко, то, что иконка такая же или то, что оба типа файлов можно сразу "запустить"?Да, то, что файлы представляют собой иконки, и файлы любых типов "запускаются". То, что иконки определённого вида вызывают определённую ассоциацию у пользователя, вот только не всегда эта ассоциация оказывается верной.
Нет. Тут обсуждается, что делая уборку на столе путём смахивания всего без разбора в мусорное ведро, можно потерять и что-то ценное.
Ты не путай
Ссать на телевизор - это запускать такое . А здесь обсуждается случай, когда тебя может убить током от случайного прикосновения к ссущему на телефизор.
Ладно, давай сравнивать с точки зрения юзера, и будем сравнивать только одинаковые действия.
В файловом менеджере, предоставляемом windows, никакое имя файла не может изменить поведение операции удаления группы файлов. В bash+coreutils показано, что это не так.
Теперь скажи, что нужно сравнивать в твоем случае получения файла по icq.
В файловом менеджере, предоставляемом windows, никакое имя файла не может изменить поведение операции удаления группы файлов. В bash+coreutils показано, что это не так.
Теперь скажи, что нужно сравнивать в твоем случае получения файла по icq.
Т.е. предлагается алгоритм удаления вещей со стола:
удалить вещь 1
удалить вещь 2
..
удалить вещь N
?
удалить вещь 1
удалить вещь 2
..
удалить вещь N
?
Потому что надо выполнять rm так -
У команды del, кстати, насколько я помню - возможностей гораздо меньше, чем у rm, так что нечего жаловаться.
rm -options -- filenames
У команды del, кстати, насколько я помню - возможностей гораздо меньше, чем у rm, так что нечего жаловаться.
del -- это не виндоус-вей.
это ностальгия виндовского юзера по юниксовому шеллу.
это ностальгия виндовского юзера по юниксовому шеллу.
Хм, а я дел использовал задолго до первой встречи с никсами.
ностальгию по юниксам люди всасывают с молоком матери
Да, то, что юниксоиды всасывают - это факт 
В файловом менеджере, предоставляемом windows, никакое имя файла не может изменить поведение операции удаления группы файлов. В bash+coreutils показано, что это не так.Не правда... Если выделить все иконки на десктопе и среди них будут: Мой компьютер, Сетевое окружение и Корзина, а потом нажать DEL, то ничего не произойдет.
Если выделить все иконки на десктопе и среди них будут: Мой компьютер, Сетевое окружение и Корзина, а потом нажать DEL, то ничего не произойдетЭто, наверное, в 3.1 такое было.
Ну, типа. Нет!
> Если выделить все иконки на десктопе и среди них будут: Мой компьютер, Сетевое окружение и Корзина, а потом нажать DEL, то ничего не произойдет.
Обрати внимание на то, что и в списке доступных команд - команды delete не будет.
Обрати внимание на то, что и в списке доступных команд - команды delete не будет.
у меня они прекрасно удаляются
с соответствующим запросом на подтверждение
с соответствующим запросом на подтверждение
корзина не удаляется - по крайней мере, при настройках по умолчанию
хм, а я не нашел как корзину на рабочий стол вывести
> Обрати внимание на то, что и в списке доступных команд -
> команды delete не будет.
Кнопки на клавиатуре не научились прятать.
А то прикольные были бы сообщения в Network:
> команды delete не будет.
Кнопки на клавиатуре не научились прятать.
А то прикольные были бы сообщения в Network:
Хочу настроить VPN, а с клавиатуры пропали почти все кнопки, что делать, нельзя выбрать ни один пункт меню?
клавиатура от лебедева уже на подходе, так что все будет :/
В файловом менеджере, предоставляемом windows, никакое имя файла не может изменить поведение операции удаления группы файлов. В bash+coreutils показано, что это не так.В NTFS есть хардлинки или я ошибаюсь?
> Теперь скажи, что нужно сравнивать в твоем случае получения файла по icq.
Не понял вопрос.
Не понял вопрос.
Т.е. предлагается алгоритм удаления вещей со стола:Даже хуже:
удалить вещь 1
удалить вещь 2
..
удалить вещь N
посмотреть на вещь 1
удалить вещь 1
посмотреть на вещь 2
удалить вещь 2
а отсортировать, потом удалить нужное скопом?
есть, разумеется
Ну что я должен рассматривать в качестве противопоставления подходу мирабилиса?
Ну так вот это неоптимально, если задача звучит как "получить чистый стол". В explorere я могу легко получить чистый стол не смотря на то, что там лежит (меня отдельно спросят про ящики стола). А вот в баше (в случае злого умысла) я точно останусь и без вещей в ящиках и меня никто не предупредит.
А ты держи ящики не над поверхностью стола, а под ней, как у всех нормальных людей. Тогда мусор смахнёшь, а ящики не тронешь.
> есть, разумеется
На самом деле не разумеется, потому что в документации ОС про них ничего не сказано. Так вот с помощью хардлинков можно опровергнуть вот это утверждение:
На самом деле не разумеется, потому что в документации ОС про них ничего не сказано. Так вот с помощью хардлинков можно опровергнуть вот это утверждение:
:
В файловом менеджере, предоставляемом windows, никакое имя файла не может изменить поведение операции удаления группы файлов.
> Ну что я должен рассматривать в качестве противопоставления подходу мирабилиса?
Причём здесь мирабилис? Проблема запускаемых иконок не частная, а общая. Противопоставлять можешь почтовую программу mutt.
Причём здесь мирабилис? Проблема запускаемых иконок не частная, а общая. Противопоставлять можешь почтовую программу mutt.
Проблема запускаемых иконок не частная, а общая.Нет тут никакой проблемы.
Фокус в том, что вред от запускаемых иконок - явно преднамеренный, а от отсутствия вывода хоть какой-нибудь информации об интерпретируемых командах у rm, mv, rd и cp - нет.
>> Проблема запускаемых иконок не частная, а общая.
> Нет тут никакой проблемы.
Ок, буду знать. Проблемы нет.
> Нет тут никакой проблемы.
Ок, буду знать. Проблемы нет.
ну, ладно, надо будет поэкспериментировать
Во-первых, "при чем" здесь пишется раздельно 
Во-вторых, у мс есть все, чтобы избежать проблемы запускаемых иконок:
- Мой любимый файловый менеджер при наведении на файл показывает не только иконку, но и полное имя с расширением, каким бы длинным имя не было.
- Мой любимый почтовый клиент (ОЕ) при скачивании аттача показывает не только иконку, но и N последних символов имени, включая расширение.
Во-вторых, у мс есть все, чтобы избежать проблемы запускаемых иконок:
- Мой любимый файловый менеджер при наведении на файл показывает не только иконку, но и полное имя с расширением, каким бы длинным имя не было.
- Мой любимый почтовый клиент (ОЕ) при скачивании аттача показывает не только иконку, но и N последних символов имени, включая расширение.
> Мой любимый файловый менеджер при наведении на файл показывает
> не только иконку, но и полное имя с расширением,
> каким бы длинным имя не было.
Долго ты будешь искать нужное, если оно показывается только при наведении.
> Мой любимый почтовый клиент (ОЕ) при скачивании аттача показывает
> не только иконку, но и N последних символов имени, включая расширение.
В то время как главное в данном случае - это content type.
> не только иконку, но и полное имя с расширением,
> каким бы длинным имя не было.
Долго ты будешь искать нужное, если оно показывается только при наведении.
> Мой любимый почтовый клиент (ОЕ) при скачивании аттача показывает
> не только иконку, но и N последних символов имени, включая расширение.
В то время как главное в данном случае - это content type.
> В то время как главное в данном случае - это content type.
почему именно content-type?
ps
content-type, вообще, только браузер умеет обрабатывать.
почему именно content-type?
ps
content-type, вообще, только браузер умеет обрабатывать.
>Долго ты будешь искать нужное, если оно показывается только при наведении.
Нужное я могу опознать по первым N буквам имени (иконке, времени, и.т.д)
>В то время как главное в данном случае - это content type.
Нет. Главное (в нашем споре) - что произойдет при нажатии open. А тут все зависит только от расширения.
Нужное я могу опознать по первым N буквам имени (иконке, времени, и.т.д)
>В то время как главное в данном случае - это content type.
Нет. Главное (в нашем споре) - что произойдет при нажатии open. А тут все зависит только от расширения.
> Нужное я могу опознать по первым N буквам имени (иконке, времени, и.т.д)
Если так, то rm * тоже не нужно использовать - удалишь (не)нужное по первым буквам.
> Главное (в нашем споре) - что произойдет при нажатии open.
> А тут все зависит только от расширения.
Вот и ещё проблема с мелкомягкими: игнорирование стандартов Internet.
В той системе, откуда пришёл файл, расширение может и не иметь такого значения, как думает OE.
Если так, то rm * тоже не нужно использовать - удалишь (не)нужное по первым буквам.
> Главное (в нашем споре) - что произойдет при нажатии open.
> А тут все зависит только от расширения.
Вот и ещё проблема с мелкомягкими: игнорирование стандартов Internet.
В той системе, откуда пришёл файл, расширение может и не иметь такого значения, как думает OE.
content-type, вообще, только браузер умеет обрабатывать.Веб-программисты не верят в жизнь вне 80 порта. Content-type есть не только в HTTP, но и в формате email сообщения.
Во-вторых, у мс есть все, чтобы избежать проблемы запускаемых иконокУ мс есть всё чтобы bash запустить. Никто не сомневался, что есть. Важно то, что пропагандируемая философия заключается в том, что any file is clickable.
- Мой любимыйРад за тебя, что ты идёшь поперек философии навязываемой производителем твоей ОС.
насколько я понимаю, мы имеем проблему от смещивания двух каналов передачи информации - доверяемого (мы сами (наша система) - показывает иконку для файла и не доверяемого (чужой файл - сам для себя показывает иконку).
так ведь это проблема как раз в unix way-е повсеместно идет: что при передаче параметров, через командную строку, что при работе в php - везде идет сознательное смещивание двух разных каналов передачи данных в один, что приводит к огребанию по ушам - по полной - в случае малейшей ошибки.
ведь с rm из начального поста все тоже самое - смешав в единое - доверяемую информацию - наши настройки, и не доверяемую - имена файлов - мы и получили капкан, который периодически и срабатывает.
так ведь это проблема как раз в unix way-е повсеместно идет: что при передаче параметров, через командную строку, что при работе в php - везде идет сознательное смещивание двух разных каналов передачи данных в один, что приводит к огребанию по ушам - по полной - в случае малейшей ошибки.
ведь с rm из начального поста все тоже самое - смешав в единое - доверяемую информацию - наши настройки, и не доверяемую - имена файлов - мы и получили капкан, который периодически и срабатывает.
>Если так, то rm * тоже не нужно использовать - удалишь (не)нужное по первым буквам.
В моем менеджере нет команды rm, вырази свою мысль поточнее.
>Вот и ещё проблема с мелкомягкими: игнорирование стандартов Internet.
Ну да, мс, соглашается со стандартами Internet, как с неизбежным злом и старается минимизировать их использование
В моем менеджере нет команды rm, вырази свою мысль поточнее.
>Вот и ещё проблема с мелкомягкими: игнорирование стандартов Internet.
Ну да, мс, соглашается со стандартами Internet, как с неизбежным злом и старается минимизировать их использование
> Вот и ещё проблема с мелкомягкими: игнорирование стандартов Internet.
> В той системе, откуда пришёл файл, расширение может и не иметь такого значения, как думает OE.
Есть стандарт - который описывает, как ОС должна вести себя с content-type-ом при работе вне браузера?
> В той системе, откуда пришёл файл, расширение может и не иметь такого значения, как думает OE.
Есть стандарт - который описывает, как ОС должна вести себя с content-type-ом при работе вне браузера?
Проблема не в том, что any file is clickable, а в наличии возможности определять тип файла еще до клика.
(ps : Мой любимый файлменеджер - explorer)
(ps : Мой любимый файлменеджер - explorer)
> так ведь это проблема как раз в unix way-е повсеместно идет: что при передаче параметров, через командную строку
Командную строку набирает человек. Он может вставить в неё явным и неявным образом tainted информацию. Но компьютер не защищён от этого.
> что при работе в php
А причём здесь unix?
> ведь с rm из начального поста все тоже самое - смешав в единое - доверяемую информацию - наши настройки, и
> не доверяемую - имена файлов - мы и получили капкан, который периодически и срабатывает.
См. выше.
Кстати только сейчас мне подумалось. А неужели cmd.exe иным образом обрататывает аргументы?
Командную строку набирает человек. Он может вставить в неё явным и неявным образом tainted информацию. Но компьютер не защищён от этого.
> что при работе в php
А причём здесь unix?
> ведь с rm из начального поста все тоже самое - смешав в единое - доверяемую информацию - наши настройки, и
> не доверяемую - имена файлов - мы и получили капкан, который периодически и срабатывает.
См. выше.
Кстати только сейчас мне подумалось. А неужели cmd.exe иным образом обрататывает аргументы?
> В моем менеджере нет команды rm, вырази свою мысль поточнее.
ты говоришь, что полное имя знать не обязательно
а я говорю, что rm * набирать не обязательно
отмазки примерно одинаковой силы
ты говоришь, что полное имя знать не обязательно
а я говорю, что rm * набирать не обязательно
отмазки примерно одинаковой силы
>А неужели cmd.exe иным образом обрататывает аргументы?
'/' вроде не может содержаться в имени файла
'/' вроде не может содержаться в имени файла
rm * набирать не обязательноИ не надо, за тебя это сделает кривой make.
Я говорил, что видеть полные имена необязательно. (А знать нужное - обязательно)
>а я говорю, что rm * набирать не обязательно
ну да, тут уже предлагали замену
rm file1
rm file2
...
>а я говорю, что rm * набирать не обязательно
ну да, тут уже предлагали замену
rm file1
rm file2
...
rm `ls|grep -n '-rf'`
> ну да, тут уже предлагали замену
реальная замена: rm -r trash/
реальная замена: rm -r trash/
> Командную строку набирает человек. Он может вставить в неё явным и неявным образом tainted информацию. Но компьютер не защищён от этого.
разве речь шла про это?
речь шла про то, какие подходы лучше использовать, чтобы избежать вот таких неявных ошибок.
> А причём здесь unix?
потому, что php - построен на тех же самых принципах, что и сам *nix.
> Кстати только сейчас мне подумалось. А неужели cmd.exe иным образом обрататывает аргументы?
cmd - вроде звездочку сам не обрабатывает.
и в качестве, основного префикса для опций используется "/", а тире - это уже мода с никсов пошла.
разве речь шла про это?
речь шла про то, какие подходы лучше использовать, чтобы избежать вот таких неявных ошибок.
> А причём здесь unix?
потому, что php - построен на тех же самых принципах, что и сам *nix.
> Кстати только сейчас мне подумалось. А неужели cmd.exe иным образом обрататывает аргументы?
cmd - вроде звездочку сам не обрабатывает.
и в качестве, основного префикса для опций используется "/", а тире - это уже мода с никсов пошла.
> И не надо, за тебя это сделает кривой make.
Какая версия make это делает сама?
Какая версия make это делает сама?
разве это замена?
rm -r trash/ удалит все подкаталоги
а rm * - нет
rm -r trash/ удалит все подкаталоги
а rm * - нет
> Есть стандарт - который описывает, как ОС должна вести себя с content-type-ом при работе вне браузера?
Есть. Не ОС, а MUA. Стандарт называется RFC1437, 1993 год. А вообще Content-Type был придуман RFC1049, 1988 год. Браузеры тогда были?
Есть. Не ОС, а MUA. Стандарт называется RFC1437, 1993 год. А вообще Content-Type был придуман RFC1049, 1988 год. Браузеры тогда были?
если это мусор - то тебе и нужно удалить подкаталоги
с помойкой, в которой кто-то злонамеренный понаставил засад типа файлов '-rf', именно так следует поступать
с помойкой, в которой кто-то злонамеренный понаставил засад типа файлов '-rf', именно так следует поступать
задача ставилась в общем виде, без всякого мусора
> И не надо, за тебя это сделает кривой make.
Сказал, как в воду пёрнул.
Сказал, как в воду пёрнул.
А как должен вести себя MUA при вызове внешних программ?
Неважно, можно допустить ошибку в Makefile (от этого никто не застрахован) - и потерять многое.
> > А неужели cmd.exe иным образом обрататывает аргументы?
> '/' вроде не может содержаться в имени файла
То, что какая-то программа начинает свои ключи с / - частный случай.
И действительно ли на виндовых fs запрещён / в имени файла?
> '/' вроде не может содержаться в имени файла
То, что какая-то программа начинает свои ключи с / - частный случай.
И действительно ли на виндовых fs запрещён / в имени файла?
> Стандарт называется RFC1437, 1993 год. А вообще Content-Type был придуман RFC1049, 1988 год
и где же там зафиксировано самое главное - как для произвольного файла определить его content-type?
и где же там зафиксировано самое главное - как для произвольного файла определить его content-type?
> потому, что php - построен на тех же самых принципах, что и сам *nix.
Пездец. С таким мощным заявлением даже лень спорить.
> cmd - вроде звездочку сам не обрабатывает.
Я не могу проверить. Можешь узнать точно?
Пездец. С таким мощным заявлением даже лень спорить.
> cmd - вроде звездочку сам не обрабатывает.
Я не могу проверить. Можешь узнать точно?
> правильнее все-таки обеспечивать структурированный доступ
> к разнородным параметрам
не пиши на *sh, пиши на языках, где такое есть
только вот для интерактивной работы такое почему-то не очень подходит, несмотря на красоту и очевидность концепции
много было попыток, теперь вот и MS взялись со своим monad, посмотрим что будет с ним
в частности, отцы unix придумали C без таких средств как основной язык, мне кажется, чтобы не быть похожими на lisp-машины, с которыми они обязаны были быть знакомыми
то есть если довести до логического завершения работу с параметрами, получится lisp
> к разнородным параметрам
не пиши на *sh, пиши на языках, где такое есть
только вот для интерактивной работы такое почему-то не очень подходит, несмотря на красоту и очевидность концепции
много было попыток, теперь вот и MS взялись со своим monad, посмотрим что будет с ним
в частности, отцы unix придумали C без таких средств как основной язык, мне кажется, чтобы не быть похожими на lisp-машины, с которыми они обязаны были быть знакомыми
то есть если довести до логического завершения работу с параметрами, получится lisp
cmd.exe НЕ обрабатывает wildcard-ы.
всё (кроме пайпов) приходит в argv
всё (кроме пайпов) приходит в argv
> Неважно, можно допустить ошибку в Makefile (от этого никто не застрахован) - и потерять многое.
В виндовз допустить ошибку нельзя? Или там от этого страхуют?
В виндовз допустить ошибку нельзя? Или там от этого страхуют?> задача ставилась в общем виде, без всякого мусора
кем ставилась? вообще-то, лучше избегать выполнения дурных задач, поставленных другими, а придумывать свои, правильные; а для тех, кто не согласен - что ж, есть windows
кем ставилась? вообще-то, лучше избегать выполнения дурных задач, поставленных другими, а придумывать свои, правильные; а для тех, кто не согласен - что ж, есть windows
> А как должен вести себя MUA при вызове внешних программ?
На это нет стандарта.
На это нет стандарта.
> только вот для интерактивной работы такое почему-то не очень подходит, не смотря на красоту и очевидность концепции
вчера не подходило?
сегодня не подходит?
никогда подходит не будет?
вчера не подходило?
сегодня не подходит?
никогда подходит не будет?
> и где же там зафиксировано самое главное - как для произвольного файла определить его content-type?
Не передергивай так дёшево. Вижу, ты хочешь утянуть разговор в своё любимое русло.
Ты хотел, что бы тебе рассказали про Content-Type вне браузера - тебе рассказали.
Не передергивай так дёшево. Вижу, ты хочешь утянуть разговор в своё любимое русло.
Ты хотел, что бы тебе рассказали про Content-Type вне браузера - тебе рассказали.
вчера многие пытались безуспешно
прежде чем сегодня долбиться в ту же стену, нужно понять, почему ничего не получилось у предшественников, и чем ты лучше их
прежде чем сегодня долбиться в ту же стену, нужно понять, почему ничего не получилось у предшественников, и чем ты лучше их
> как для произвольного файла определить его content-type?
в письме нет файлов, там вложения
в письме нет файлов, там вложения
В ответ на:
вообще-то, лучше избегать выполнения дурных задач, поставленных другими, а придумывать свои, правильные
это тоже nix-way ? =)
>На это нет стандарта.
ну тогда нет ничего странного в поведении OE.
ну тогда нет ничего странного в поведении OE.
> > вообще-то, лучше избегать выполнения дурных задач, поставленных другими, а придумывать свои, правильные
> это тоже nix-way ? =)
Да.
> это тоже nix-way ? =)
Да.
ведь с rm из начального поста все тоже самое - смешав в единое - доверяемую информацию - наши настройки, и не доверяемую - имена файлов - мы и получили капкан, который периодически и срабатывает.Прежде чем удалить что-нить, я делаю ls <шаблон для удаления>. И удаляю я обычно либо rm <имя файла или шаблон>, либо rm -Rf <дирректория>, где имя директории не содержит шаблонов.
Считаю, что в данном случае ls аналогично просмотру расширений в винде. В смысле, прежде чем удалить что-то (в винде - запустить что-то следует посмотреть, что именно ты удаляешь (запускаешь).
> ну тогда нет ничего странного в поведении OE
а никто и не говорил, что поведение странное
оно просто дурное
а никто и не говорил, что поведение странное
оно просто дурное
> > На это нет стандарта.
> ну тогда нет ничего странного в поведении OE.
Теперь ты дёшево передергиваешь. Никто не говорит, что OE нарушает стандарт. Говорят, что он поступает небезопасно.
> ну тогда нет ничего странного в поведении OE.
Теперь ты дёшево передергиваешь. Никто не говорит, что OE нарушает стандарт. Говорят, что он поступает небезопасно.
>Прежде чем удалить что-нить, я делаю ls <шаблон для удаления>.
угадай, что сделает ls * при наличии файла "-fr"
угадай, что сделает ls * при наличии файла "-fr"
> content-type, вообще, только браузер умеет обрабатывать
у браузера от Microsoft и с этим проблемы
у браузера от Microsoft и с этим проблемы
> Прежде чем удалить что-нить, я делаю ls <шаблон для удаления>. И удаляю я обычно либо rm <имя файла или шаблон>, либо rm -Rf <дирректория>, где имя директории не содержит шаблонов.
Все это правильно - если речь идет об интерактивной работе.
но это теряет смысл - если мы захотим rm записать в виде автоматического или полуавтоматического скрипта.
Все это правильно - если речь идет об интерактивной работе.
но это теряет смысл - если мы захотим rm записать в виде автоматического или полуавтоматического скрипта.
Я угадал.
И что в этом плохого? Я посмотрел на результат работы, понял, что фигня, набрал ls, и будучи наученный этим тредом, понял в чем фигня.
при этом я не потерял ни одного своего файлика.
И что в этом плохого? Я посмотрел на результат работы, понял, что фигня, набрал ls, и будучи наученный этим тредом, понял в чем фигня.
при этом я не потерял ни одного своего файлика.
>И что в этом плохого?
То, что ls * (и даже ls *f*) не покажет тебе файла "-fr"
То, что ls * (и даже ls *f*) не покажет тебе файла "-fr"
Ты часто в автоматических скриптах используешь rm *. Т.е. удалить только эту директорию, и ни одной поддиректории?
если это так важно, тогда пользуйся rm -- *.
если это так важно, тогда пользуйся rm -- *.
А ls без параметров кто-нить отменял?
Ну твой алгоритм звучал вроде так:
ls <template>
rm <template>
ls <template>
rm <template>
речь же идет не только о rm, а и о остальных командах тоже.
также речь идет не только - есть или нет вредоносное влияние, но и будет, или не будет скрипт работать так, как задумывалось.
зы
ты лично в скриптах всегда пишешь '--' перед шаблонами?
ты пишешь именно так?
также речь идет не только - есть или нет вредоносное влияние, но и будет, или не будет скрипт работать так, как задумывалось.
зы
ты лично в скриптах всегда пишешь '--' перед шаблонами?
ты пишешь именно так?
ls -- *.txt
copy -- * /target/
Обычно мой шаблон выглядит либо xxx*, либо *.jpg. -rf не под один из них не попадает.
Если шаблоном будет *, то я запускаю ls <шаблон> и вижу, что он мне выдает не только мою дирректорию, но еще и поддиректории. Офигеваю. Задумываюсь (эт очень полезное занятие). Понимаю, что не так (запускаю просто ls). Решаю проблему.
Если шаблоном будет *, то я запускаю ls <шаблон> и вижу, что он мне выдает не только мою дирректорию, но еще и поддиректории. Офигеваю. Задумываюсь (эт очень полезное занятие). Понимаю, что не так (запускаю просто ls). Решаю проблему.
в скриптах я удаляю либо rm <список файлов>, либо rm -Rf <имя дирректории>.
И никак иначе.
Может стоить рассматривать поставленный вопрос не как "доверяете ли вы команде rm", а как "доверяете ли вы содержимому директории".
если кто-то может создать файлик в директории, значит у него хватит прав и на большие злодействия. Значит вопрос стоит в правильной расстановке прав.
P.S.
изначальная тема мне очень понравилась. Думаю, что запомню надолго.
Но похоже, что все перерастает в hollywar. Жаль.
И никак иначе.
Может стоить рассматривать поставленный вопрос не как "доверяете ли вы команде rm", а как "доверяете ли вы содержимому директории".
если кто-то может создать файлик в директории, значит у него хватит прав и на большие злодействия. Значит вопрос стоит в правильной расстановке прав.
P.S.
изначальная тема мне очень понравилась. Думаю, что запомню надолго.
Но похоже, что все перерастает в hollywar. Жаль.
> если кто-то может создать файлик в директории, значит у него хватит прав и на большие злодействия. Значит вопрос стоит в правильной расстановке прав.
вывод очень неверный
файлы мы можем, например, создавать через ту же заливку через web-интерфейс.
если мы знаем, что на сервере удаление файлов делается :
автоматизированным скриптом - вот с такой строчкой rm *.jpg, то как минимум - мы можем залив файл '-.jpg', осуществить отказ в работе этого скрипта.
вывод очень неверный
файлы мы можем, например, создавать через ту же заливку через web-интерфейс.
если мы знаем, что на сервере удаление файлов делается :
автоматизированным скриптом - вот с такой строчкой rm *.jpg, то как минимум - мы можем залив файл '-.jpg', осуществить отказ в работе этого скрипта.
> в скриптах я удаляю либо rm <список файлов>,
т.е ты всегда удаляешь только фиксированный конечный набор файлов?
т.е ты всегда удаляешь только фиксированный конечный набор файлов?
Понятно.
Т.е. ты абсолютно и полностью доверяешь директории, куда имеют возможность записать кто угодно?
Моя мысль звучала так: "можно не делать лишнего гемора, если не доверяшь. Но если есть какая-то дырка в твоей система, то ей обязательно кто-нить воспользуется".
А ведь еще в старые добрые времена, мой папа мне говорил, что прежде чем запустить файл с дискеты - проверь его антивирусом. А потом он сильно ругался, когда оказывалось, что моя любимая игрушка наводила погром на жестком диске.
Т.е. ты абсолютно и полностью доверяешь директории, куда имеют возможность записать кто угодно?
Моя мысль звучала так: "можно не делать лишнего гемора, если не доверяшь. Но если есть какая-то дырка в твоей система, то ей обязательно кто-нить воспользуется".
А ведь еще в старые добрые времена, мой папа мне говорил, что прежде чем запустить файл с дискеты - проверь его антивирусом. А потом он сильно ругался, когда оказывалось, что моя любимая игрушка наводила погром на жестком диске.
да, я ей не доверяю, поэтому тех же прав на запуск не даю
но проблема в том, что когда я пишу:
copy * \dev\null
я совсем не ожидаю, что имена файлов имеют какое-то значение.
но проблема в том, что когда я пишу:
copy * \dev\null
я совсем не ожидаю, что имена файлов имеют какое-то значение.
я никогда не использую шаблон *.
он должен либо с чего-то начинаться, либо чем-то заканчиваться. И чаще всего, я знаю, какие именно файлы я буду удалять этим скриптом, и их набор очень даже конечен. Если это не так, тогда все это хранится в отдельной директории, которая чистится rm -Rf dir; mkdir dir.
он должен либо с чего-то начинаться, либо чем-то заканчиваться. И чаще всего, я знаю, какие именно файлы я буду удалять этим скриптом, и их набор очень даже конечен. Если это не так, тогда все это хранится в отдельной директории, которая чистится rm -Rf dir; mkdir dir.
вообще в скриптах, как минимум, стОит всегда указывать абсолютный путь до удаляемых файлов
> он должен либо с чего-то начинаться, либо чем-то заканчиваться
могу в третий раз повторить, что даже если звездочка на что-то заканчивается, то все равно нормально скрипт работать не будет.
copy *.txt \dev\null
все равно не скопирует файлы, если они начинаются на '-'
могу в третий раз повторить, что даже если звездочка на что-то заканчивается, то все равно нормально скрипт работать не будет.
copy *.txt \dev\null
все равно не скопирует файлы, если они начинаются на '-'
> файлы мы можем, например, создавать через ту же заливку
> через web-интерфейс
и разрешаем любые имена? уже неминуемо будут проблемы, что с ../../../, что с .cgi или там .php
> если мы знаем, что на сервере удаление файлов делается :
> автоматизированным скриптом - вот с такой строчкой rm *.jpg
так вот не надо так делать
надо и проверять имена, и писать скрипты безопасно, для чего есть более подходящие языки
> проблема в том, что когда я пишу:
> copy * \dev\null
это синтаксис нового шелла от MS?
короче, вам надо повторять всё более трёх раз,
напрашивается вывод, что Windows не очень хорошо влияет на головной мозг
> через web-интерфейс
и разрешаем любые имена? уже неминуемо будут проблемы, что с ../../../, что с .cgi или там .php
> если мы знаем, что на сервере удаление файлов делается :
> автоматизированным скриптом - вот с такой строчкой rm *.jpg
так вот не надо так делать
надо и проверять имена, и писать скрипты безопасно, для чего есть более подходящие языки
> проблема в том, что когда я пишу:
> copy * \dev\null
это синтаксис нового шелла от MS?
короче, вам надо повторять всё более трёх раз,
напрашивается вывод, что Windows не очень хорошо влияет на головной мозг
> вообще в скриптах, как минимум, стОит всегда указывать
> абсолютный путь до удаляемых файлов
не обязательно абсолютный, ./* тоже сойдёт
> абсолютный путь до удаляемых файлов
не обязательно абсолютный, ./* тоже сойдёт
> вообще в скриптах, как минимум, стОит всегда указывать абсолютный путь до удаляемых файлов
совсем, не уверен
во-первых - это противоречит той же атомарности
во-вторых - на уровне скрипта часто нет знания о полных путях к файлам, есть только знание о текущей дире.
совсем, не уверен
во-первых - это противоречит той же атомарности
во-вторых - на уровне скрипта часто нет знания о полных путях к файлам, есть только знание о текущей дире.
> надо и проверять имена, и писать скрипты безопасно, для чего есть более подходящие языки
кто и когда это будет делать?
пробежался поиском по данному форуму и по google-у.
постоянно видны советы запускать тот же перл вот таким способом: "pl -xx -zz *", причем в том числе и от более-менее адекватных людей.
кто и когда это будет делать?
пробежался поиском по данному форуму и по google-у.
постоянно видны советы запускать тот же перл вот таким способом: "pl -xx -zz *", причем в том числе и от более-менее адекватных людей.
> постоянно видны советы запускать тот же перл вот таким способом: "pl -xx -zz *",
что такое pl?
если эти советы даны для случая, когда названия файлов контролирует злоумышленник, то советчики неправы
что такое pl?
если эти советы даны для случая, когда названия файлов контролирует злоумышленник, то советчики неправы
я уверен, что всегда и делаю + смотри, что гадфазер ответил - тоже вариант
2. rm -mykeys $pwd*
во-первых - это противоречит той же атомарности1. как это противоречит атомарности?
во-вторых - на уровне скрипта часто нет знания о полных путях к файлам, есть только знание о текущей дире.
2. rm -mykeys $pwd*
> что такое pl?
вам виднее как у вас exe-шник perl-а называется.
> если эти советы даны для случая, когда названия файлов контролирует злоумышленник, то советчики неправы
причем здесь злоумышленник?
мы даже без всякого злоумышленника может получить очень и очень странный результат, если по каким-то причинам у нас в дире образовались файлы с именами, начинающиеся с подчеркивания.
вам виднее как у вас exe-шник perl-а называется.
> если эти советы даны для случая, когда названия файлов контролирует злоумышленник, то советчики неправы
причем здесь злоумышленник?
мы даже без всякого злоумышленника может получить очень и очень странный результат, если по каким-то причинам у нас в дире образовались файлы с именами, начинающиеся с подчеркивания.
> вам виднее как у вас exe-шник perl-а называется.
то есть ты не читал советы из гугла и форума, а сам решил, что они такие?
то есть ты не читал советы из гугла и форума, а сам решил, что они такие?
> если по каким-то причинам у нас в дире образовались файлы с именами,
> начинающиеся с подчеркивания
и какие результаты будут от имён файлов, начинающихся с подчёркивания?
> начинающиеся с подчеркивания
и какие результаты будут от имён файлов, начинающихся с подчёркивания?
И зачем ты меня заставляешь запоминать и обращать внимание на то, как называется исполняемый файл perl-а?
кто и когда это будет делать?Зависит от разработчика.
Если все пишет один человек, то где ему удобно.
Если несколько, тот кто пишет web-часть, будет считать, что это обязанность shell-ого программиста. Shell-овый программист - что это обязанность web-разработчика, не дать создать файл с кривым именем.
В итоге и получается дырка в системе.
На самом деле, народ уже давно наступал на эти грабли, когда на всяких форумах в тели сообщения ставили закрывающийся тэг, а потом писали что-нить свое. Так и появилось в php функция htmlspecialchars.
с тире
хм, я всегда считал, что более-менее адекватный чел
а тут вдруг стал к мелочам придираться...
ps
Придирись хоть к чему-нибудь, если не получается ответь по существу? (C)
а тут вдруг стал к мелочам придираться...
ps
Придирись хоть к чему-нибудь, если не получается ответь по существу? (C)
> Если несколько, тот кто пишет web-часть, будет считать, что это обязанность shell-ого программиста. Shell-овый программист - что это обязанность web-разработчика, не дать создать файл с кривым именем.
что-то я совсем не понял, почему файл с названием, которое начинается с тире - это кривой файл?
что-то я совсем не понял, почему файл с названием, которое начинается с тире - это кривой файл?
> с тире
а если небо упадёт на землю, то вообще пи*дец
никто не называет файлы, начиная имя с тире, кроме злоумышленников
> И зачем ты меня заставляешь запоминать и обращать внимание на то,
> как называется исполняемый файл perl-а?
потому что от этого зависит смысл совета
если не хочешь запоминать, мог бы скопировать, или буфер обмена в windows уже отменили?
а если небо упадёт на землю, то вообще пи*дец
никто не называет файлы, начиная имя с тире, кроме злоумышленников
> И зачем ты меня заставляешь запоминать и обращать внимание на то,
> как называется исполняемый файл perl-а?
потому что от этого зависит смысл совета
если не хочешь запоминать, мог бы скопировать, или буфер обмена в windows уже отменили?
> никто не называет файлы, начиная имя с тире, кроме злоумышленников
на чем основывается это предположение?
в стандарте написано?
> если не хочешь запоминать, мог бы скопировать, или буфер обмена в windows уже отменили?
адекватный чел - и так поймет, а ответ от неадекватного - все равно обычно смысла мало несет.
на чем основывается это предположение?
в стандарте написано?
> если не хочешь запоминать, мог бы скопировать, или буфер обмена в windows уже отменили?
адекватный чел - и так поймет, а ответ от неадекватного - все равно обычно смысла мало несет.
> на чем основывается это предположение?
на практике и здравом смысле
> адекватный чел - и так поймет
а прикинь, если есть команда pl и делает что-то другое?
на практике и здравом смысле
> адекватный чел - и так поймет
а прикинь, если есть команда pl и делает что-то другое?
> на практике и здравом смысле
вообщем, все это мне напоминает - креатив про грабли.
ps
вместо того, чтобы убирать грабли - разработчики упираются и предлагают поставить резиновую ручку потолще.
вообщем, все это мне напоминает - креатив про грабли.
ps
вместо того, чтобы убирать грабли - разработчики упираются и предлагают поставить резиновую ручку потолще.
> вместо того, чтобы убирать грабли
грабли убрали, когда добавили опцию --
грабли убрали, когда добавили опцию --
ее добавили ко всем командам, во все программы?
> ее добавили ко всем командам, во все программы?
дa, это обрабатывается стандартными функциями разбора параметров
дa, это обрабатывается стандартными функциями разбора параметров
тогда - да, более менее
хотя, конечно, решение плохо масштабируется - если, например, нужно несколько списков
хотя, конечно, решение плохо масштабируется - если, например, нужно несколько списков
> хотя, конечно, решение плохо масштабируется -
> если, например, нужно несколько списков
если добавить несколько списков, то тут же захочется деревьев - и получится лисп
вместо этого попытались разбить операции на базовые, работающие с одним списком параметров, а более сложные структуры можно передавать через файловую систему, например
> если, например, нужно несколько списков
если добавить несколько списков, то тут же захочется деревьев - и получится лисп
вместо этого попытались разбить операции на базовые, работающие с одним списком параметров, а более сложные структуры можно передавать через файловую систему, например
> но это теряет смысл - если мы захотим rm записать в виде автоматического или полуавтоматического скрипта.
Уже сколько раз в этом треде звучал ответ. По-моему ты в режиме write-only.
Еще раз: rm -- *.
Хотя, как я уже говорил ни в одном здравом скрипте такого не будет.
Уже сколько раз в этом треде звучал ответ. По-моему ты в режиме write-only.
Еще раз: rm -- *.
Хотя, как я уже говорил ни в одном здравом скрипте такого не будет.
> ты лично в скриптах всегда пишешь '--' перед шаблонами?
Да. И кроме этого в скриптах есть еще куча моментов, которые надо делать не так, как при интерактивной работе.
Да. И кроме этого в скриптах есть еще куча моментов, которые надо делать не так, как при интерактивной работе.
в скриптах есть еще куча моментов, которые надо делать не так, как при интерактивной работеСейчас нет времени искать точную ссылку, но это твои слова:
"Я, мол, запускаю в шеле 10 команд, потом лезу в историю и делаю из неё скрипт". Ты этим пытался доказать, что шел лучше, чем драг-н-дроп какой-нибудь. Так что, на самом деле не так всё шоколадно?
Да, моя фраза. А чем это противоречит вышеотквоченной фразе? Разве в программировании плохо сначала делать набросок, а потом вставлять в него многочисленные проверки и прочее и таким образом доводить до production состояния?в скриптах есть еще куча моментов, которые надо делать не так, как при интерактивной работеСейчас нет времени искать точную ссылку, но это твои слова:
"Я, мол, запускаю в шеле 10 команд, потом лезу в историю и делаю из неё скрипт". Ты этим пытался доказать, что шел лучше, чем драг-н-дроп какой-нибудь. Так что, на самом деле не так всё шоколадно?
Пока я пришел к выводу, что на sh писать скрипты вообще нельзя. Можно,скажем, на перле, где код все-таки отделен от данных. Например,
Как теперь эту задачу снять? Ничего из этого не работает:
unlink glob("*") не содержит подводных камней, или? Но у перла интерактивный интерпретатор если и есть, то не очень популярен. Поэтому связка "из истории в скрипт" лично мне кажется недостижимой. Я вообще чем больше bash узнаю, нем больше в нем разочаровываюсь. Простейший пример:./a | sudo ./b | ./c
Как теперь эту задачу снять? Ничего из этого не работает:
kill %1
sudo kill %1
sudo kill `jobs -p`
Пока я пришел к выводу, что на sh писать скрипты вообще нельзя.Смотря какие. Скрипты, которые на > 60% занимаются выполнением системных команд именно на sh и надо писать.
./a | sudo ./b | ./cА причём здесь sh? Независимо от языка ты не можешь убить чужой процесс.
Как теперь эту задачу снять?
> Например,
> code: unlink glob("*")
> не содержит подводных камней, или?
Оно не скажет тебе, какие из файлов не получилось удалить, и почему.
> code: unlink glob("*")
> не содержит подводных камней, или?
Оно не скажет тебе, какие из файлов не получилось удалить, и почему.
Оставить комментарий
rosali
Зацените:Прикол, да?