2

on this simple script

#!/bin/bash -i
trap 'echo "(ctrl+c was hit)"' INT
while true; do
    echo -n "hit Enter..";read
    echo "still on loop"
done

if I hit ctrl+c it will exit the loop

if I make it not interactive with 1st line like #!/bin/bash, it will work!

the problem is I have several scripts (run with "startup applications" stored at ~/.config/autostart) that only work properly with interactivity enabled #!/bin/bash -i, mainly because they load the .bashrc again granted by -i option.

any tips?

EDIT: I found this on the begging of my ~/.bashrc file:

# If not running interactively, don't do anything
case $- in
    *i*) ;;
      *) return;;
esac

that prevents loading that file as source in non interactive script, I didnt put it there and I dont know why it is there...

EDIT: so, as the problem is loading what is setup at ~/.bashrc, but to the script doesnt behave weirdly, I found that scripts started by "startup applications" stored at ~/.config/autostart, may be run this way:

xterm -e "bash -i -c myScript.sh"
#or
bash -i -c 'xterm -e "myScript.sh"' #this way the title looks better

so the script wont have -i option, will begin just with #!/bin/bash to behave properly, and the ~/.bashrc file will setup the environment properly also.

Jolta
  • 2,620
  • 1
  • 29
  • 42
Aquarius Power
  • 3,729
  • 5
  • 32
  • 67

2 Answers2

2

Having bash run interactively enables job control, history expansion, aliases and several other things that you probably don't want in a script, including changes to signal behavior.

If all you want is to load variables from ~/.bashrc, have you considered to just source ~/.bashrc?

that other guy
  • 116,971
  • 11
  • 170
  • 194
  • omg... I found this on the beginning of my `~/.bashrc`: `case $- in *i*) ;; *) return;; esac` with this comment: _# If not running interactively, don't do anything_, this has caused so much trouble, I only saw now... any idea why it is there and how safe is to remove it? it wont let me load the file! – Aquarius Power Jul 04 '13 at 02:15
  • indeed I dont want the script to have things that will cause problem as I read it may become unstable; what I have been experiencing several instabilities... I found this to be a "fix" `xterm -e "bash -i -c myScript.sh"` – Aquarius Power Jul 04 '13 at 03:05
  • It's probably there because you copied it from somewhere at some point. The effects of removing it obviously depend on what else is in the file. If you do some kind of trickery to automatically load `screen` or other processes that run forever and/or replace your shell, it could be a problem. It's certainly not a normal check to include though. – that other guy Jul 04 '13 at 09:33
  • as I read, it seems to have come default with ubuntu; anyway the proper solution seems to be: not to use `#!/bin/bash -i` (with `-i`) inside the script, it seems ok and safe tho to use `bash -i -c script.sh`! I updated them all and the bogus behavior I was experiencing seems gone! – Aquarius Power Jul 04 '13 at 15:03
1

From the bash man page:

When  bash  is  interactive,  in  the  absence of any traps, it ignores
SIGTERM (so that kill 0 does not kill an interactive shell), and **SIGINT**
is  caught and handled (so that the wait builtin is interruptible).

Crt-c typically sends SIGINT (the tty driver is the one that controls what crt-c does). Consequently, bash will trap SIGNT after your trap is called in interactive mode. You could try mapping crt-c within that script to some other signal and then trap that signal (maybe SIGTERM?).

dougEfresh
  • 457
  • 2
  • 8
  • I learned interactive mode for scripts may be unstable, and indeed I have been experiencing several problems after I begin using it.. I opted for this: `bash -i -c 'xterm -e "myScript.sh"'` and disabled interactive script mode, now script begins with `#!/bin/bash` – Aquarius Power Jul 04 '13 at 04:18