Потокобезопасность system(3) в glibc

patrick.jpg

ну так бери и переноси, кто тебя остановит? ABI ядра одно и то же, только слинкуй статически.

Мой — о /bin/sh, который даже в NixOS захардкожен из-за драного POSIX.

Ваш — о dynamic loader’е, с которым как раз никаких проблем нет.

Чел, у тебя ПМ патчит на лету шебанги и собирает эльфы с недефолтным интерпретёром, а ты ноешь, что сложно запатчить единственную библиотеку. Ты не мог найти более релевантного топика, чтобы просто поныть?

Носи виртуалки, ты же любитель всяких контейнеров и прочих тяжёлых решений там, где не надо.

Я любить применять инструменты там, где они надо. А не любитель пересобирать весь мир из-за того, что в glibc кто-то исправил запятую в комментах. Это кто тут завёл песню про тяжелые решения, лол.

ну так бери и переноси, кто тебя остановит?

Как минимум какой-нибудь «иллегал инструкшн»

сложно запатчить единственную библиотеку.

Если бы. Драный /bin/sh в каждом втором гнутом скрипте захардкожен.

Я любить применять инструменты там, где они надо. А не любитель пересобирать весь мир из-за того, что в glibc кто-то исправил запятую в комментах. Это кто тут завёл песню про тяжелые решения, лол.

Помэйнтэйнь binary ABI stability у чего-нибудь, потом рассказывай, какое решение тяжёлое =)

Сфига бы?

Драный /bin/sh в каждом втором гнутом скрипте захардкожен.

Дело было не в бобине, д^W

/bin/sh в каждом втором гнутом скрипте захардкожен.

что должно быть вместо него?

sh

Помэйнтэйнь binary ABI stability у чего-нибудь, потом рассказывай, какое решение тяжёлое =)

В огороде бузина, в Киеве ABI

x86 <—> arm

Ты не смог генту для arm найти или Android для x86?

ASUS Zenfone в помощь))

Intel Inside
     @
Idiot Outside

sh

и как ядро должно интерпретировать эту строку (binfmt)?

Драный /bin/sh в каждом втором гнутом скрипте захардкожен.

В шебанге?

Это не зоопарк, а инцест

В шебанге должен быть путь до конкретного /bin/sh; посеред скрипта должен быть просто sh

Не только, о чем и ною.

Не поспоришь

А зачем оно там?

Потому что «why not, it’s mandated by POSIX anyway», и вот мы вернулись к тому, с чего начали.

Не факт. А может там секурити.

Ага, а избирательность использования /bin/sh и sh вперемешку вызвана необходимостью запутывать потенциального противника.

Какое секьюрити в автотулзах и libtool, не смеши мои тапки. Чье-то job security? Так он, небось, в лучшем мире уже.

Цуко, в голосину.

Сделал мой день.

Да вообще неплохой тред, спасибо.

в автотулзах и libtool

а чтоб не дергали на не-posix!

Ну, и легко меняется штатными средствами ПМ. Или ты хочешь единые бинарники носить между системами без зависимостей как в какой-то винде? Тогда да, ты в пролёте, носить их без остального closure не выйдет.

Так и делаю регулярно - ношу бинарники между системами (компилю на одной, использую на другой, в том числе между разными линукс-дистрами, разными версиями glibc и разными разрядностями: скомпилил в 32-bit debian, запускаю в 64-bit centos, на freebsd соответственно между разными версиями и разрядностями системы).

А вот что пытаешься сделать ты - я так и не понял.

Я вас с wandrien записал. Когда/если доведу до ума — кастану и покажу.

А я вот в скриптах специально стараюсь писать с путями, чтобы какая-нить неожиданность из $PATH всё не сломала. $PATH, на мой взгляд - для интерактивного использования, чтобы не набирать с клавиатуры полные пути.

чтобы какая-нить неожиданность из $PATH всё не сломала

Помню, какой-то display manager добавлял текущую директорию PATH=.:$PATH.

Я вас с wandrien записал.

А-а-а-а! xD

Вспомнил знакомую, которая тоже меня «запесала». Пойду напишу ей =)

Создатели Plan9 смотрят на тебя с непониманием.

У меня есть на примете отличная программа для массового прописывания в скриптах и не только конкретных путей, подсказать, подсказать? XD

А я вот в скриптах специально стараюсь писать с путями, чтобы какая-нить неожиданность из $PATH всё не сломала. $PATH, на мой взгляд - для интерактивного использования, чтобы не набирать с клавиатуры полные пути.

Поганенько пишешь. Надо, чтобы оно само и так и эдак.

Пусть встают в очередь.

Создатели Plan9 смотрят на тебя с непониманием.

Они вообще офигевшими ходили. Весь мир не туда пошел.

У ней путь не стандартизирован!!11

Нужна призказка, типа как «смог продать лед эскимосу», только обратная, «не смогли продать гикам план».

2020

2013

Огонь.

Семь лет от Resolved до Applied. А в свежем Firefox закрыли баг, которому 16 лет. xD

Я не то, чтоб про интервал, я по «отставить портить компот, ваши скрипты с sed -E, не только восемь лет как перестали полагаться на недокументированные опции, они еще и уже год как портабельны!» угараю.

Так фишка не в этом, а в том, что нигде нет внятной картины, чо вообще произошло.

1. Все BSD-деривативы (+ Соляра, которая, возможно, из BSD дёрнула код ERE, а может и нет,я не проверял) поддерживают -E, но нигде не написано, мол, «опцию поддерживают все BSD». (Как например с libc-шными функциями есть конкретный пласт, который относится к BSD-семейству.)

2. GNU sed добавляет опцию в 2006-м в каком-то левом коммите, который по описанию вообще не относится к этому вопросу, и не документирует её семь лет!11 Один дурак не добавил в ман, другие решили, что так и надо?

3. Спустя эти 7 лет, в 2013-м, ВНЕЗАПНО они документируют её как стандартную, без отсылки к стандарту.

4. В 13-м, 16-м и 18-м годах выходят апдейты SUSv4. Этой опции в них нет!

5. В 2020-м, спустя еще семь лет!, тоже ВНЕЗАПНО просыпается какой-то чел и меняет статус issue в трекере.

Ну думаю, еще лет через 7 мы увидим результат на бумаге.

Зачем вообще нужны эти сраные комитеты? Я хз.

Ну и GNU, конечно, тоже хороши.

(А документация на feature_test_macros(7), мммм… просто песня. Читаешь и лезут шары на лоб.)

Спустя эти 7 лет, в 2013-м, ВНЕЗАПНО они документируют её как стандартную, без отсылки к стандарту.

Ссылаются на багтрекер https://www.austingroupbugs.net/view.php?id=528

2012-01-26 16:51 Don Cragun Status Under Review => Resolved

И 8 лет понадобилось для

2020-03-18 15:37 geoffclare Status Resolved => Applied

Допустим. Но была ли это проблема musl?

была ли это проблема musl

столько воды утекло, ты спрашиваешь…

в той статье, насколько я помню, брали одну и ту же версию сервера, клиента и датасет. и получались страшные вещи.

вряд ли я сейчас найду её, чтобы как-то поддержать эту беседу )

Ну, то что брали одну и ту же версию - очевидно. Я больше про то, что musl даже не обещает быть совместимым с glibc. И это, в общем-то, правильное решение. А MySQL вполне могла рассчитвать на то что под линуксом есть только glibc и на её поведение. Потому такое и получилось.

не будет драного /bin/sh или драного /usr/bin/env

А шебанги тоже nix будет патчить что ли?