RFR 8166051: [jline] Cannot parse .inputrc with \r

Jan Lahoda jan.lahoda at oracle.com
Fri Sep 16 19:10:20 UTC 2016


On 16.9.2016 18:26, Robert Field wrote:
> BufferedReader provides platform independent behavior.  Which is

Yes.

> appropriate here because configuration files get copied between

Not sure if (BufferedReader-based) platform-independent behavior is 
appropriate for reading inputrc - that file is originally for use of the 
native readline. The native readline appears to use '\n' on my Linux and 
either '\n' or \'r\n' on my Windows. Neither appears to interpret 
standalone '\r'. Which is similar to the proposed patch. But I admit the 
jline behavior still differs from the native behavior, as jline trim()s 
the line it read; and native does not appear to produce warnings for 
absent closing ".

> platforms with different line-end standards.
> The proposed replacement exchanges this for a platform dependent strategy.
> While it would address this one obscure failure, my concern is that it
> will create new, possibly more common, problems.  specifically where a
> file where \r\n is used -- injecting \r into the results.
> Not sure what the right choice is.
> A compromise might be to accept \n or \r\n on all platforms, and \r
> alone only on platforms that accept that as a line end.
> I am concerned with forking jline, esp. if it not a clear fix.

So, maybe we should treat this is an upstream bug, reporting it to jline 
and wait until it is properly fixed there?

> Can we address this at a higher level?  More tolerant error handling?

Without changing jline, I think we could completely suppress all 
warnings from jline. With a change to jline, we could suppress this 
specific warning. But, I am not sure either of these is a proper fix - 
we/jline is still not interpreting the file correctly. So we would be 
just masking out the problem.

Jan

>
> -Robert
>
>
> On 09/16/16 02:23, Jan Lahoda wrote:
>> Please review a change to how .inputrc is read. Currently, it uses
>> BufferedReader.readLine(), which interprets '\r' as a line separator,
>> and so the '\r' character cannot be used in the macros. The proposed
>> change is to use System.getProperty("line.separator") and "\n" as line
>> separators.
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8166051
>>
>> Webrev:
>> http://cr.openjdk.java.net/~jlahoda/8166051/webrev.00/
>>
>> Thanks!
>>
>> Jan
>


More information about the kulla-dev mailing list