Bug 42605

Summary: Нужно добавить диагностическое сообщение об отсутствии интерпретатора ELF
Product: Sisyphus Reporter: jqt4
Component: bash4Assignee: 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 что-то где-то не нашлось".