bug-bash
[Top][All Lists]
Advanced

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

Re: Strange/incorrect behavior of a fake executable file


From: Greg Wooledge
Subject: Re: Strange/incorrect behavior of a fake executable file
Date: Wed, 14 Mar 2018 08:43:45 -0400
User-agent: NeoMutt/20170113 (1.7.2)

On Tue, Mar 13, 2018 at 10:29:22PM -0600, Eduardo Bustamante wrote:
> On Tue, Mar 13, 2018 at 7:24 PM, Vladimir Likic <address@hidden> wrote:
> > Repeat-By:
> >
> > $ echo junk > junk
> > $ chmod +x junk
> > $./junk
> > --> this completely destroys my system

Only if you have "." in your $PATH (or a function named junk that
recurses into itself, etc.).

You've written a program that recursively calls itself by name, but
only if that name can be found in a directory that is in your $PATH.

This is ONE of the reasons why you should never put "." into your $PATH.
Which in turn is why you need to write "./junk" to run a program in the
current directory instead of just "junk".

You have included "." in your $PATH (or you are doing this in ~/bin or
/usr/local/bin or something).  Now "junk" works to invoke the program,
and you get the infinite recursion which brings your system to its knees.

> Uh, what do you mean by that? And how is this a bash bug?
> 
> A few points:
> 
> 1) You do not provide a hash-bang (i.e. #!/bin/bash), which means that
> /bin/sh will be used (

No, that's incorrect.  When bash tells the operating system to run
this program, the operating system will return ENOEXEC (Exec format
error).  Bash (and every other shell) will catch this and spawn a
child copy of itself to try to interpret the program as a script.

So, in the absence of a shebang, the file is interpreted as a command
script by whatever shell the user happens to be using at the time.

> 2) You are using Debian apparently. /bin/sh in Debian is dash, not bash
> 3) What's the value of PATH? (I'm guessing you have an empty entry or
> '.' in there, and therefore, the script calls itself recursively).
> It's not good practice to have the current working directory in your
> PATH, so, fix that.

The smart money is definitely on ". or '' in $PATH".  The only other
option I see is that the user was working inside a directory that is
in $PATH (~/bin or /usr/local/bin or whatever).  Too bad he didn't
use a PS1 that shows $PWD in his example.



reply via email to

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