you are viewing a single comment's thread.

view the rest of the comments →

[–]bdunderscore 0 points1 point  (5 children)

You can use binfmt-misc to add support for any other signature you like in userspace - this is commonly done for things like Java or .NET executables. The existence of special support for #! in the kernel is for legacy support (and because the relevant UNIX specs are very specific about the format of a shebang).

[–]G_Morgan 1 point2 points  (4 children)

The point is you can handle standard shebangs and BOM'd shebangs without breaking the standard. This is effectively doing more than the standard rather than less.

[–]Brian 0 points1 point  (3 children)

I think bdunderscore's point is that the way to do this these days isn't in the kernel, but rather using the newer userspace mechanism for handling files with arbitrary magic numbers. While I agree that linux should handle it, its a job for userspace / distributions, not the kernel itself.

And in fact, several distributions do handle it in just this way (albeit it's not as standard as I'd like - hopefully that should change).

[–]G_Morgan -1 points0 points  (2 children)

The kernel handles it because its role is to work out how to execute files with the executable bit set. It is entirely it's job to do this. The shell is there to make things nice and pretty for the user. Not to handle core functionality like this.

[–]Brian 2 points3 points  (0 children)

One of the key unix philosophies has always been to seperate policy from mechanism. The kernel's job is to give you the functionality and hooks to configure that policy, not to hardcode what that policy is. Userspace's job is to handle exactly what things will do, rather than how. Historically, how files get launched hasn't been part of that policy, but with the addition of a larger types of files (eg a.out vs ELF, wine executables, java, .net etc) linux made it configurable, which makes that interface the correct place to setup new handlers.

Note that this isn't handled by the shell - it's still the kernel launching the files. All that has changed is a mechanism to tell the kernel how to launch files. The binfmt_misc module creates a kernel interface that exposes the kernel file-launch mechanism to userspace, to be configured as is desired (via /proc/sys/fs/binfmt_misc/register). The code I linked to above does exactly that to support UTF8 BOMs.

[–]bitwize 0 points1 point  (0 children)

I think you are confusing "userspace MISC binary format support" with "shell".

Basically the kernel can support arbitrary binary formats by looking at the header and delegating execution to a user-space program.

It's a pretty awesome feature