|
| 1.4, Аноним (-), 00:15, 15/07/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Прикольный патч. Не осилили исправить и просто выпилили поддержку формата.
| | |
| |
| 2.6, Аноним (-), 00:31, 15/07/2017 [^] [^^] [^^^] [ответить]
| +/– |
А как исправить-то? Судя по ману, у tar'а нет ключа конца опций (--).
| | |
| |
| 3.8, Аноним (-), 00:41, 15/07/2017 [^] [^^] [^^^] [ответить]
| +5 +/– | |
> А как исправить-то? Судя по ману, у tar'а нет ключа конца опций (--).
Зато есть, например, опции -T и --null. Почему не скормить ему имя файла через пайп?
| | |
| |
| 4.27, Аноним (-), 10:02, 15/07/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
У кого есть? У GNU tar? У BSD tar? Или ещё у какой-то из множества реализаций?
| | |
|
|
| 2.26, llolik (ok), 09:51, 15/07/2017 [^] [^^] [^^^] [ответить]
| +7 +/– |
 Ну обычно hot-fix так и делают. Проще временно отключить фичу, если она некритична и фикс нужен серьёзный, и сделать нормальный патч, чем сразу кидаться и патчить, рискуя наделать других глюков.
| | |
|
| 1.5, Аноним (-), 00:27, 15/07/2017 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– | |
> для извлечения каждого изображения в Evince запускается команда "tar -xOf $archive $filename"
Oчередная победа святого юниксвея.
| | |
| |
| |
| 3.11, Ordu (ok), 05:34, 15/07/2017 [^] [^^] [^^^] [ответить] | +/– |  Почему же Уж сколько раз твердили миру, что все эти system 3 до добра не довод... большой текст свёрнут, показать | | |
| |
| 4.12, Аноним (-), 06:39, 15/07/2017 [^] [^^] [^^^] [ответить]
| +/– | |
> не позволяют пересмотреть ситуацию и придумать лучший
Так и нельзя придумать ничего лучше.
| | |
| |
| 5.13, Ordu (ok), 06:44, 15/07/2017 [^] [^^] [^^^] [ответить]
| –6 +/– |
Угу. Unix Way пора переименовать в Unix Dead End. Развиваться больше некуда. Разве что рендеринг шрифтов сделать искаропки.
| | |
| |
| 6.38, Аноним (-), 12:56, 15/07/2017 [^] [^^] [^^^] [ответить]
| –4 +/– |
Не знаю как на счёт дальнейшего развития, но за dead end (тупик) плюсанул.
| | |
|
|
| 4.14, Аноним (-), 07:13, 15/07/2017 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> что все эти system(3)
По умолчанию им никто и не пользуется, скажу тебе по секрету, это даже не в стандартах С. Используют ядерные fork(), posix_spawn(), clone(), но никак не system().
| | |
| |
| 5.16, Ordu (ok), 07:54, 15/07/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> что все эти system(3)
> По умолчанию им никто и не пользуется, скажу тебе по секрету, это
> даже не в стандартах С. Используют ядерные fork(), posix_spawn(), clone(), но
> никак не system().
Ну, во-первых, наверное, всё же не столько этот список функций важен в данном контексте, а таки execve? Ведь именно криво подготовленные аргументы для execve создают уязвимости?
А, во-вторых, какая разница, что именно они используют? Что бы это ни было, оно ничего не понимает в аргументах командной строки и позволяет программисту исподтишка совершать невероятные глупости.
| | |
| |
| 6.21, Аноним (-), 08:32, 15/07/2017 [^] [^^] [^^^] [ответить] | –1 +/– | А может ты почитаешь, перед тем как глупости молоть execve executes the pro... большой текст свёрнут, показать | | |
| |
| 7.41, Аноним (-), 13:22, 15/07/2017 [^] [^^] [^^^] [ответить]
| +/– | |
> Абсолютно разные вызовы, делают абсолютно разное.
Ну и зачем же _ты_ их сюда приплёл? В любом случае, так или иначе, запуск происходит через вызов execve. Хоть system() используй, хоть fork()+exec*(), хоть posix_spawn().
| | |
|
| 6.35, Аноним (-), 11:39, 15/07/2017 [^] [^^] [^^^] [ответить]
| +/– |
> А, во-вторых, какая разница, что именно они используют? Что бы это ни
> было, оно ничего не понимает в аргументах командной строки и позволяет
> программисту исподтишка совершать невероятные глупости.
Угу, только проблема не в этом, а в том, как tar по сугубо историческим причинам обрабатывает свои аргументы. Перепиливали-перепиливали его, да недоперепилили. Из последней версии POSIX его вместе с прочими допотопными архиваторами, кстати, вообще выкинули, заменив на pax.
| | |
|
| 5.20, Анонимный Алкоголик (??), 08:28, 15/07/2017 [^] [^^] [^^^] [ответить]
| +/– |
>> что все эти system(3)
> По умолчанию им никто и не пользуется, скажу тебе по секрету, это
> даже не в стандартах С. Используют ядерные fork(), posix_spawn(), clone(), но
> никак не system().
У win кстати метод в стиле system...
| | |
| |
| 6.22, Аноним (-), 08:33, 15/07/2017 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> У win кстати метод в стиле system...
Потому что NT следует POSIX, внезапно, да?
| | |
| 6.23, Аноним (-), 08:35, 15/07/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
system(), если что, нестандартная функция. Ну так, на будущее.
| | |
| |
| 7.32, Аноним (-), 11:26, 15/07/2017 [^] [^^] [^^^] [ответить]
| +2 +/– |
Функция стандартной библиотеки C, прописанная в стандарте ISO/IEC, нестандартна? Вот это новости!
| | |
|
|
| 5.34, Аноним (-), 11:35, 15/07/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> что все эти system(3)
> По умолчанию им никто и не пользуется, скажу тебе по секрету, это
> даже не в стандартах С.
Вот как раз system(3) — в стандарте C.
> Используют ядерные fork(), posix_spawn(), clone(), но
> никак не system().
А fork() и posix_spawn() есть только в POSIX. clone() же вообще нестандартная и непереносимая штука.
| | |
|
| 4.15, Аноним (-), 07:17, 15/07/2017 [^] [^^] [^^^] [ответить]
| –4 +/– | |
> тут ещё C гадит как язык: на нём, я боюсь, не получится действительно красивого API -- то что я выше написал можно через препроцессор раскрыть и получить результат, но там могут начаться проблемы с тем, как макрос или код им сгенерённый определят была ли какая-то опция упомянута или нет: в C ведь нет ни хаскельного Maybe, ни rust'ового Option. А если не на C писать -- дык не юниксвейно же: юниксвей признаёт только C'шный взгляд на API/ABI со всеми их ограничениями
Ты ещё скажи, что у asm сплошные ограничения. Ограничения только в твоей глупой голове и твоих питонах, кстати, тоже.
| | |
| |
| 5.17, Ordu (ok), 07:55, 15/07/2017 [^] [^^] [^^^] [ответить]
| +/– |
>> тут ещё C гадит как язык: на нём, я боюсь, не получится действительно красивого API -- то что я выше написал можно через препроцессор раскрыть и получить результат, но там могут начаться проблемы с тем, как макрос или код им сгенерённый определят была ли какая-то опция упомянута или нет: в C ведь нет ни хаскельного Maybe, ни rust'ового Option. А если не на C писать -- дык не юниксвейно же: юниксвей признаёт только C'шный взгляд на API/ABI со всеми их ограничениями
> Ты ещё скажи, что у asm сплошные ограничения. Ограничения только в твоей
> глупой голове и твоих питонах, кстати, тоже.
С асмом связываться без хорошего препроцессора можно только программируя микроконтроллеры. А если взять хороший препроцессор к асму, то получится что-нибудь в стиле rust.
| | |
| |
| 6.19, Аноним (-), 08:19, 15/07/2017 [^] [^^] [^^^] [ответить]
| –4 +/– | |
> что-нибудь в стиле rust.
Ржавчина ржавая с самого начала, гарбедж коллектор, уродливый синтаксис, и "momory safety" только за счёт того, что убрали указатели? Не смешите мои мокасины. Чудес не бывает, всё равно, если писать криво, будут уязвимости даже в Java. Пока что язык новый, поэтому сообщений об узявимостях нет, да и используют его 1.5 проекта. Как станет таким же популярным как С++, сразу куча уязвимостей, недоработок в архитектуре вылезет. А потом, года через два, объявят, что Rust устарел и мы пишем новый Безопасный(C)(TM) язык программирования!
В любом случае, уязвимости в SoC никто не отменял. Один IME чего стоит.
| | |
| |
| 7.44, Anonim (??), 13:55, 15/07/2017 [^] [^^] [^^^] [ответить]
| +4 +/– | |
> Ржавчина ржавая с самого начала, гарбедж коллектор, уродливый синтаксис, и "momory safety" только за счёт того, что убрали указатели?
Совсем упоролись эти жабоскриптчики.
В ржавом сборщик мусора ещё в самых ранних альфа версиях выпилили. А указатели никто не убирал.
| | |
|
|
| 5.50, Аноним (-), 19:07, 15/07/2017 [^] [^^] [^^^] [ответить]
| +2 +/– |
> Ты ещё скажи, что у asm сплошные ограничения. Ограничения только в твоей
> глупой голове и твоих питонах, кстати, тоже.
Ну, я скажу.
А ты, как эксперт опеннета по компиляторам и ассемблерам, расскажи незнающим, как ты на _практике_ будешь в асме колбэки на основе замыканий или генерики делать.
И почему во всех сохранившихся диалектах асма, которые не задумывались как бэкэнд, можно целую кучу высокоуровневых вещей найти, впрлоть до макросов?
| | |
|
| 4.39, freehck (ok), 13:05, 15/07/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > и пускай библиотека консультируется с базой данных команд и соображает как раскрыть макрос run_program
ordu, проблема в том, что базы terminfo создать вообще говоря возможно: ты выбираешь конечное число наиболее распространённых терминалов, обеспечиваешь к ним унифицированный интерфейс, а затем не спеша добавляешь менее распространённые.
В случае же с базой всех возможных команд, это уже задача принципиально другого уровня:
Во-первых, необходимо регистрировать каждую команду в системе при установке, кто должен это делать? Разработчик программы? Мейнтейнер?
Во-вторых, необходимо перед вызовом каждой программы проверять корректность её аргументов по базе, и не давать ей запуститься, если параметры не правильные. И это необходимо в рантайме, хотя бы потому, что существуют языки shell. База будет большой. Сильно увеличится время запуска.
В-третьих, даже если написать типизированный shell с выводом типов по хиндли-милнеру, он будет конечно безопаснее, но пользоваться им будет крайне неудобно. Почему? Да хотя бы потому что 100500 программ заточены под возврат ошибки не в виде ocaml-овских option или result, но через возврат int-а, и нам придётся все вызовы оборачивать во что-то эдакое.
В-четвёртых, что вы с этой вашей базой будете делать с программами, в которых аргументы представляют собой язык? В аргументах которых можно задавать другие команды? Ну тот же "bash -c <command>", тот же "find ... -exec <command>"? Это ж пипец, предусмотреть все случаи.
В-пятых, не все команды принимают аргументы, следуя рекомендациям posix. tar, unrar, например... Как эти программы в базу вносить?
Вы предлагаете создать базу программ, но это лишь способ перенести проверку с программы на какой-то внешний механизм. Спрашивается, зачем? При разработке Unix долго думали, как это сделать, и как видите, оставили это на усмотрение разработчиков. И это самый правильный путь, потому что программ великое множество, и список их постоянно пополняется, так что за всеми не уследить.
| | |
| |
| 5.43, Crazy Alex (ok), 13:27, 15/07/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Все эти проблемы возникают, если пытаться покрыть абсолютно все потребности всего софта. Если же ограничиться конкретным набором (описанным в POSIX или Singe Unix, например) - всё проще, и это покроет большой процент реального использования. Для остального - ругающиеся линтеры и соответствующие стандарты качества, и подобные баги будут вытеснены куда=то на обочину цивилизованного программирования.
Для find и подобных определить отдельный "выхываемый" аргумент - тоже можно.
Хотя as for me - оно того не стоит, если уж связываться с новым API и кучей работы - надо дальше идти, и вводить типизацию параметров и хотя бы внятную стандартную сериализацию в стандартном вводе/выводе, если не типизацию с рефлексией.
| | |
| 5.48, Ordu (ok), 18:14, 15/07/2017 [^] [^^] [^^^] [ответить] | –1 +/– | Для начала разработчик программы Со временем мейнтейнеры дистрибутивов начнут п... большой текст свёрнут, показать | | |
|
|
|
|
| 1.28, Нанобот (ok), 10:22, 15/07/2017 [ответить] [﹢﹢﹢] [ · · · ]
| –4 +/– |
 2017й год на дворе, а в линуксе при просмотре сайтов exec используют. И эти люди потом ещё катят бочку на Винду...
| | |
| |
| 2.61, Аноним (-), 23:45, 17/07/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
2017й год на дворе, а в винде обновление офисного пакета требует перезагрузки всей системы. И эти люди потом ещё катят бочку на Линукс...
| | |
|
| 1.30, Аноним (-), 11:02, 15/07/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
И что же мешает всю эту дрянь запускать под ограничивающим профилем AppArmor или SELinux?
| | |
| |
| 2.40, soarin (ok), 13:10, 15/07/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
 Очень просто AppArmor и SELinux направлены на серверное применение.
Отлаживать их работу с десктопным софтом никому особо не охота.
| | |
|
| 1.51, Аноним (-), 21:49, 15/07/2017 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
Гномоящеры как всегда лохонулись на пустом месте. Проблемы mplayer никого не учат, все кругом слепые? Тот же smplayer до сих пор парсит регулярками выхлоп работы mplayer позорище. Ладно хоть существует libmpv.
| | |
| |
| 2.53, Аноним (-), 02:53, 16/07/2017 [^] [^^] [^^^] [ответить]
| –2 +/– |
Возьми и научи их как правильно. Некому контрибьютить же, от того имеем что имеем.
| | |
| |
| |
| 4.60, Аноним (-), 19:08, 16/07/2017 [^] [^^] [^^^] [ответить]
| –1 +/– | |
Никто не запрещает форкать же.
Да и этих плееров/плееров-обёрток – хоть пруд пруди, но действительно качественных – не напасёшься.
| | |
|
|
|
| 1.54, Аноним (-), 04:42, 16/07/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Склепал proof of concept. Действительно работает. Достаточно взять валидный jpg, дать ему указанное в новости имя и запаковать в tar с именем, заканчивающимся на .cbr.
| | |
| 1.56, Аноним (-), 11:49, 16/07/2017 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
все программисты, использующие консольные утилиты вместо либ, если такие есть для языка, профнепригодны.
| | |
| |
| 2.57, Аноним (-), 15:12, 16/07/2017 [^] [^^] [^^^] [ответить]
| +3 +/– |
Все программисты, считающие, что нельзя в программах использовать консольные утилиты, вчерашние или сегодняшние виндуzятники. А в юниксах это такой же нормальный способ повторного использование кода, как и линковка с библиотеками, и все юниксовые IPC как раз под это заточены.
| | |
| |
| 3.58, Andrey Mitrofanov (?), 17:00, 16/07/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
#>>вместо либ, если такие есть для языка, профнепригодны.
> Все программисты, считающие, что нельзя в программах использовать консольные утилиты,
> вчерашние или сегодняшние виндуzятники. А в юниксах это такой же нормальный
> способ повторного использование кода, как и линковка с библиотеками, и все
> юниксовые IPC как раз под это заточены.
...точн, слыхал я тех погромистов - про ""удобство"" libsystemd0 и неосиляние /bin/bash. И про профнепригодность и "вон из профессии". Не буду погромистом!
| | |
|
|
|
