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