[SOLVED] exit in script files cause konsole terminal itself to exit
ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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.
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).
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:
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?
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.
Last edited by catkin; 04-12-2010 at 05:28 AM.
Reason: exist -> exits
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.
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.
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.
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.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.