Comment 1 Ewa Matejska 2006-09-26 12:45:12 EDT

Hi,

I've documented this as a limitation in the plugin (org.eclipse.rse.remotecdt/instructions.txt).  The problem is that I have no way to detect that the user command in the remote shell has completed. From what I can tell, I can only open a remote shell, and pass commands to it.  I cannot just run one command to completion on the remote target.

I can hack it for the debug case to terminate when I detect that the gdb connection has terminated but I have no way to know for the run case that the user program has stopped running.

For now I think this should be marked as a limitation. I will file a bug against the RSE APIs and fix this later when that bug is resolved. 

Thanks.

Comment 2 Martin Oberhuber 2006-09-26 12:57:10 EDT

DaveM... I'm wondering whether Ewa could to this:
 * Start the debuggee with "exec" --> replace the Shell process by the Debuggee
 * Listen to the Output and Error Streams
 * If the Streams are closed, the debuggee has terminated

I believe that's how the RSE command view detects that the remote shell has terminated - when user types "exit" the command view is marked as "terminated".

Another option would be to call the debuggee like this:
  $command ; exit
Such that the shell runs the debuggee command, and as soon as the debuggee command is finished, it performs an "exit", leading the output and error streams to close.

Ideas or Comments?

Comment 3 Ewa Matejska 2006-09-26 13:04:39 EDT

Is "exit" a command that is recognized by every kind of shell subsystem?  I can give this method a try very easily.

Comment 4 David McKnight 2006-09-26 15:09:50 EDT

The "$command ; exit" approach might work.  See what happens with that.

Comment 5 Martin Oberhuber 2006-09-27 04:17:38 EDT

All the shells I know of have an "exit" command:
Bourne sh, ksh, csh, tcsh, zsh, bash, and cmd.

The only difference is that Unixy flavors of shells use ";" as separator while Windows cmd uses "&" as separator. But there's a method on the 
    IRemoteCmdSubSystem.getCommandSeparator()
which returns exactly the separator to use.

Since the "Universal" subsystems that we are dealing with are kind of Unix Flavor anyways, I think we should be OK with the limitation. Moreover, in case a remote shell should not support the "exit" command, the worst thing that can happen is that the shell remains open... which doesnt seem too bad.

Comment 6 Lothar Werzinger 2006-10-18 14:12:36 EDT

I try to write a custom launcher for us using RSE and I have the same problem. The shell stays open and if I close it manually I get the following error:

Error logged from Debug Core: 
java.io.IOException: Pipe broken
        at java.io.PipedInputStream.read(PipedInputStream.java:255)
        at java.io.PipedInputStream.read(PipedInputStream.java:305)
        at java.io.BufferedInputStream.read1(BufferedInputStream.java:254)
        at java.io.BufferedInputStream.read(BufferedInputStream.java:313)
        at java.io.FilterInputStream.read(FilterInputStream.java:90)
        at 
org.eclipse.debug.internal.core.OutputStreamMonitor.read(OutputStreamMonitor.java:138)
        at org.eclipse.debug.internal.core.OutputStreamMonitor.access$1
(OutputStreamMonitor.java:128)
        at 
org.eclipse.debug.internal.core.OutputStreamMonitor$1.run(OutputStreamMonitor.java:194)
        at java.lang.Thread.run(Thread.java:595)


This is a code snippet of what I tried. I tried both methods (launchShell+writeToShell and 
runCommand). The workaround with coomad + ";exit" fails completely with runCommand and with launchShell+writeToShell I still get the error with the exception above.

This workaround would not work for me (in our final product), as I do not want to expose that kind of error to the user.


        IShellService shellService = (IShellService) 
getConnectedRemoteService(
            configuration, SHELL_SERVICE);
        
        String [] environment = new String[2];
        environment[0] = "AAA=BBB";
        environment[1] = "ZZZ=YYY";
        String initialWorkingDirectory = "";
        String command = "ls";
        
//        IHostShell hostShell = shellService.launchShell(monitor, 
initialWorkingDirectory, environment);
//        hostShell.writeToShell(command);
        IHostShell hostShell = shellService.runCommand(monitor, 
initialWorkingDirectory, command, environment);
        
        try
        {
          remoteProcess = new HostShellAdapter(hostShell);
        }
        catch (Exception e)
        {
          if (remoteProcess != null)
          {
            remoteProcess.destroy();
          }
          throw new CoreException(
              new Status(
                  IStatus.ERROR,
                  DebugPlugin.PLUGIN_ID,
                  IStatus.OK,
                  Messages
                      .getString("EngineLaunchConfigurationDelegate.createprocessfailed"), //$NON-NLS-1$
                  null));
        }
        
        IProcess process = 
org.eclipse.debug.core.DebugPlugin.newProcess(launch, remoteProcess, "just a 
test");

Comment 7 Lothar Werzinger 2006-10-18 15:11:30 EDT

I changed the HostShellAdapter so that I get prints in the destroy() and exitValue() calls like this:

	public synchronized void destroy() {
    System.out.println("destroy()");
		hostShell.exit();
    System.out.println("after exit()");
		notifyAll();
		try {
			inputStream.close();
			errorStream.close();
			outputStream.close();
		} catch (IOException e) {
			// Ignore
		}	
	}

	public int exitValue() {
    boolean isActive = hostShell.isActive();
    System.out.println("isActive=" + isActive);
		if(isActive)
			throw new IllegalThreadStateException();
		// No way to tell what the exit value was.
		return 0;
	}

This is what I get when I call the shell with "ls;exit":
The java.io.IOException is due to the fact that the shell already has called exit.
What's strange however is that the shell claims still that it's active. And then I get a "Terminate failed" messagebox.

destroy()
java.io.IOException: Broken pipe
after exit()
isActive=true
isActive=true
isActive=true
isActive=true
isActive=true
isActive=true
isActive=true
isActive=true
isActive=true
isActive=true
isActive=true

Comment 8 Lothar Werzinger 2006-10-18 15:27:39 EDT

I forgot to say that I tried to use the Local connection on a Linux machine. I did not try any real remote connection, as it doesn't even work with Local.

Comment 9 Lothar Werzinger 2006-10-18 16:22:12 EDT

I tried now with a ssh connection to my local machine and this is what I get:
The shell executes exit (logout), but the process is still shown as running.
If I terminate I get the following log:
isActive=true
destroy()
after exit()
isActive=false
isActive=false

So the remote shell reports isActive correctly (only Local does it wrong)
But even with the "command;exit" workaround the eclipse process does not terminate automatically.

What can I do to get the process terminated one the command exits?

Comment 10 Lothar Werzinger 2006-10-18 16:50:05 EDT

shellService.runCommand does not work with ssh; it works with Local though. I tried it also with WindowsXP (dstore) and it works there, too. Just the output is a bit funny

DataElement 
{
	Type:	command
	Name:	dir
	Value:	dir
	ID:	826407830
	Source:	
	Depth:	2
	DataStore:	172.16.92.128
}

DataElement 
{
	Type:	stdout
	Name:	
	Value:	
	ID:	-1734739135
	Source:	
	Depth:	2
	DataStore:	172.16.92.128
}

DataElement 
{
	Type:	stdout
	Name:	 Volume in drive C has no label.
	Value:	 Volume in drive C has no label.
	ID:	1348701698
	Source:	
	Depth:	2
	DataStore:	172.16.92.128
}
...

Should I open a separate bug for that?

Comment 11 Ewa Matejska 2006-10-20 04:42:27 EDT

Hi,

I'm attaching a patch for this bug.

I had the same problem where the terminal shell was not exiting with the ssh connection even with the exit command.  To fix this I had to modify HostShellAdapter as described in the patch.  The problem was the that the waitForExit was not polling the isActive command because of course in the past it would always be active without the exit command.  With the patch, the remote shell process. exits when the process exits.

Regarding your problems with the runCommand sometimes being implemented,  that's a bug with the RSE API's.  It should be filed as a separate bug.

Regarding the exception you're seeing with the Local connection,  I've never seen this but I'll give it a try.

Regarding the weird output from the dstore connection, yes please file a bug.  I have the same problem with the Remote C/C++ Launcher. At least maybe the implementor can justify why it has to look like that.

Thank You,
Ewa

Comment 12 Ewa Matejska 2006-10-20 04:48:49 EDT

Reopening untim Martin merges the patch.

Comment 13 Lothar Werzinger 2006-10-20 13:33:55 EDT

Thanks Ewa, I'll try it as soon as it get's available.

By the way, would it be possible to move the HostShellAdapter into another rse package? I did copy it into my project, as I don't want a dependency to CDT.

I will open new bugs for the weird output from the dstore connection and the runCommand sometimes being implemented.

Comment 14 Martin Oberhuber 2006-10-20 15:58:18 EDT

Created attachment 52422 [details]
Patch to close the Remote Shell process.

Moving Ewa's patch from bug 158788 where it had accidentally been stored to the right bug

Comment 15 Ewa Matejska 2006-10-20 16:03:16 EDT

Whoops...I had a late night last night.  Thanks for catching that Martin.

Comment 16 Martin Oberhuber 2006-10-20 16:18:09 EDT

(In reply to comment #13)
> By the way, would it be possible to move the HostShellAdapter into another rse
> package? I did copy it into my project, as I don't want a dependency to CDT.

Applied the patch, it should be in RSE 1.0 RC2.
Marking this bug fixed, since the other observations are tracked separately:

Bug 161770 (runCommand fails with ssh)
Bug 161773 (strange output with dstore)
Bug 161777 (move HostShellOutputAdapter)

Comment 17 Lothar Werzinger 2006-10-21 11:24:41 EDT

I can confirm that the fix works for SSH, Windows dstore in RSE 1.0RC2.
Local still fails, due to the isActive problem described in comment 7.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=158786#c7

I'm going to open a seperate bug for that problem.

Comment 18 Martin Oberhuber 2006-10-23 01:06:08 EDT

Thanks.

If you verify a bug, feel free to set status "VERIFIED". This helps us to know that a user (reporter) actually verified it. We will then set it CLOSED once we've verified it as well.

Comment 19 Martin Oberhuber 2006-11-23 06:53:01 EST

Closing.

Comment 20 Martin Oberhuber 2008-08-13 13:07:53 EDT

[target cleanup] 1.0 RC2 was the original target milestone for this bug