I haven't looked at the source to see what would be involved, but my uneducated guess would be that changing the shebang handler to ignore \r wouldn't be very complicated or risky.

We all know that the proper line ending on a unix system is \n , but exploding because someone uploaded a file with a \r at the end of the shebang line isn't really the best approach in my opinion.

Well thats the problem we are only guessing here. But the fact is if you would change the behaviour how a line ending is handled you are changing a critical piece of the system, one that interacts with a hell of a lot of other programs. You can never now or assure that every other program still works correctly after the change. You can guess and you can try to foretell what effects the change will have but the shere amount of scripts that get invoked via the shebang every day will most definitely assure that you cannot guarantee it. And as far as i am concerned i would rather not have it added to the standard code base.

--
"WHAT CAN THE HARVEST HOPE FOR IF NOT THE CARE OF THE REAPER MAN"
-- Terry Pratchett, "Reaper Man"

I suggested (and outlined) a patch for the kernel above. There might be a more clever way of doing it with a loadable kernel module to avoid rebuilding your kernel, but that would probably be quite a bit more work (but allow you to use your vendor kernel).

Yes, there's no good excuse for the kernel failing to ignore what is clearly whitespace. Someone please fix Linux already. This bug has existed for way too long.

( And how come it seems that there aren't any Linux users that know that she-bang lines are handled by the kernel? I think that change even predates Linux so there never was a Linux where the shell had to do the #!-handling. How many decades does it take for people to catch on? :)

- tye        

Interestingly, the kernel code in question (C, not perl I'm afraid :-) already does this:

    while (cp > bprm->buf) {
        cp--;
        if ((*cp == ' ') || (*cp == '\t'))
            *cp = '\0';
        else
            break;
    }
[download]

i.e. it finished the executable name at the first space or tab. I guess a better patch would be to change that if test to also null out '\r' (hmm...and probably form-feed and others whilst we're at it).

I wonder how loudly people would scream if this were proposed as a kosher kernel patch. It breaks backwards compatability quite badly, but perhaps only for people who deserve it...

When I first started with openbsd and freebsd 6 years ago I assumed the shell was responsible for the shebang, and never revisited the topic to challenge that assumption. It was never quite important enough for me to research it.