[dengzhhu653]

What changes were proposed in this pull request?

Avoid TerminalBuilder.build() for script input so JLine does not select PosixPtyTerminal via native providers’ newTerminal, so it reads bytes/lines matching the input file.

Why are the changes needed?

Statement sent to HS2 gets corrupted

Does this PR introduce any user-facing change?

No

How was this patch tested?

Re-run the scripts in my macOS laptop.

[utafrali]

The fix targets a real bug but uses a jline3 internal impl class as the solution, which creates a fragile dependency. Additionally, hardcoding UTF-8 can silently corrupt scripts in other encodings. No automated regression test covers this path, and the PR description's 'What changes were proposed' section is blank, making it impossible to verify intent from the diff alone.

[utafrali]

Importing from org.jline.terminal.impl couples Beeline to jline3's internal implementation package. Classes in impl packages are not part of the stable public API and can be removed or changed in patch releases of jline3 without notice.

The same behavior can be achieved through the public TerminalBuilder API:

terminal = TerminalBuilder.builder()
    .streams(inputStream, getErrorStream())
    .type(Terminal.TYPE_DUMB)
    .encoding(StandardCharsets.UTF_8)
    .build();

This avoids the impl import entirely while still forcing a dumb, encoding-fixed terminal for file input.

[dengzhhu653]

Good point.

[utafrali]

Hardcoding StandardCharsets.UTF_8 here is a silent regression for users whose script files are in a different encoding (e.g. Latin-1, GBK, Shift-JIS). The original TerminalBuilder path would have derived the encoding from the JVM default or terminal negotiation.

Consider reading the charset from an existing Beeline option (e.g. getOpts().getScriptCharset() or a system property fallback), or at minimum document the UTF-8 requirement prominently, since any non-UTF-8 script will now be silently misread rather than just having its statements reordered.

[dengzhhu653]

For beeline today, getCommands(File) already uses "UTF-8", other beeline I/O also standardizes on UTF-8 (password file contents, OutputFile with "UTF-8"). Explicit UTF-8 aligns -f with existing file handling.
We can support something like getOpts().getScriptCharset() in the future.

[utafrali]

The comment "a plain stream pump" is not accurate for ExternalTerminal. According to jline3 source, ExternalTerminal spawns a background thread to process input and handle signals (e.g. Ctrl+C). It is designed for SSH/telnet connections, not file reading. This comment will mislead future readers about what ExternalTerminal actually does. If the goal is simply to suppress terminal capability detection, please describe that instead.

[dengzhhu653]

Nice catch, Thanks

[dengzhhu653]

@utafrali I don't add the regression test due to, I want to kept the diff small, 500 lines of a script file is noisy compared to few lines of fix, and this issue might depend on the environment. The jira provides a script file I can show the case locally, after patching the fix, issue is gone.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Copilot]

🟡 Changes recommended

Existing tests bypass the changed terminal-construction path, so a regression test is needed to verify that real provider selection preserves every line of large scripts, including UTF-8 text and a final line without a newline.

1 open issue

• Test real terminal construction preserves large UTF-8 scripts · New

What changed in this PR

This PR addresses statement corruption when Beeline reads script files with -f, changing JLine terminal selection to avoid native pseudo-terminals.

Changes:

• Forces the exec provider and dumb terminal type for script input.
• Explicitly uses UTF-8 for script decoding.
• Leaves interactive system-terminal construction unchanged.

File	Description
beeline/​src/​java/​org/​apache/​hive/​beeline/​BeeLine.java	Configures a non-PTY, UTF-8 terminal for script input to prevent statement corruption.

_{Review effort: Balanced}