How to avoid having shell scripts which fail from killing Emacs shell?

How to avoid having shell scripts which fail from killing Emacs shell?

[David Karr]

I've often been annoyed by shell scripts which fail for particular
reasons, at which point it causes my Emacs shell buffer to get killed,
with "Process shell<2> finished".  I think it's possible I could code
the script to make this not happen, but it would make more sense
(especially when I didn't write the script) to configure Emacs or the
Bash inside Emacs, so that it doesn't get killed when a script it's
running fails.

What are my options for mitigating this?

Re: How to avoid having shell scripts which fail from killing Emacs shell?

[David Karr]

On Jun 19, 4:03 pm, David Karr <davidmichaelk...@gmail.com> wrote:
> I've often been annoyed by shell scripts which fail for particular
> reasons, at which point it causes my Emacs shell buffer to get killed,
> with "Process shell<2> finished".  I think it's possible I could code
> the script to make this not happen, but it would make more sense
> (especially when I didn't write the script) to configure Emacs or the
> Bash inside Emacs, so that it doesn't get killed when a script it's
> running fails.
>
> What are my options for mitigating this?

If it matters, note that I'm using Cygwin, and the Emacs built for
Cygwin.

Re: How to avoid having shell scripts which fail from killing Emacs shell?

[David Combs]

>
>If it matters, note that I'm using Cygwin, and the Emacs built for
>Cygwin.

Try NTEMACS.  Beats the hell out of that cygwin one!  (Full screen,
this, that, etc -- just like "at home"!)

I do believe you will like it, and NEVER go back.


David

Re: How to avoid having shell scripts which fail from killing Emacs shell?

[Peter Dyballa]

Am 20.06.2009 um 01:03 schrieb David Karr:

> to configure Emacs or the Bash inside Emacs, so that it doesn't get  
> killed when a script it's running fails.


Make the shell script trap (shell built-in) this catastrophic error  
and just execute an exit (shell built-in) instead (in last millennium  
this was standard). You can also run shell scripts asynchronously in  
a dedicated temporary buffer by executing it as a shell or compile  
command.


I'm not the bash guru (tcsh user), and its manual page is very long  
for reading it. I remember there is a section about SIGNALs. It  
should give some basic clues.

--
Greetings

   Pete                                           0
                                            %-/\_//
                                             (*)(*)

Re: How to avoid having shell scripts which fail from killing Emacs shell?

[David Karr]

On Jun 20, 2:06 am, Peter Dyballa <Peter_Dyba...@Web.DE> wrote:
> Am 20.06.2009 um 01:03 schrieb David Karr:
>
> > to configure Emacs or the Bash inside Emacs, so that it doesn't get  
> > killed when a script it's running fails.
>
> Make the shell script trap (shell built-in) this catastrophic error  
> and just execute an exit (shell built-in) instead (in last millennium  
> this was standard). You can also run shell scripts asynchronously in  
> a dedicated temporary buffer by executing it as a shell or compile  
> command.

If it matters, changing my test script to use "trap" to just exit on a
signal didn't make any difference.

Re: How to avoid having shell scripts which fail from killing Emacs shell?

[Peter Dyballa]

Am 22.06.2009 um 18:43 schrieb David Karr:

> If it matters, changing my test script to use "trap" to just exit on a
> signal didn't make any difference.


Then your bash must be broken. Or you have in a terminal emulator a  
different environment than in GNU Emacs. As mentioned you can adjust  
both environments by means of ~/.emacs_bash.

You could also check which bash RC files are executed by bash shell  
in terminal emulator and in GNU Emacs.

--
Greetings

   Pete

America believes in education: the average professor earns more money  
in a year than a professional athlete earns in a whole week.
				– Evan Esar

Re: How to avoid having shell scripts which fail from killing Emacs shell?

[Pascal J. Bourguignon]

David Karr <davidmichaelkarr@gmail.com> writes:

> On Jun 20, 2:06 am, Peter Dyballa <Peter_Dyba...@Web.DE> wrote:
>> Am 20.06.2009 um 01:03 schrieb David Karr:
>>
>> > to configure Emacs or the Bash inside Emacs, so that it doesn't get  
>> > killed when a script it's running fails.
>>
>> Make the shell script trap (shell built-in) this catastrophic error  
>> and just execute an exit (shell built-in) instead (in last millennium  
>> this was standard). You can also run shell scripts asynchronously in  
>> a dedicated temporary buffer by executing it as a shell or compile  
>> command.
>
> If it matters, changing my test script to use "trap" to just exit on a
> signal didn't make any difference.

Probably your "script" is not a script but a text file containing
shell commands that you source.

The trick to avoid having it kill your shell, is to have it run in its
own shell (which it is free to kill).  To do so, you must put:

#!/bin/bash

on the first line of the "script", and you should change the access
rights to give it executable rights:

chmod +x script


Then you can launch it as:

./script

instead of 

. script # or source script


When you launch it like this, the kernel notice the #! characters at
the beginning of the file, and therefore forks a process running
/bin/bash, which will execute the rest of the script.  When that
script exits or kills itself, it only kills the bash launched by the
kernel, and not the bash running in emacs.


-- 
__Pascal Bourguignon__

Re: How to avoid having shell scripts which fail from killing Emacs shell?

[David M. Karr]

Pascal J. Bourguignon wrote:
> David Karr <davidmichaelkarr@gmail.com> writes:
> 
>> On Jun 20, 2:06 am, Peter Dyballa <Peter_Dyba...@Web.DE> wrote:
>>> Am 20.06.2009 um 01:03 schrieb David Karr:
>>>
>>>> to configure Emacs or the Bash inside Emacs, so that it doesn't get  
>>>> killed when a script it's running fails.
>>> Make the shell script trap (shell built-in) this catastrophic error  
>>> and just execute an exit (shell built-in) instead (in last millennium  
>>> this was standard). You can also run shell scripts asynchronously in  
>>> a dedicated temporary buffer by executing it as a shell or compile  
>>> command.
>> If it matters, changing my test script to use "trap" to just exit on a
>> signal didn't make any difference.
> 
> Probably your "script" is not a script but a text file containing
> shell commands that you source.
> 
> The trick to avoid having it kill your shell, is to have it run in its
> own shell (which it is free to kill).  To do so, you must put:
> 
> #!/bin/bash

That's not the problem.  It's a proper script and executable.

I've managed to find an element of this that seems to cause the problem, 
and removing that component makes it not happen.

Currently, my test class also reads a line of input from stdin, in 
addition to some command-line arguments.  I tried creating a dummy test 
class that doesn't read from stdin, even when I force it to throw an 
exception, and that doesn't kill the shell.  However, when I then change 
the class to read a line from stdin, whether it throws an exception or 
not, the shell dies after the script completes.  I imagine I could 
simplify this test case by just doing the readline from the script, 
instead of the class.  I'll try that a little later this morning.

Re: How to avoid having shell scripts which fail from killing Emacs shell?

[Peter Dyballa]

Am 23.06.2009 um 15:15 schrieb David M. Karr:

> I tried creating a dummy test class that doesn't read from stdin,  
> even when I force it to throw an exception, and that doesn't kill  
> the shell.  However, when I then change the class to read a line  
> from stdin, whether it throws an exception or not, the shell dies  
> after the script completes.

Can it be that you just use the wrong Java routine to read input?

> I imagine I could simplify this test case by just doing the  
> readline from the script, instead of the class.


Is the mix of shell and Java code necessary to set CLASSPATH or is  
its purpose wider? In the latter case, have you thought of making the  
Java code external and compiling it and then using that Java  
executable file in your script?

--
Greetings

   Pete

Who the fsck is "General Failure," and why is he reading my disk?

Re: How to avoid having shell scripts which fail from killing Emacs shell?

[David Karr]

On Jun 23, 6:15 am, "David M. Karr" <davidmichaelk...@gmail.com>
wrote:
> Pascal J. Bourguignon wrote:
> > David Karr <davidmichaelk...@gmail.com> writes:
>
> >> On Jun 20, 2:06 am, Peter Dyballa <Peter_Dyba...@Web.DE> wrote:
> >>> Am 20.06.2009 um 01:03 schrieb David Karr:
>
> >>>> to configure Emacs or the Bash inside Emacs, so that it doesn't get  
> >>>> killed when a script it's running fails.
> >>> Make the shell script trap (shell built-in) this catastrophic error  
> >>> and just execute an exit (shell built-in) instead (in last millennium  
> >>> this was standard). You can also run shell scripts asynchronously in  
> >>> a dedicated temporary buffer by executing it as a shell or compile  
> >>> command.
> >> If it matters, changing my test script to use "trap" to just exit on a
> >> signal didn't make any difference.
>
> > Probably your "script" is not a script but a text file containing
> > shell commands that you source.
>
> > The trick to avoid having it kill your shell, is to have it run in its
> > own shell (which it is free to kill).  To do so, you must put:
>
> > #!/bin/bash
>
> That's not the problem.  It's a proper script and executable.
>
> I've managed to find an element of this that seems to cause the problem,
> and removing that component makes it not happen.
>
> Currently, my test class also reads a line of input from stdin, in
> addition to some command-line arguments.  I tried creating a dummy test
> class that doesn't read from stdin, even when I force it to throw an
> exception, and that doesn't kill the shell.  However, when I then change
> the class to read a line from stdin, whether it throws an exception or
> not, the shell dies after the script completes.  I imagine I could
> simplify this test case by just doing the readline from the script,
> instead of the class.  I'll try that a little later this morning.

I didn't get a chance to run a test on Unix/Linux, but I tried
changing my script to just do a "read" with a prompt.  When I run
this, it does not kill the shell at the end of the script.  When I
change it back to do the same thing from Java, it kills the shell at
the end of the script.  Very odd.

Note that I'm specifically stating "at the end of the script". If I
put a print statement in the script after the call to Java, it prints
the line, finishes the script, then kills the shell.

Re: How to avoid having shell scripts which fail from killing Emacs shell?

[Peter Dyballa]

Am 23.06.2009 um 17:06 schrieb David Karr:

> Note that I'm specifically stating "at the end of the script". If I
> put a print statement in the script after the call to Java, it prints
> the line, finishes the script, then kills the shell.

Can you give us a sketch of your script, like:

	#!/bin/bash
	<some variable settings>
	pushd <some working directory>
	# here the Java code starts with:
		<a cup of hot Java?>
	# the Java function to read:
	...
	# Here the Java code ends:
	<code>
	<shell code>
	# Final statement:
	...
	<shell script ends here with a newline>

Actual lines and line numbers (shell-command-on-region with pr -n - 
l9999) won't be bad. Maybe it's possible from seeing the code to see  
a design flaw or the actual cause ... Could be a log from your  
*shell* can provide further information.

You can also invoke your script as

	bash -x ./script.name

or put a line

	set -x

near the beginning (line #2ff) into it to see bash execute the lines.  
This might give additional insight.

--
Greetings

   Pete

Upgraded, adj.:
	Didn't work the first time.

Re: How to avoid having shell scripts which fail from killing Emacs shell?

[David Karr]

On Jun 19, 4:03 pm, David Karr <davidmichaelk...@gmail.com> wrote:
> I've often been annoyed by shell scripts which fail for particular
> reasons, at which point it causes my Emacs shell buffer to get killed,
> with "Process shell<2> finished".  I think it's possible I could code
> the script to make this not happen, but it would make more sense
> (especially when I didn't write the script) to configure Emacs or the
> Bash inside Emacs, so that it doesn't get killed when a script it's
> running fails.
>
> What are my options for mitigating this?

For a little more background, note that the script in question gathers
some simple parameters and then calls a Java class, which in my test
case, throws an exception because I'm giving it a file path that
doesn't exist (deliberately).

I note that even though the Java class throws an exception, it doesn't
cause the script to exit at that point. I tried putting an "echo"
right after the Java call, and it executes fine.  Right after that (as
it's the last line in the script), the script exits, and at my shell
prompt, I see "% exit" (where "%" is my PS1), and my shell buffer
terminates.

Re: How to avoid having shell scripts which fail from killing Emacs shell?

[Peter Dyballa]

Am 22.06.2009 um 22:21 schrieb David Karr:

> I note that even though the Java class throws an exception, it doesn't
> cause the script to exit at that point. I tried putting an "echo"
> right after the Java call, and it executes fine.  Right after that (as
> it's the last line in the script), the script exits, and at my shell
> prompt, I see "% exit" (where "%" is my PS1), and my shell buffer
> terminates.

Could you try it with other shells, too? You still have no proof that  
your bash is *not* broken. And, for another series of tests, you  
could try the same in another account. And particularly when  
launching GNU Emacs without customisation ...

Besides this, the bash in *shell* buffer can be initialised  
differently than in an xterm. Bash is complicated.


OK, I do remember similiar events! It was in tcsh. And there were two  
or three problems: a script was running wild, I was typing C-c or  
such wildly, and ... well, it could have been in cpan (filling up my  
root and boot file system). Anyway, in the end I saw the shell die,  
and at this moment it's not possible to gain more information. There  
were also events outside cpan. I do remember that I made mistakes,  
typing C-d for example. There could be one plausible cause: when you  
type input and your script is not prepared to read this, then GNU  
Emacs has to save it. Maybe this period is limited. And then  
something irregular could happen. I have no real idea, but what you  
encounter is not impossible. (And maybe Cygwin adds something to make  
it happen, it's an emulation in a host operating system.)

There is no chance to make the tests in a real UNIX environment?

--
Greetings

   Pete

Indentation?! I will show you how to indent when I indent your skull!

Re: How to avoid having shell scripts which fail from killing Emacs shell?

[David Karr]

On Jun 22, 3:49 pm, Peter Dyballa <Peter_Dyba...@Web.DE> wrote:
> Am 22.06.2009 um 22:21 schrieb David Karr:
>
> > I note that even though the Java class throws an exception, it doesn't
> > cause the script to exit at that point. I tried putting an "echo"
> > right after the Java call, and it executes fine.  Right after that (as
> > it's the last line in the script), the script exits, and at my shell
> > prompt, I see "% exit" (where "%" is my PS1), and my shell buffer
> > terminates.
>
> Could you try it with other shells, too? You still have no proof that  
> your bash is *not* broken. And, for another series of tests, you  
> could try the same in another account. And particularly when  
> launching GNU Emacs without customisation ...
>
> Besides this, the bash in *shell* buffer can be initialised  
> differently than in an xterm. Bash is complicated.
>
> OK, I do remember similiar events! It was in tcsh. And there were two  
> or three problems: a script was running wild, I was typing C-c or  
> such wildly, and ... well, it could have been in cpan (filling up my  
> root and boot file system). Anyway, in the end I saw the shell die,  
> and at this moment it's not possible to gain more information. There  
> were also events outside cpan. I do remember that I made mistakes,  
> typing C-d for example. There could be one plausible cause: when you  
> type input and your script is not prepared to read this, then GNU  
> Emacs has to save it. Maybe this period is limited. And then  
> something irregular could happen. I have no real idea, but what you  
> encounter is not impossible. (And maybe Cygwin adds something to make  
> it happen, it's an emulation in a host operating system.)
>
> There is no chance to make the tests in a real UNIX environment?

My current test case has the Java class taking a line of input from
stdin.  I guess I'll build an experimental class that takes the file
name from the command line parameter instead of stdin, and test that
on both Cygwin and Linux.

Re: How to avoid having shell scripts which fail from killing Emacs shell?

[David Karr]

On Jun 22, 3:49 pm, Peter Dyballa <Peter_Dyba...@Web.DE> wrote:
> Am 22.06.2009 um 22:21 schrieb David Karr:
>
> > I note that even though the Java class throws an exception, it doesn't
> > cause the script to exit at that point. I tried putting an "echo"
> > right after the Java call, and it executes fine.  Right after that (as
> > it's the last line in the script), the script exits, and at my shell
> > prompt, I see "% exit" (where "%" is my PS1), and my shell buffer
> > terminates.
>
> OK, I do remember similiar events! It was in tcsh. And there were two  
> or three problems: a script was running wild, I was typing C-c or  
> such wildly, and ... well, it could have been in cpan (filling up my  
> root and boot file system). Anyway, in the end I saw the shell die,  
> and at this moment it's not possible to gain more information. There  
> were also events outside cpan. I do remember that I made mistakes,  
> typing C-d for example. There could be one plausible cause: when you  
> type input and your script is not prepared to read this, then GNU  
> Emacs has to save it. Maybe this period is limited. And then  
> something irregular could happen. I have no real idea, but what you  
> encounter is not impossible. (And maybe Cygwin adds something to make  
> it happen, it's an emulation in a host operating system.)

Well, this did give me one idea that gave me a clue, but I don't know
what to do with this clue.

I tried writing a simple class that takes a command-line arg as a
filepath.  I get it to throw an exception, but it doesn't kill the
shell.

I then changed the class to additionally read a line of text from
stdin, in addition to taking the filepath.  When I test this, whether
the command-line file path exists or not, it still kills the shell at
the end of the script.  So, the key is that the sub-shell reads
input.  I have no idea what to do with that information, but I'm sure
it's a useful clue.