Bug 42605

Summary:	Нужно добавить диагностическое сообщение об отсутствии интерпретатора ELF
Product:	Sisyphus	Reporter:	jqt4
Component:	bash4	Assignee:	placeholder <placeholder>
Status:	NEW ---	QA Contact:	qa-sisyphus
Severity:	normal
Priority:	P5	CC:	glebfm, iv, ldv, legion, placeholder
Version:	unstable
Hardware:	all
OS:	Linux

Description jqt4 2022-04-26 16:45:00 MSK

Имеется проблема: https://bugzilla.altlinux.org/42268
Если в системе отсутствует нужный интерпретатор ELF, то bash выдаёт сообщение об ошибке, не позволяющее пользователю понять и устранить причину проблемы.

Для решения проблемы предложен патч:
https://src.fedoraproject.org/rpms/bash/blob/rawhide/f/bash-2.05a-interpreter.patch

Прошу добавить такую функциональность в bash.

Comment 1 Dmitry V. Levin 2022-04-27 13:04:40 MSK

Патч так себе, да и сама идея копаться в потрохах executable, execve которого завершился с ENOENT, чтобы додумывать за ядро, кажется мне неправильной.

Comment 2 Gleb F-Malinovskiy 2022-04-27 14:24:08 MSK

Но сообщение об ошибке могло бы быть другим.
Если файл на самом деле есть, ядро ответило ENOENT, а #! в начале файла нет, то можно смело говорить, что не нашёлся ELF interpreter, хотя и не указывать, какой именно.  (Опционально, проверить ещё, что в начале есть \x7fELF.)

Comment 3 Alexey Gladkov 2022-04-27 14:43:22 MSK

(Ответ для Dmitry V. Levin на комментарий #1)
> Патч так себе, да и сама идея копаться в потрохах executable, execve
> которого завершился с ENOENT, чтобы додумывать за ядро, кажется мне
> неправильной.

из execve(2):

ENOENT The file pathname or a script or ELF interpreter does not exist.

Почему нельзя просто проверять наличие файла если execve вернул ENOENT и не пытаться лезть внутрь ?

Но в целом, я согласен, что предлагается заставить bash додумывать за ядро. Если взять другой шелл все усилия обнулятся. Тогда уж патчить нужно вообще все шеллы в репозитории на предмет этой ошибки.

Comment 4 Dmitry V. Levin 2022-04-27 16:15:29 MSK

Executable может быть чем угодно, даже не обязательно ELF'ом, binfmt_misc никто не запрещал.
Максимум, на что я готов согласиться - это дополнительный вызов access(command, X_OK),
чтобы отличить "ENOENT главного executable" от "ENOENT что-то где-то не нашлось".