NetBSD Problem Report #23729

Received: (qmail 26240 invoked by uid 605); 12 Dec 2003 20:50:26 -0000
Message-Id: <20031212205025.87B931115D@narn.netbsd.org>
Date: Fri, 12 Dec 2003 20:50:25 +0000 (UTC)
From: refling@acm.org
Sender: gnats-bugs-owner@NetBSD.org
Reply-To: refling@acm.org
To: gnats-bugs@gnats.NetBSD.org
Subject: please add a FAQ on the 'Syntax error: "(" unexpected' ld.so issue
X-Send-Pr-Version: www-1.0

>Number:         23729
>Category:       misc
>Synopsis:       please add a FAQ on the 'Syntax error: "(" unexpected' ld.so issue
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    misc-bug-people
>State:          closed
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Fri Dec 12 20:51:01 +0000 2003
>Closed-Date:    Sat Jun 18 08:05:50 +0000 2022
>Last-Modified:  Sat Jun 18 08:10:01 +0000 2022
>Originator:     John Refling
>Release:        1.6.1
>Organization:
>Environment:
i386, sparc, etc
>Description:
The 'Syntax error: "(" unexpected' error message (typically occuring
when ld.so is missing) is absolutely non-informative to the novice
user.

Could a brief FAQ be created, probably under "Common (and not so common)
problems" which at least mentions this symptom [in its title], and a
brief mention of what might be happening, eg, /usr/libexec/ld.so is
missing, etc.

There was some brief discussion in tech-kern, starting 04/16/2001
under the title "poor error reporting when ls.so is missing".


>How-To-Repeat:

>Fix:

add a brief FAQ

>Release-Note:
>Audit-Trail:
From: dholland@eecs.harvard.edu (David Holland)
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: misc/23729: Syntax error: "(" unexpected
Date: Sat, 7 Oct 2006 21:07:25 -0400 (EDT)

 As of now, the only widely used shells that try to run files that
 won't exec() are sh and ksh. All the others fail, which you can verify
 by taking your favorite hello.c, compiling, and then editing the
 binary to replace "ld_elf.so" with, say, "ld_alf.so". This produces
 these results:

    % csh -c ./hullo 
    ./hullo: Exec format error. Wrong Architecture.

    % bash -c ./hullo 
    bash: ./hullo: cannot execute binary file

    % tcsh -c ./hullo 
    ./hullo: Exec format error. Binary file not executable.

    % zsh -c ./hullo 
    zsh: exec format error: ./hullo

 and

    % sh -c ./hullo 
    ./hullo: 1: Syntax error: "(" unexpected

    % ksh -c ./hullo 
    ./hullo: 1: Syntax error: "(" unexpected

 The behavior exhibited by sh and ksh is historic, but hasn't been
 useful since #! was invented, which was a long time ago.

 Probably the best thing to do is to remove it.

 -- 
    - David A. Holland / dholland@eecs.harvard.edu

From: David Laight <david@l8s.co.uk>
To: gnats-bugs@NetBSD.org
Cc: misc-bug-people@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org, refling@acm.org
Subject: Re: misc/23729: Syntax error: "(" unexpected
Date: Sun, 8 Oct 2006 12:49:13 +0100

 On Sun, Oct 08, 2006 at 01:10:03AM +0000, David Holland wrote:
 >  
 >  The behavior exhibited by sh and ksh is historic, but hasn't been
 >  useful since #! was invented, which was a long time ago.

 Actually it looks as though the other shells do a rudimentary check
 that the file is a text file before executing it as a script.

 If you give them a C source file you'll probobably find they try to
 parse it as commands.

 	David

 -- 
 David Laight: david@l8s.co.uk

From: Alan Barrett <apb@cequrux.com>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: misc/23729: Syntax error: "(" unexpected
Date: Sun, 8 Oct 2006 16:55:17 +0200

 On Sun, 08 Oct 2006, David Holland wrote:
 >     % sh -c ./hullo 
 >     ./hullo: 1: Syntax error: "(" unexpected
 >  
 >     % ksh -c ./hullo 
 >     ./hullo: 1: Syntax error: "(" unexpected
 >  
 >  The behavior exhibited by sh and ksh is historic, but hasn't been
 >  useful since #! was invented, which was a long time ago.
 >  
 >  Probably the best thing to do is to remove it.

 I agree.  I'd like {sh $file} to always interpret $file as a shell
 script, and never try to exec it or parse #! lines.  And I'd like {sh
 -c $file} to check whether file is an alias or builtin command, and if
 not then exec it (leaving the kernel to worry about magic numbers and
 #! lines).  I think POSIX agrees with me, but it's a bit difficult to
 follow their description.

 --apb (Alan Barrett)

From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@NetBSD.org, misc-bug-people@netbsd.org,
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, refling@acm.org
Cc: 
Subject: Re: misc/23729: Syntax error: "(" unexpected
Date: Sun, 8 Oct 2006 22:10:15 -0400

 On Oct 8,  1:10am, dholland@eecs.harvard.edu (David Holland) wrote:
 -- Subject: Re: misc/23729: Syntax error: "(" unexpected

 | The following reply was made to PR misc/23729; it has been noted by GNATS.
 | 
 | From: dholland@eecs.harvard.edu (David Holland)
 | To: gnats-bugs@NetBSD.org
 | Cc: 
 | Subject: Re: misc/23729: Syntax error: "(" unexpected
 | Date: Sat, 7 Oct 2006 21:07:25 -0400 (EDT)
 | 
 |  As of now, the only widely used shells that try to run files that
 |  won't exec() are sh and ksh. All the others fail, which you can verify
 |  by taking your favorite hello.c, compiling, and then editing the
 |  binary to replace "ld_elf.so" with, say, "ld_alf.so". This produces
 |  these results:
 |  
 |     % csh -c ./hullo 
 |     ./hullo: Exec format error. Wrong Architecture.
 |  
 |     % bash -c ./hullo 
 |     bash: ./hullo: cannot execute binary file
 |  
 |     % tcsh -c ./hullo 
 |     ./hullo: Exec format error. Binary file not executable.
 |  
 |     % zsh -c ./hullo 
 |     zsh: exec format error: ./hullo
 |  
 |  and
 |  
 |     % sh -c ./hullo 
 |     ./hullo: 1: Syntax error: "(" unexpected
 |  
 |     % ksh -c ./hullo 
 |     ./hullo: 1: Syntax error: "(" unexpected
 |  
 |  The behavior exhibited by sh and ksh is historic, but hasn't been
 |  useful since #! was invented, which was a long time ago.
 |  
 |  Probably the best thing to do is to remove it.

 And what happens to shell scripts that don't start with #!?

 christos

From: Alan Barrett <apb@cequrux.com>
To: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org
Cc: 
Subject: Re: misc/23729: Syntax error: "(" unexpected
Date: Mon, 9 Oct 2006 21:59:13 +0200

 On Sun, 08 Oct 2006, Christos Zoulas wrote:
 > |  The behavior exhibited by sh and ksh is historic, but hasn't been
 > |  useful since #! was invented, which was a long time ago.
 > |  
 > |  Probably the best thing to do is to remove it.
 > 
 > And what happens to shell scripts that don't start with #!?

 If you tell the shell to treat them as scripts, via 'sh filename', they
 should work.  If you tell the shell to exec them, via 'sh -c filename'
 or just 'filename' from inside a shell, then I think you should get an
 exec failure, just as if you did execlp("filename", "filename", NULL).

 --apb (Alan Barrett)

State-Changed-From-To: open->feedback
State-Changed-By: kre@NetBSD.org
State-Changed-When: Fri, 17 Jun 2022 05:32:43 +0000
State-Changed-Why:

Can we close this PR?

In the intervening time, the world has changed.  When the run time linker
is missing, systems (including ours) now seem to all report ENOENT
to the exec attempt - when that happens the shell assumes that the path
name it passed to the kernel doesn't exist (any more, in many cases it
just previously found it via a PATH search) and simply does nothing more.

Also, /bin/sh now does a check for exec'ing ELF format files, and no
longer tries to run them as scripts, when the simple exec fails (if you
ask to run it as a script "sh file" then it will attempt it of course).

Not sure about /bin/ksh - but as long as the kernel is returning ENOENT
in the case in question, it also doesn't have the problem reported.

In any case, I don't think we really need (any more) a FAQ about this
particular issue.

FWIW: I believe our (and almost everyone else's) kernel to be broken in
this area, once it has determined that the file passed to exec exists,
checked permissions, checked its format (and all the other stuff it
checked before deciding to allow an exec), it should stop reporting any
more specific errors, anything which fails after that point (which includes
the attempt to find /libexec/ld.elf_so, or the interpreter listed in a
#!, or where the user lacks permission to run that, or anything similar
(like a "ln -s /etc /etc" symlink ELOOP error) should be reported as
ENOEXEC, that is, there is something wrong with the file being exec'd
and we cannot do that.

That systems don't do this was reported as a bash bug just recently,
(wrt some linux version or other) with a request that bash look at
ENOENT errors returned, and work out what was not found, so the error
message doesn't appear to be saying that the command named doesn't exist
where the user can clearly see with "ls" that it does.   Having a shell
do the work for that would be absurd, even having it add weasel words
(which was a watered down request) so that ENOENT errors would be reported
as something like "file doesn't exist or some other file needed to run it
doesn't exist" is fairly dumb, when the obvious correct thing to do is to
fix the kernel to map all those late errors into ENOENT.

But none of that is an issue for this PR.  I just felt like a rant!


From: matthew green <mrg@eterna.com.au>
To: gnats-bugs@netbsd.org
Cc: misc-bug-people@netbsd.org, netbsd-bugs@netbsd.org,
    gnats-admin@netbsd.org, kre@NetBSD.org, refling@acm.org
Subject: re: misc/23729 (please add a FAQ on the 'Syntax error: "(" unexpected' ld.so issue)
Date: Fri, 17 Jun 2022 15:40:21 +1000

 > Can we close this PR?

 at least for sh, i think it's resolved due to:

 > Also, /bin/sh now does a check for exec'ing ELF format files, and no
 > longer tries to run them as scripts, when the simple exec fails (if you
 > ask to run it as a script "sh file" then it will attempt it of course).


 > Not sure about /bin/ksh - but as long as the kernel is returning ENOENT
 > in the case in question, it also doesn't have the problem reported.

 ksh is fun :)

 space-bird ~> /bin/sh /bin/sh
 /bin/sh: Cannot execute ELF binary /bin/sh
 space-bird ~> /bin/ksh /bin/ksh
 /bin/ksh[1]: syntax error: `QX^F^DFC#*U^M' unexpected
 /bin/ksh[1]:
 space-bird ~> /bin/ksh /bin/sh
 /bin/sh[3]: syntax error: `(' unexpected
 /bin/sh[3]:

 csh and tcsh are even more fun.  the different is related to
 the 2nd arg (similar output depending on the input.)

 space-bird ~> /bin/csh /bin/csh
 ^F^D@@@M-@^AM-@^A^H^C^D^B^B^B^S^S^A^A^EM-4B^BM-4B^B: Event not found.

 space-bird ~> /bin/tcsh /bin/tcsh
 ^?ELF^B^A^A^B: Command not found.
 Missing }.
 Missing }.
 H\205\377^O\204^]^AL\215\255\220\376\377\377\350F^^^DI\211\304L\211\356H\2=
 11\307\350\210\343: Command not found.
 [1] 12918
 \2441H\213E\310H+^E^S\3052^O\205/^BH\201\304h^A[AA]A^A_]\303L\211\346\277:=
  No match.
 Illegal variable name.
 \202u3E1\377H9\312A^O\237\307\213\205\230\376\377\377%\360=3D@^O\204\367H\=
 203\275\377\377\377^O\204\250H\213\205\300\376\377\377H9\302^O\216\230H\21=
 35\325\2441H9\360^?: Command not found.
 Missing }.
 H\205\377^O\205\361\376\377\377H\213\225\210\376\377\377H\211^U: Command n=
 ot found.


 .mrg.

From: <refling@alumni.stanford.edu>
To: <gnats-bugs@netbsd.org>
Cc: 
Subject: RE: misc/23729 (please add a FAQ on the 'Syntax error: "(" unexpected' ld.so issue)
Date: Fri, 17 Jun 2022 13:28:18 -0700

 Yes, probably time to close it.

 John Refling 

 -----Original Message-----
 From: matthew green [mailto:mrg@eterna.com.au] 
 Sent: Thursday, June 16, 2022 10:45 PM
 To: misc-bug-people@netbsd.org; gnats-admin@netbsd.org;
 netbsd-bugs@netbsd.org; refling@acm.org
 Subject: re: misc/23729 (please add a FAQ on the 'Syntax error: "("
 unexpected' ld.so issue)

 The following reply was made to PR misc/23729; it has been noted by GNATS.

 From: matthew green <mrg@eterna.com.au>
 To: gnats-bugs@netbsd.org
 Cc: misc-bug-people@netbsd.org, netbsd-bugs@netbsd.org,
     gnats-admin@netbsd.org, kre@NetBSD.org, refling@acm.org
 Subject: re: misc/23729 (please add a FAQ on the 'Syntax error: "("
 unexpected' ld.so issue)
 Date: Fri, 17 Jun 2022 15:40:21 +1000

  > Can we close this PR?

  at least for sh, i think it's resolved due to:

  > Also, /bin/sh now does a check for exec'ing ELF format files, and no  >
 longer tries to run them as scripts, when the simple exec fails (if you  >
 ask to run it as a script "sh file" then it will attempt it of course).


  > Not sure about /bin/ksh - but as long as the kernel is returning ENOENT
 > in the case in question, it also doesn't have the problem reported.

  ksh is fun :)

  space-bird ~> /bin/sh /bin/sh
  /bin/sh: Cannot execute ELF binary /bin/sh  space-bird ~> /bin/ksh /bin/ksh
  /bin/ksh[1]: syntax error: `QX^F^DFC#*U^M' unexpected
  /bin/ksh[1]:
  space-bird ~> /bin/ksh /bin/sh
  /bin/sh[3]: syntax error: `(' unexpected
  /bin/sh[3]:

  csh and tcsh are even more fun.  the different is related to  the 2nd arg
 (similar output depending on the input.)

  space-bird ~> /bin/csh /bin/csh
  ^F^D@@@M-@^AM-@^A^H^C^D^B^B^B^S^S^A^A^EM-4B^BM-4B^B: Event not found.

  space-bird ~> /bin/tcsh /bin/tcsh
  ^?ELF^B^A^A^B: Command not found.
  Missing }.
  Missing }.
  H\205\377^O\204^]^AL\215\255\220\376\377\377\350F^^^DI\211\304L\211\356H\2=
  11\307\350\210\343: Command not found.
  [1] 12918
  \2441H\213E\310H+^E^S\3052^O\205/^BH\201\304h^A[AA]A^A_]\303L\211\346\277:=
   No match.
  Illegal variable name.
  \202u3E1\377H9\312A^O\237\307\213\205\230\376\377\377%\360=3D@^O\204\367H\=
  203\275\377\377\377^O\204\250H\213\205\300\376\377\377H9\302^O\216\230H\21=
  35\325\2441H9\360^?: Command not found.
  Missing }.
  H\205\377^O\205\361\376\377\377H\213\225\210\376\377\377H\211^U: Command n=
 ot found.


  .mrg.


From: Robert Elz <kre@munnari.OZ.AU>
To: matthew green <mrg@eterna.com.au>
Cc: gnats-bugs@netbsd.org, misc-bug-people@netbsd.org, netbsd-bugs@netbsd.org,
        gnats-admin@netbsd.org, refling@acm.org
Subject: Re: misc/23729 (please add a FAQ on the 'Syntax error: "(" unexpected' ld.so issue)
Date: Fri, 17 Jun 2022 21:47:30 +0700

     Date:        Fri, 17 Jun 2022 15:40:21 +1000
     From:        matthew green <mrg@eterna.com.au>
     Message-ID:  <6302.1655444421@splode.eterna.com.au>

   | space-bird ~> /bin/sh /bin/sh
   | /bin/sh: Cannot execute ELF binary /bin/sh

 hmmm  ... that looks like  a bug.  If run that way, the shell
 should try to run it, just like all the other shells you tried
 did.  POSIX does make it undefined/unspecified what happens
 when there are any \0's in any part of the script that could be
 executed (ie: not counting random data that may followw) so
 we are probably technically conformant, but that still seems
 wrong.

 I will, however, resist fixing it fir a few days to see what
 others think.

 The issue in the PR (which is not really about this problem
 at all) concerns seemingly sane, executable, commands - typically
 found via a PATH search, though not always - for which exec()
 fails with ENOEXEC - which shells from the ancient past, long before
 #! was invented, have always treated as meaning "command is a sh
 script", and so simply opened and tried to parse that way.

 That is still required by POSIX (which does not have #!), but
 they do now permit the shell to use a heuristic to guess
 whether the file really is a script or not.

 Most shells implement such a test now (but less did when this
 PR was filed .. POSIX didn't allow it then) so the problem
 reported occurs far less often than it did (it is still not
 well handked).

 kre

State-Changed-From-To: feedback->closed
State-Changed-By: kre@NetBSD.org
State-Changed-When: Sat, 18 Jun 2022 08:05:50 +0000
State-Changed-Why:
Shells have changed, the error in question no longer appears often.


From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: misc/23729 (please add a FAQ on the 'Syntax error: "(" unexpected' ld.so issue)
Date: Sat, 18 Jun 2022 15:06:19 +0700

     Date:        Fri, 17 Jun 2022 20:30:02 +0000 (UTC)
     From:        <refling@alumni.stanford.edu>
     Message-ID:  <20220617203002.849E01A923C@mollari.NetBSD.org>

   |  Yes, probably time to close it.

 OK, thanks, done.

 kre


>Unformatted:

Home	PR Database Search