From robert@fledge.watson.org  Sat Sep 16 11:50:11 2000
Return-Path: <robert@fledge.watson.org>
Received: from fledge.watson.org (fledge.watson.org [204.156.12.50])
	by hub.freebsd.org (Postfix) with ESMTP id 8B9C537B422
	for <FreeBSD-gnats-submit@freebsd.org>; Sat, 16 Sep 2000 11:50:10 -0700 (PDT)
Received: (from robert@localhost)
	by fledge.watson.org (8.9.3/8.9.3) id OAA03050;
	Sat, 16 Sep 2000 14:50:11 -0400 (EDT)
	(envelope-from robert)
Message-Id: <200009161850.OAA03050@fledge.watson.org>
Date: Sat, 16 Sep 2000 14:50:11 -0400 (EDT)
From: rwatson@freebsd.org
Sender: robert@fledge.watson.org
Reply-To: rwatson@freebsd.org
To: FreeBSD-gnats-submit@freebsd.org
Subject: Bizarre shell interpreter failure mode
X-Send-Pr-Version: 3.2

>Number:         21315
>Category:       bin
>Synopsis:       Shells often behave oddly when executing shell scripts
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Sep 16 12:00:01 PDT 2000
>Closed-Date:    Fri Nov 11 19:25:14 UTC 2011
>Last-Modified:  Fri Nov 11 19:25:14 UTC 2011
>Originator:     Robert Watson
>Release:        FreeBSD 4.1-STABLE i386
>Organization:
>Environment:

FreeBSD mocking.southhadley.watson.org 4.1-STABLE FreeBSD 4.1-STABLE #1: Mon Aug  7 14:13:19 EDT 2000     root@numocking.gw.tislabs.com:/usr/src/sys/compile/MOCKING  i386

>Description:

Shells appear to behave oddly when executing shell scripts in a number of
situations.

(1) When the kernel discovers that the interpreter used is another
    interpreter, it generally returns ``Exec format error'' (ENOEXEC).
    However, when csh and sh find themselves in the same situation, they
    don't return that error, they execute the script using their own
    interpreter.

(2) When in single-user mode, the sh shell appears to assume that any
    script it runs should be executed using its own interpreter, not
    the interpreter at the top of the file.  In multi-user mode, this
    appears to work fine.

>How-To-Repeat:

(1)

    $ cat /tmp/test1
    #!/tmp/test2
    echo This is test1, meant to execute using test2
    $ cat /tmp/test2
    #!/tmp/test1
    echo This is test2, meant to execute with test1
    $ /tmp/test1
    This is test1, meant to execute using test2
    $ /tmp/test2
    This is test2, meant to execute with test1
    $

I.e., executing test1 resulted in sh executing it, instead of ENOEXEC.
Similarly with test2.  Neither resulted in a recursive call, which is
good.  This seems like a poor failure-mode -- it's inconsistent with
the kernel execve() implementation's failure mode, and it runs things
when you would hope that it wouldn't (always bad).

(2)

Boot to single user mode, select /bin/sh as the shell, and attempt to
execute a shell script relying on csh features.

>Fix:

Not attached.


>Release-Note:
>Audit-Trail:

From: Jilles Tjoelker <jilles@stack.nl>
To: bug-followup@FreeBSD.org, rwatson@freebsd.org
Cc:  
Subject: Re: bin/21315: Shells often behave oddly when executing shell
	scripts
Date: Sun, 5 Apr 2009 01:22:34 +0200

 > Shells appear to behave oddly when executing shell scripts in a number
 > of situations.
 
 > (1) When the kernel discovers that the interpreter used is another
 > interpreter, it generally returns ``Exec format error'' (ENOEXEC).
 > However, when csh and sh find themselves in the same situation, they
 > don't return that error, they execute the script using their own
 > interpreter.
 
 In the case of sh, POSIX says that it should do this. If sh gets ENOEXEC
 or equivalent when it tries to execute something, it should execute the
 file as a shell script. Only if the file is not a text file may sh
 refuse to execute it, writing an error message and returning an exit
 status of 126. (Our sh does not use this exception, resulting in
 messages like '1: Syntax error: "(" unexpected' when trying to execute
 an ELF binary for a different architecture.)
 
 > (2) When in single-user mode, the sh shell appears to assume that any
 > script it runs should be executed using its own interpreter, not the
 > interpreter at the top of the file. In multi-user mode, this appears
 > to work fine.
 
 I have no idea about this, but it could have something to do with
 ENOEXEC as well. In particular, when this PR was written, ld-elf.so.1
 was in /usr/libexec, so unavailable when /usr was not mounted.
 
 -- 
 Jilles Tjoelker
State-Changed-From-To: open->feedback 
State-Changed-By: jh 
State-Changed-When: Sun Sep 25 13:31:18 UTC 2011 
State-Changed-Why:  
Should this PR still kept open? 

http://www.freebsd.org/cgi/query-pr.cgi?pr=21315 
State-Changed-From-To: feedback->closed 
State-Changed-By: jh 
State-Changed-When: Fri Nov 11 19:25:13 UTC 2011 
State-Changed-Why:  
Feedback timeout. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=21315 
>Unformatted:
