On Tue, Mar 13, 2018 at 10:29:22PM -0600, Eduardo Bustamante wrote: > On Tue, Mar 13, 2018 at 7:24 PM, Vladimir Likic <v.li...@gmail.com> 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.
