LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Programming (https://www.linuxquestions.org/questions/programming-9/)
-   -   exit in script files cause konsole terminal itself to exit (https://www.linuxquestions.org/questions/programming-9/exit-in-script-files-cause-konsole-terminal-itself-to-exit-801423/)

Star_Gazer 04-11-2010 04:44 PM

exit in script files cause konsole terminal itself to exit
 
I noticed that if I have "exit" in a bash script file., e.g.
script.sh,
that when the word "exit" is reached, and the script file being executed is not in the PATH environment, i.e.
". script.sh",
the whole konsole shell profile is exited! What gives here? Is there another command compatible to "exit" to prevent this, or will I just have the leave the "." part in the PATH enviroment, which is, to my understanding, is not recommended? I desire for a "goto" function in bash script files. :study:

Thanks,
Clifton

GazL 04-11-2010 04:54 PM

It's because your sourcing. You should be starting it with:
./script.sh

(no space between the . and the slash)

Star_Gazer 04-11-2010 06:04 PM

Quote:

Originally Posted by GazL (Post 3932218)
It's because your sourcing. You should be starting it with:
./script.sh

(no space between the . and the slash)

Thanks. As I recall, I attempted that method, and got the same problem. I am using openSUSE 11.2 KDE 4.42, Konsole version 2.42, if that means anything.

Clifton

JohnGraham 04-11-2010 06:40 PM

Quote:

Originally Posted by Star_Gazer (Post 3932267)
Thanks. As I recall, I attempted that method, and got the same problem.

Have you tried it again, to be sure? A call to exit closing your terminal session is exactly what you'd expect from sourcing with ". script.sh", and if this isn't cured by using "./script.sh", that's a major problem.

If you try the alternate method and it doesn't work, please post the offending script (or, preferably, a minimal example that demonstrates the same behaviour).

Star_Gazer 04-11-2010 07:05 PM

Quote:

Originally Posted by JohnGraham (Post 3932282)
Have you tried it again, to be sure? A call to exit closing your terminal session is exactly what you'd expect from sourcing with ". script.sh", and if this isn't cured by using "./script.sh", that's a major problem.

If you try the alternate method and it doesn't work, please post the offending script (or, preferably, a minimal example that demonstrates the same behaviour).

I took the ":." out of the PATH variable to test the script file again, and got this:
Code:

/media/drawers/practice/awkgrepsed $ ./log_gets.sh
bash: ./log_gets.sh: Permission denied
/media/drawers/practice/awkgrepsed $

That is strange, because the file is executable (-rwxr-xr-x). This is just a practice script file for educating myself. It is small. Here it is:

Code:

#!/bin/bash
if [ -z $1 ]; then
        echo "ERROR!"
        echo "You must specify valid file specs."
        echo "e.g. $(basename $0) ex100409.log ..."
        echo ""
        sleep 2
        exit 1
else
        LOGFILNAM=$1
fi

if [ -n $LOGFILNAM ]; then
grep -o -h -E 'GET /.+\.html? \W+ ' $LOGFILNAM | sed 's/GET //1' | sed 's/ \-//g' | sort
fi

But I just put the ':." part back into the PATH environment, and still get the same problems as noted above. Maybe it is the settings for the drive in the fstab?

Thanks,
Clifton

Star_Gazer 04-11-2010 07:15 PM

Fascinating... I moved the files to the ~/Documents/Practice directory, and
Code:

./log_gets.sh
log_gets.sh

work fine, yet:
Code:

. log_gets.sh
does not. It exits Konsole. I have been using Linux since May of last year, and haven't encounter these pecularities.

Clifton

catkin 04-11-2010 11:22 PM

Quote:

Originally Posted by Star_Gazer (Post 3932303)
Fascinating... I moved the files to the ~/Documents/Practice directory, and
Code:

./log_gets.sh
log_gets.sh

work fine, yet:
Code:

. log_gets.sh
does not. It exits Konsole.

That is normal. The first case runs the script in a sub-shell and its "exit" exits the sub-shell returning you to the first shell. The second case runs the script it your current shell and its exit does the same a typing exit at the command prompt -- it terminates the shell.

Are you clear about the difference between ./log_gets.sh and . log_gets.sh? They are very different.

GazL 04-12-2010 04:09 AM

The filesystem containing /media/drawers/practice/awkgrepsed may have been mounted with the noexec option, That would explain why you get permission denied even when it's marked executable and works when moved elsewhere.

Star_Gazer 04-12-2010 07:04 AM

Quote:

Originally Posted by catkin (Post 3932426)
That is normal. The first case runs the script in a sub-shell and its "exit" exits the sub-shell returning you to the first shell. The second case runs the script it your current shell and its exit does the same a typing exit at the command prompt -- it terminates the shell.

Ah, I see. I'll have to remember that. That makes good sense, especially if one is executing a script outside the shell (i.e. clicking on the filename in Dolphin, Konqueror, or Krusader).

Quote:

Are you clear about the difference between ./log_gets.sh and . log_gets.sh? They are very different.
Not really. All I remember is that "if the file to execute is not in a directory listed in the PATH environment variable, use ". command" when in such a directory.

Thanks.
Clifton

Star_Gazer 04-12-2010 07:08 AM

Quote:

Originally Posted by GazL (Post 3932621)
The filesystem containing /media/drawers/practice/awkgrepsed may have been mounted with the noexec option, That would explain why you get permission denied even when it's marked executable and works when moved elsewhere.

Yes... I thought the same. That drive does have the 'noexec' option in it.

Thanks,
Clifton

catkin 04-12-2010 08:05 AM

Quote:

Originally Posted by Star_Gazer (Post 3932761)
All I remember is that "if the file to execute is not in a directory listed in the PATH environment variable, use ". command" when in such a directory.

That's not correct; use ./command in that situation. The "." command is something different; it runs the commands in a script file within the current shell; it's useful for setting variables and defining aliases and functions; if the same script were run as ./command then all those settings would happen in a subshell and be lost when the subshell terminated.

Star_Gazer 04-12-2010 08:32 AM

Quote:

Originally Posted by catkin (Post 3932830)
That's not correct; use ./command in that situation. The "." command is something different; it runs the commands in a script file within the current shell; it's useful for setting variables and defining aliases and functions; if the same script were run as ./command then all those settings would happen in a subshell and be lost when the subshell terminated.

I understand better now - thank you.

Clifton


All times are GMT -5. The time now is 09:46 PM.