bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: binfmt_script and ^M


From: Jesse Pollard
Subject: Re: binfmt_script and ^M
Date: Tue, 6 Mar 2001 07:55:15 -0600 (CST)

Andreas Schwab <schwab@suse.de>:Andreas Schwab <schwab@suse.de>Andreas Schwab 
<schwab@suse.de>
> Paul Flinders <paul@dawa.demon.co.uk> writes:
> 
> |> Andreas Schwab wrote:
> |> 
> |> > This [isspace('\r') == 1] has no significance here.  The right thing to
> |> 
> |> > look at is $IFS, which does not contain \r by default.  The shell only 
> splits
> |> 
> |> > words by "IFS whitespace", and the kernel should be consistent with it:
> |> >
> |> > $ echo -e 'ls foo\r' | sh
> |> > ls: foo: No such file or directory
> |> 
> |> The problem with that argument is that #!<interpreter> can be applied
> |> to more than just shells which understand $IFS, so which environment
> |> variable does the kernel pick?
> 
> The kernel should use the same default value of IFS as the Bourne shell,
> ie. the same value you'll get with /bin/sh -c 'echo "$IFS"'.  This is
> independent of any settings in the environment.
> 
> |> It's a difficult one - logically white space should terminate the 
> interpreter
> 
> No, IFS-whitespace delimits arguments in the Bourne shell.

IFS can be defined in the environment.

The kernel cannot use that definition because it introduces buffer limits
and a potential overflow. Besides, the kernel can run scripts from
applications that may not have or pass IFS, or it's equivalent in whatever
shell is being used (I seem to remember an Icon shell that used commas).

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]