Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 335814

Summary: OSGi console help command carriage return problem.
Product: [Eclipse Project] Equinox Reporter: Nikolas Falco <nfalco79>
Component: FrameworkAssignee: equinox.framework-inbox <equinox.framework-inbox>
Status: RESOLVED FIXED QA Contact:
Severity: trivial    
Priority: P3 CC: l.kirchev, tjwatson
Version: unspecified   
Target Milestone: 3.7 M7   
Hardware: PC   
OS: All   
Whiteboard:
Attachments:
Description Flags
A simple example of actual help OSGi console command none

Description Nikolas Falco CLA 2011-01-31 04:14:44 EST
Build Identifier: M20100909-0800

When an equinox application is running under linux machine and I connect to its remote console from a windows platform, part of help commands are shown without a carriage return, so is very hard understand and find console commands.
Commands affected are:
- org.eclipse.equinox.internal.app.AppCommands
- org.eclipse.core.runtime.internal.adaptor.EclipseCommandProvider
- org.eclipse.core.internal.registry.osgi.RegistryCommandProvider

The only correct implementation of help is FrameworkCommandProvider

All these command use '\n' or read the system property 'line.separator'. I remember that in a telnet protocol should be use '\r\n' to have a real new line indipendent of operative system where you run telnet implementation.

Reproducible: Always

Steps to Reproduce:
1.Run an eclipse instance with -console 5000 under a linux machine.
2.Open a telnet session (with Putty or other telnet programs) under a windows machine.
3.Launch "help" command
Comment 1 Nikolas Falco CLA 2011-01-31 04:17:28 EST
Created attachment 187933 [details]
A simple example of actual help OSGi console command

How you can see is hard to understand help and recognise avaiable commands.
Comment 2 Thomas Watson CLA 2011-01-31 16:20:54 EST
Lazar, have you run across this issue?
Comment 3 Lazar Kirchev CLA 2011-02-01 01:56:27 EST
(In reply to comment #2)
> Lazar, have you run across this issue?

I have seen once a similar behavior with a custom Command Provider implementation, I think it was even on Windows-Windows connection, but at the time I didn't delve into the issue. I will check this and I will provide a patch - as we planned to add special per-command help to the command providers, I can make both changes together.
Comment 4 Thomas Watson CLA 2011-03-21 09:08:09 EDT
This has been fixed as part of the fixes to  bug340290 bug335035 and bug340293