Community
Participate
Working Groups
IShellService.runCommand gives strange output with WindowsXP (dstore) I tested with RSE 1.0RC1. The output looks like this: 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 } ... (see also https://bugs.eclipse.org/bugs/show_bug.cgi?id=158786#c10) I don't know if this problem affects different Platform/OS, so I picked "All". Feel free to change that if necessary.
Dave can you look at this? The problem manifests in the remote cdt launcher, see also bug 158312. It might be that Ewa interprets the output from a destore IHostShell wrongly, but I'm not deep enough into dstore. I hope it's easy for you to see what's going on since you've done the IBM internal launcher. I'm setting P2 since we'd REALLY like the remotecdt launcher to work with dstore as well and this is apparently a prerequisite.
I'm not sure how's this is being used, but the DStoreShellService returns DataElements as it's output in the DStoreOutputReader rather than straight lines of text. DStoreServerCommandShell normally takes care of wrappering the elements, however that's at the subsystem layer rather than at the service layer. I suppose it would be better if the service layer took care of all that, since consumers of that should not really know about dstore-specifics but sorting that out will have to wait.
I'd be ok saying that Services may do whatever is simple to implement; and that users of a service are required to use it at the subsystem layer in order to get extra functionality. But I have looked at the DStoreServiceCommandShell and I'm finding that it's merely wrappering the DataObjects that it gets from the service into RemoteError / RemoteOutput objects. I cannot see how a client could request a stream from the DStoreServiceCommandShell that can be used for simple I/O. Do we need additional API here, like IServiceCommandShell.getOutputStream() / getInputStream() ? Or do it at the service layer, and have IHostShell.getPlainOutputStream() / getPlainInputStream() ?
The way the dstore shell stuff works is the interpretation of lines is done on the backend - there is no "stream" that comes back - just the interpretted objects.
This will need to be looked at after the release so I'm going to lower the priority.
bringing back to p2 so that a workaround for this can be provided
as per committed meeting, I will change the IShellService layer to provide an IHostOutput object and a new API for getting IHostOuput from readline calls rather than Object. Each IHostOutput object will have a getString() method.
I've changed things so that the IHostShellOutputReader returns a list of IHostOutput objects instead of generic Objects. IHostOutput has a getString() method that should always return the actual line of shell output. Try this out and see if this fixes the problem for you.
Now that everything is in IHostOutput form, you should be able to use these services consistently (and therefore runCommand should not have this issue).
I'm not sure how to test this, but using the shell (through dstore) on Linux, Unix and Windows does not seem to have any problems that would be associated with this. This looks like an API change, and there does not appear to be any regression as a result. Dave/Martin, should we close the bug or wait for bug 158312 to be closed.
verified with I20061102-1200
closing.
[target cleanup] 1.0 RC3 was the original target milestone for this bug
