Re: [Patch] Support UTF-8 scripts

["D. Hazelton" <dhazelton@enter.net>]

On Saturday 17 September 2005 06:28, "Martin v. Löwis" wrote:
> D. Hazelton wrote:
> > This is a bogus argument. You're comparing the way a _binary_
> > executable works to the way an interpreted _text_ script works.
> > execve(), at least on my system, isn't capable of running a
> > script - if I want to do that from a program I have to tell
> > execve() that it's running /bin/sh and the script file is in the
> > parameter list.
>
> This being the linux-kernel list, I assume your system is Linux,
> no? Well, on Linux, execve *does* support script files. This is the
> whole point of my patch - I would not propose a kernel patch to
> improve this support if it weren't there in the first place.

This is news to me. The last time I handed execve() a script as a 
paramter I had errors returned from execve() -- I must admit that 
this was not on my current system and I had assumed that the behavior 
would be consistent.

> > While I appreciate that the kernel is capable of performing
> > complex actions when execve runs into a file that is not an a.out
> > or elf binary I have yet to see a "binfmt script" option in the
> > kernel config files ever.
>
> It's not a config option because it is always enabled. See
> fs/binfmt_script.c for details. It wasn't integrated into the
> binfmt system until I made it so some ten years ago, though.

I haven't gotten into that section of the code yet. I've been slowly 
working my way through the code from the drivers that seem to cause 
strange behavior on my system and then up the tree from there.

> > On the other hand, there is the "binfmt_misc" option, which does
> > the work that you seem to be looking for and can, AFAIK, be set
> > to handle both ASCII and UTF-8 scripts. Why add the complexity to
> > the kernel when it's not needed?
>
> One shouldn't add complexity if its not needed. However, this patch
> does not add complexity. It is fairly trivial.

You are correct. It is fairly trivial. However my point still is valid 
that the Kernel has the whole binfmt_misc system -- I will admit that 
I have recently been shown numbers that show a noticeable difference 
in the speed of a binary executed using the binfmt_misc system and 
the binfmt_script system, but the fact remains that offering handling 
for UTF8 and ASCII scripts directly in the kernel will likely lead to 
at least one more patch in which the the full Unicode standard is 
implemented.

That, and my point remains that the kernel should know absolutely 
nothing about how to execute a text file - the kernel should return 
an error to the extent of "I don't know what to do with this file" to 
the shell that tries to execute it, and the shell can then check for 
the sh_bang. I do admit that this change would break a lot of 
existing code, so I'll leave the argument to the experts.


> Regards,
> Martin

DRH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/