Debian Bug report logs - #609882
libc6: "No such file or directory" error when attempting to execute LSB executable without lsb-core

version graph

Package: command-not-found; Maintainer for command-not-found is Julian Andres Klode <jak@debian.org>; Source for command-not-found is src:command-not-found.

Reported by: Graham Inggs <graham.inggs@uct.ac.za>

Date: Thu, 13 Jan 2011 13:36:01 UTC

Severity: wishlist

Merged with 697299

Found in version command-not-found/0.2.38-1

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#609882; Package libc6. (Thu, 13 Jan 2011 13:36:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Graham Inggs <graham.inggs@uct.ac.za>:
New Bug report received and forwarded. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. (Thu, 13 Jan 2011 13:36:04 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Graham Inggs <graham.inggs@uct.ac.za>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: libc6: "No such file or directory" error when attempting to execute LSB executable without lsb-core
Date: Thu, 13 Jan 2011 15:34:34 +0200
Package: libc6
Version: 2.11.2-8
Severity: normal

On an amd64 architecture system without lsb-core installed, download 
lmutil_x64_lsb.tar.gz from 
http://www.globes.com/support/fnp_utilities_download.htm
Extract the file from the archive, mark it executable and then attempt 
to execute it:

$ ./lmutil
bash: ./lmutil: No such file or directory

The error message should be more informative, for example:

This program requires 'lsb-core' which is currently not installed.  You 
can install it by typing:
sudo apt-get install lsb-core



-- System Information:
Debian Release: 6.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.36-2.slh.3-aptosid-amd64 (SMP w/1 CPU core; PREEMPT)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libc6 depends on:
ii  libc-bin                      2.11.2-8   Embedded GNU C Library: 
Binaries
ii  libgcc1                       1:4.4.5-10 GCC support library

libc6 recommends no packages.

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]         1.5.37     Debian configuration 
management sy
pn  glibc-doc <none>     (no description available)
ii  locales                       2.11.2-8   Embedded GNU C Library: 
National L

-- debconf information:
  glibc/upgrade: true
  glibc/disable-screensaver:
  glibc/restart-failed:
  glibc/restart-services:





Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#609882; Package libc6. (Thu, 13 Jan 2011 22:45:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Aurelien Jarno <aurelien@aurel32.net>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. (Thu, 13 Jan 2011 22:45:06 GMT) Full text and rfc822 format available.

Message #10 received at 609882@bugs.debian.org (full text, mbox):

From: Aurelien Jarno <aurelien@aurel32.net>
To: Graham Inggs <graham.inggs@uct.ac.za>, 609882@bugs.debian.org
Cc: control@bugs.debian.org
Subject: Re: Bug#609882: libc6: "No such file or directory" error when attempting to execute LSB executable without lsb-core
Date: Thu, 13 Jan 2011 23:43:30 +0100
reassign 609882 command-not-found
thanks

On Thu, Jan 13, 2011 at 03:34:34PM +0200, Graham Inggs wrote:
> Package: libc6
> Version: 2.11.2-8
> Severity: normal
>
> On an amd64 architecture system without lsb-core installed, download  
> lmutil_x64_lsb.tar.gz from  
> http://www.globes.com/support/fnp_utilities_download.htm
> Extract the file from the archive, mark it executable and then attempt  
> to execute it:
>
> $ ./lmutil
> bash: ./lmutil: No such file or directory
>
> The error message should be more informative, for example:
>
> This program requires 'lsb-core' which is currently not installed.  You  
> can install it by typing:
> sudo apt-get install lsb-core
>

I fail to see the relation with libc6. Reassigning to the 
"command-not-found" package.

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net




Bug reassigned from package 'libc6' to 'command-not-found'. Request was from Aurelien Jarno <aurelien@aurel32.net> to control@bugs.debian.org. (Thu, 13 Jan 2011 22:45:08 GMT) Full text and rfc822 format available.

Bug No longer marked as found in versions eglibc/2.11.2-8. Request was from Aurelien Jarno <aurelien@aurel32.net> to control@bugs.debian.org. (Thu, 13 Jan 2011 22:45:08 GMT) Full text and rfc822 format available.

Bug reassigned from package 'command-not-found' to 'bash'. Request was from Stefano Rivera <stefano@rivera.za.net> to control@bugs.debian.org. (Fri, 14 Jan 2011 10:30:03 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Matthias Klose <doko@debian.org>:
Bug#609882; Package bash. (Fri, 14 Jan 2011 10:36:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Stefano Rivera <stefano@rivera.za.net>:
Extra info received and forwarded to list. Copy sent to Matthias Klose <doko@debian.org>. (Fri, 14 Jan 2011 10:36:06 GMT) Full text and rfc822 format available.

Message #21 received at 609882@bugs.debian.org (full text, mbox):

From: Stefano Rivera <stefano@rivera.za.net>
To: 609882@bugs.debian.org
Cc: Graham Inggs <graham.inggs@gmail.com>, control@bugs.debian.org
Subject: Bug#609882: libc6: "No such file or directory" error when attempting to execute LSB executable without lsb-core
Date: Fri, 14 Jan 2011 12:27:12 +0200
reassign 609882 bash
thanks

It looks like the commmand-not-found handler won't work here:
$ function command_not_found_handle { echo handled; }
$ export PATH=.:$PATH
$ lmutilfoo
handled
$ lmutil
bash: ./lmutil: No such file or directory

The program is there, on the path, but the interpretor required doesn't exist.

Yes, ld-linux doesn't seem to be involved:
$ strace -e execve -f sh -c ./lmutil
execve("/bin/sh", ["sh", "-c", "./lmutil"], [/* 55 vars */]) = 0
Process 14084 attached
[pid 14084] execve("./lmutil", ["./lmutil"], [/* 55 vars */]) = -1 ENOENT (No such file or directory)
sh: ./lmutil: not found
Process 14084 detached
--- SIGCHLD (Child exited) @ 0 (0) ---

It's rare for ELFs to require missing interpretors, so this is rather a special
case...
shell_execve (execute_cmd.c) does check for missing interpretors for
scripts (with shebangs) but not for ELFs

$ cat > testscript
#!/bin/foobarbaz
$ chmod +x testscript 
$ testscript 
bash: ./testscript: /bin/foobarbaz: bad interpreter: No such file or directory

Now, *that* gives a more useful error, maybe something to aim for.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  H: +27 21 465 6908 C: +27 72 419 8559  UCT: x3127




Information forwarded to debian-bugs-dist@lists.debian.org, Matthias Klose <doko@debian.org>:
Bug#609882; Package bash. (Fri, 27 Jan 2012 14:48:17 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jan Behrend <jbehrend@mpifr-bonn.mpg.de>:
Extra info received and forwarded to list. Copy sent to Matthias Klose <doko@debian.org>. (Fri, 27 Jan 2012 14:48:17 GMT) Full text and rfc822 format available.

Message #26 received at 609882@bugs.debian.org (full text, mbox):

From: Jan Behrend <jbehrend@mpifr-bonn.mpg.de>
To: <609882@bugs.debian.org>
Subject: libc6: "No such file or directory" error when attempting to execute LSB executable without lsb-core
Date: Fri, 27 Jan 2012 15:11:20 +0100
Hi,

I did some investigating and came up with the following:

If you purge all packages which lsb-core depends on and lsb-core 
itself,
lmutil remains functional, which is odd in the first place.
But if you look at the postinstall script of lsb-core the two symlinks
it creates make all the difference.  Unfortunately these symlinks to 
_not_
get removed by the postrm script.

lsb-core.postinst:
amd64)
 [...]
 ln -sf /lib/ld-linux-x86-64.so.2 /lib64/ld-lsb-x86-64.so.2
 ln -sf /lib/ld-linux-x86-64.so.2 /lib64/ld-lsb-x86-64.so.3

Hope this helps.
Cheers Jan

-- 
MAX-PLANCK-INSTITUT fuer Radioastronomie
Jan Behrend - Rechenzentrum
----------------------------------------
Auf dem Huegel 69, D-53121 Bonn
Tel: +49 (228) 525 359, Fax: +49 (228) 525 229
jbehrend@mpifr-bonn.mpg.de http://www.mpifr-bonn.mpg.de




Information forwarded to debian-bugs-dist@lists.debian.org, Matthias Klose <doko@debian.org>:
Bug#609882; Package bash. (Thu, 03 Jan 2013 18:30:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Matthias Klose <doko@debian.org>. (Thu, 03 Jan 2013 18:30:03 GMT) Full text and rfc822 format available.

Message #31 received at 609882@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: debian-devel@lists.debian.org
Cc: 609882@bugs.debian.org
Subject: Re: Bug#697270: PC 32-bit programs fails to work on amd64
Date: Thu, 03 Jan 2013 10:26:46 -0800
Timo Weingärtner <timo@tiwe.de> writes:
> 2013-01-03 um 18:32:28 schrieb Russ Allbery:
>> Alexey Eromenko <al4321@gmail.com> writes:

>>> User error? Huh ?

>>> No ! This is a Debian Bug !
>>> Debian clearly says: "File does not exist", while in fact it DOES EXIST.
>>> This is a 100% proof of Debian bug.

> I guess it is bash telling you that.

>> That's the error message that you get when the dynamic loader for a
>> binary doesn't exist.  I think that's been the case for as long as
>> Linux has existed.

> That's already reported as bug #609882.

I think that's asking quite a lot of bash.  Wouldn't it have to open the
binary and parse the ELF headers, extracting the INTERP header, in order
to verify that?  Does it really make sense to encode understanding of ELF
binary layout formats in bash?

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>



Merged 609882 697299 Request was from Timo Weingärtner <timo@tiwe.de> to control@bugs.debian.org. (Thu, 03 Jan 2013 18:33:03 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Matthias Klose <doko@debian.org>:
Bug#609882; Package bash. (Thu, 03 Jan 2013 18:42:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Matthias Klose <doko@debian.org>. (Thu, 03 Jan 2013 18:42:03 GMT) Full text and rfc822 format available.

Message #38 received at 609882@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Russ Allbery <rra@debian.org>
Cc: 609882@bugs.debian.org
Subject: Re: bash: "File does not exist" when ELF interpreter is missing
Date: Thu, 3 Jan 2013 10:37:44 -0800
Russ Allbery wrote:
> Timo Weingärtner <timo@tiwe.de> writes:
>>> Alexey Eromenko <al4321@gmail.com> writes:

>>>> Debian clearly says: "File does not exist", while in fact it DOES EXIST.
>>>> This is a 100% proof of Debian bug.
>>
>> I guess it is bash telling you that.
[...]
> I think that's asking quite a lot of bash.  Wouldn't it have to open the
> binary and parse the ELF headers, extracting the INTERP header, in order
> to verify that?  Does it really make sense to encode understanding of ELF
> binary layout formats in bash?

I suppose it could check if the file exists itself, or it could always
use a message like "File or interpreter does not exist".



Information forwarded to debian-bugs-dist@lists.debian.org, Matthias Klose <doko@debian.org>:
Bug#609882; Package bash. (Thu, 03 Jan 2013 18:45:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Timo Weingärtner <timo@tiwe.de>:
Extra info received and forwarded to list. Copy sent to Matthias Klose <doko@debian.org>. (Thu, 03 Jan 2013 18:45:03 GMT) Full text and rfc822 format available.

Message #43 received at 609882@bugs.debian.org (full text, mbox):

From: Timo Weingärtner <timo@tiwe.de>
To: 609882@bugs.debian.org
Cc: debian-devel@lists.debian.org
Subject: Re: Bug#697270: PC 32-bit programs fails to work on amd64
Date: Thu, 3 Jan 2013 19:42:42 +0100
[Message part 1 (text/plain, inline)]
Hallo Russ Allbery,

2013-01-03 um 19:26:46 schriebst Du:
> Timo Weingärtner <timo@tiwe.de> writes:
> > 2013-01-03 um 18:32:28 schrieb Russ Allbery:
> >> Alexey Eromenko <al4321@gmail.com> writes:
> >>> User error? Huh ?
> >>> 
> >>> No ! This is a Debian Bug !
> >>> Debian clearly says: "File does not exist", while in fact it DOES
> >>> EXIST. This is a 100% proof of Debian bug.
> > 
> > I guess it is bash telling you that.
> > 
> >> That's the error message that you get when the dynamic loader for a
> >> binary doesn't exist.  I think that's been the case for as long as
> >> Linux has existed.
> > 
> > That's already reported as bug #609882.
> 
> I think that's asking quite a lot of bash.  Wouldn't it have to open the
> binary and parse the ELF headers, extracting the INTERP header, in order
> to verify that?  Does it really make sense to encode understanding of ELF
> binary layout formats in bash?

As seen in strace bash already checks for existance of the script and the 
#!interpreter. So when execve threw a ENOENT ("The file filename or a script 
or ELF interpreter does not exist, or a shared library needed for file or 
interpreter cannot be found.") it could at least say something like 
"interpreter or libs not found, try ldd for debugging".


Grüße
Timo
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Matthias Klose <doko@debian.org>:
Bug#609882; Package bash. (Thu, 03 Jan 2013 18:45:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Matthias Klose <doko@debian.org>. (Thu, 03 Jan 2013 18:45:05 GMT) Full text and rfc822 format available.

Message #48 received at 609882@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Russ Allbery <rra@debian.org>
Cc: debian-devel@lists.debian.org, 609882@bugs.debian.org
Subject: Re: Bug#697270: PC 32-bit programs fails to work on amd64
Date: Thu, 3 Jan 2013 10:43:22 -0800
[Message part 1 (text/plain, inline)]
On Thu, Jan 03, 2013 at 10:26:46AM -0800, Russ Allbery wrote:
> >> That's the error message that you get when the dynamic loader for a
> >> binary doesn't exist.  I think that's been the case for as long as
> >> Linux has existed.

> > That's already reported as bug #609882.

> I think that's asking quite a lot of bash.  Wouldn't it have to open the
> binary and parse the ELF headers, extracting the INTERP header, in order
> to verify that?  Does it really make sense to encode understanding of ELF
> binary layout formats in bash?

No, it doesn't.  Especially when binfmt_misc means you can get this error
from an arbitrary number of file formats with arbitrary levels of
interpreter nesting.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Matthias Klose <doko@debian.org>:
Bug#609882; Package bash. (Thu, 03 Jan 2013 18:45:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Matthias Klose <doko@debian.org>. (Thu, 03 Jan 2013 18:45:07 GMT) Full text and rfc822 format available.

Message #53 received at 609882@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: 609882@bugs.debian.org
Subject: Re: bash: "File does not exist" when ELF interpreter is missing
Date: Thu, 03 Jan 2013 10:44:11 -0800
Jonathan Nieder <jrnieder@gmail.com> writes:
> Russ Allbery wrote:

>> I think that's asking quite a lot of bash.  Wouldn't it have to open
>> the binary and parse the ELF headers, extracting the INTERP header, in
>> order to verify that?  Does it really make sense to encode
>> understanding of ELF binary layout formats in bash?

> I suppose it could check if the file exists itself, or it could always
> use a message like "File or interpreter does not exist".

I suppose, but I guess if I were the bash maintainer I would be unenthused
by this slippery slope.  Right now (presumably; I haven't looked at the
code), it's calling the appropriate syscall via libc, getting back ENOENT,
and printing out strerror(errno).

Messing about with checking things afterwards is sort of second-guessing
the kernel (what if the file was deleted between the point that it tried
to run it and the point at which it tried to check for its existence?).
If we want to distinguish between missing file and missing interpreter,
wouldn't it be better to introduce a new errno value that correctly
represents that difference?  After all, the kernel knows which problem it
had.  It just collapses them into a single errno value.

Of course, introducing a new errno value is hard and requires upstream
coordination between the kernel and glibc, not to mention some possible
impact on compatibility if any code out there is relying on getting ENOENT
when the interpreter isn't found.  Which, I suppose, is the argument for
doing this in bash.  (Although I'm inclined to agree with the original
reassignment of the bug: this sort of magic seems like what
command-not-found is for.)

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>



Information forwarded to debian-bugs-dist@lists.debian.org, Matthias Klose <doko@debian.org>:
Bug#609882; Package bash. (Thu, 03 Jan 2013 18:51:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Matthias Klose <doko@debian.org>. (Thu, 03 Jan 2013 18:51:03 GMT) Full text and rfc822 format available.

Message #58 received at 609882@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: 609882@bugs.debian.org, debian-devel@lists.debian.org
Subject: Re: Bug#697270: PC 32-bit programs fails to work on amd64
Date: Thu, 03 Jan 2013 10:46:54 -0800
Timo Weingärtner <timo@tiwe.de> writes:
> Hallo Russ Allbery,

>> I think that's asking quite a lot of bash.  Wouldn't it have to open
>> the binary and parse the ELF headers, extracting the INTERP header, in
>> order to verify that?  Does it really make sense to encode
>> understanding of ELF binary layout formats in bash?

> As seen in strace bash already checks for existance of the script and
> the #!interpreter. So when execve threw a ENOENT ("The file filename or
> a script or ELF interpreter does not exist, or a shared library needed
> for file or interpreter cannot be found.") it could at least say
> something like "interpreter or libs not found, try ldd for debugging".

Hm, yes, I suppose that's true.  There's a race condition when the binary
is deleted between the ENOENT failure and the subsequent check, but
apparently bash is already living with that for the shell script check.
Okay, good point.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>



Information forwarded to debian-bugs-dist@lists.debian.org, Matthias Klose <doko@debian.org>:
Bug#609882; Package bash. (Thu, 03 Jan 2013 19:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Matthias Klose <doko@debian.org>. (Thu, 03 Jan 2013 19:27:03 GMT) Full text and rfc822 format available.

Message #63 received at 609882@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Russ Allbery <rra@debian.org>
Cc: 609882@bugs.debian.org, command-not-found@packages.debian.org
Subject: Re: bash: "File does not exist" when ELF interpreter is missing
Date: Thu, 3 Jan 2013 11:21:39 -0800
# complex
severity 609882 wishlist
reassign 609882 command-not-found 0.2.38-1
quit

Russ Allbery wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:

>> I suppose it could check if the file exists itself, or it could always
>> use a message like "File or interpreter does not exist".
[...]
>                      (Although I'm inclined to agree with the original
> reassignment of the bug: this sort of magic seems like what
> command-not-found is for.)

Yes, agreed.

At least I think that's the right place to experiment.  In the long
run, there's precedent for including this kind of thing in bash, as
Stefano mentioned:

| shell_execve (execute_cmd.c) does check for missing interpretors for
| scripts (with shebangs) but not for ELFs
|
| $ cat > testscript
| #!/bin/foobarbaz
| $ chmod +x testscript 
| $ testscript 
| bash: ./testscript: /bin/foobarbaz: bad interpreter: No such file or directory

Thanks for your thoughtfulness.
Jonathan



Severity set to 'wishlist' from 'normal' Request was from Jonathan Nieder <jrnieder@gmail.com> to control@bugs.debian.org. (Thu, 03 Jan 2013 19:27:07 GMT) Full text and rfc822 format available.

Bug reassigned from package 'bash' to 'command-not-found'. Request was from Jonathan Nieder <jrnieder@gmail.com> to control@bugs.debian.org. (Thu, 03 Jan 2013 19:27:08 GMT) Full text and rfc822 format available.

Marked as found in versions command-not-found/0.2.38-1. Request was from Jonathan Nieder <jrnieder@gmail.com> to control@bugs.debian.org. (Thu, 03 Jan 2013 19:27:09 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Julian Andres Klode <jak@debian.org>:
Bug#609882; Package command-not-found. (Thu, 03 Jan 2013 20:24:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andrey Rahmatullin <wrar@wrar.name>:
Extra info received and forwarded to list. Copy sent to Julian Andres Klode <jak@debian.org>. (Thu, 03 Jan 2013 20:24:09 GMT) Full text and rfc822 format available.

Message #74 received at 609882@bugs.debian.org (full text, mbox):

From: Andrey Rahmatullin <wrar@wrar.name>
To: debian-devel@lists.debian.org, 609882@bugs.debian.org
Subject: Re: Bug#697270: PC 32-bit programs fails to work on amd64
Date: Fri, 4 Jan 2013 02:17:20 +0600
[Message part 1 (text/plain, inline)]
On Thu, Jan 03, 2013 at 10:26:46AM -0800, Russ Allbery wrote:
> >>> Debian clearly says: "File does not exist", while in fact it DOES EXIST.
> >>> This is a 100% proof of Debian bug.
> 
> > I guess it is bash telling you that.
> 
> >> That's the error message that you get when the dynamic loader for a
> >> binary doesn't exist.  I think that's been the case for as long as
> >> Linux has existed.
> 
> > That's already reported as bug #609882.
> 
> I think that's asking quite a lot of bash.  Wouldn't it have to open the
> binary and parse the ELF headers, extracting the INTERP header, in order
> to verify that?  Does it really make sense to encode understanding of ELF
> binary layout formats in bash?
This was discussed on Dec 26 on #-devel, a Fedora patch
(http://pkgs.fedoraproject.org/cgit/bash.git/tree/bash-2.05a-interpreter.patch)
was mentioned. Yes, it parses ELF headers.

-- 
WBR, wRAR
[signature.asc (application/pgp-signature, inline)]

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Fri Apr 18 13:43:38 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.