Bug 424353 - Cannot specify Unix line endings when launching a JVM
Summary: Cannot specify Unix line endings when launching a JVM
Status: REOPENED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Debug (show other bugs)
Version: 4.4   Edit
Hardware: All All
: P5 normal (vote)
Target Milestone: ---   Edit
Assignee: JDT-Debug-Inbox CLA
QA Contact:
URL:
Whiteboard: stalebug
Keywords: helpwanted
Depends on:
Blocks: 424352
  Show dependency tree
 
Reported: 2013-12-18 11:51 EST by Ed Willink CLA
Modified: 2024-04-05 19:40 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ed Willink CLA 2013-12-18 11:51:24 EST
In order to have Unix line endings when launching a JUnit test, it is necessary to specify \n as the Java system property. This appears to be impossible since the multiple levels of escaping required from the UI do not nest correctly. None of \n \\n \\\n \\\\n work.
Comment 1 Dani Megert CLA 2014-01-13 09:30:20 EST
(In reply to Ed Willink from comment #0)
> In order to have Unix line endings when launching a JUnit test, it is
> necessary to specify \n as the Java system property. This appears to be
> impossible since the multiple levels of escaping required from the UI do not
> nest correctly. None of \n \\n \\\n \\\\n work.

This is not a bug in the UI, but how java(.exe) handles this [1]. There is no way to set the line separator. Even if we tried to set that property via code, it won't work because some of the classes are initialized before us.

If you know of a valid way to set that property, let us know and we can reopen this bug here.

[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4947206
Comment 2 Dani Megert CLA 2014-01-13 09:36:10 EST
*** Bug 424352 has been marked as a duplicate of this bug. ***
Comment 3 Ed Willink CLA 2014-01-13 10:01:10 EST
Your conclusion is not backed up by the referenced WONTFIX Java bug.

The referenced bug imposed shell expectations that were rejected. The ability to use \n was demonstrated.

For a Java launch from Eclipse, the sender (Eclipse) is known and the receiver shell (e.g. Windows) is known; the sender can therefore encode the shell line in a way that passes through the shell to control the JVM usefully.

I suggest that the JVM launch should define an escaping policy (perhaps Java-like) decode it, then re-encode it using a shell-specific policy. Similarly the persisted launch should use the re-encoding applicable to the launch file loader/saver.
Comment 4 Eclipse Genie CLA 2020-04-14 20:05:25 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug.

If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.
Comment 5 Ed Willink CLA 2020-04-15 03:56:23 EDT
(In reply to Dani Megert from comment #1)
> If you know of a valid way to set that property, let us know and we can
> reopen this bug here.
> 
> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4947206

Rereading the above bug, the reporter provided the workaround. The receiver, which for this Bugzilla is the JUnit test runner, needs to replace all \\+n by \n since the JVM doesn't.
Comment 6 Eclipse Genie CLA 2022-04-07 18:58:04 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.
Comment 7 Eclipse Genie CLA 2024-04-05 19:40:41 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.