Gregory P. Smith <g...@krypto.org> added the comment:
That bash produces a nicer error message is because bash happens to implement its own special logic to try and figure out why an exec failed with an error other than ENOEXEC. The OS kernel & libc do not give it that information, there is no such errno. Bash inspects the executable itself for a #! in some error paths, extracts an interpreter from that and constructs an error message involving it. (bash's execute_cmd.c and HAVE_HASH_BANG_EXEC logic) I agree with Eric. I don't think we should do anything here. This isn't posix_spawn, subprocess, or os.exec* specific. It's just how posix-y OSes that have the concept of a #! line interpreter for executable files work. The errno that comes back from an exec failure is not super informative. If someone disagrees, the way to move forward on this is to implement equivalent logic in a central place and have it called from all of the relevant places within the posixmodule (os) and the _posixsubprocess module. With tests of all possible errno cases and code paths for each. And make a PR out of that. If you're going to take that on; do _not_ look at the bash source code. That's GPL, we cannot copy it. Just go by this description. To me, this seems over complicated to get right and maintain. I'd rather not do this within Python. But if someone is going to make a PR for it, I'll at least look at it to see if it seems like something we could accept maintenance of. I cannot guarantee we'd accept it. ---------- resolution: -> not a bug stage: -> needs patch status: open -> closed type: behavior -> enhancement _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue43113> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
