`secrets cat` command removes the last line without unix file endings

[aryanjassal]

Describe the bug

When writing a file using editors, most of them (fancy IDEs like JetBrains to text editors like VS Code to even minimal TUI apps like nvim) automatically add a newline to the end of the file, signifying that the file is finished.

This doesn't exist on every file, and for files which don't have this, the terminal emulator adds a % at the end to let the user know that the file wasn't closed correctly. *

This behaviour is missing from secrets cat, and if a file does not have a proper ending, then the last line doesn't display properly. Well, the last line does get printed out for a split second, but the terminal emulator overwrites it. This behaviour also exists when using bash in a TTY, so it is not a terminal emulator issue.

To Reproduce

1. Write a file using secrets write without a newline
2. Read the file using secrets cat
3. See last line get erased
4. Pipe the output to a file
5. Run cat on the file
6. See the correct output (with a % at the end if on terminal emulators, or nothing if on TTY)

Expected behavior

All the lines from the output should be printed irrelevant of the ending of the file (or lack thereof)

Screenshots

Platform (please complete the following information)

• Device: Dell Precision 3480
• OS: NixOS 24.05
• Version ["0.12.0","1.15.1","1","1"]

Additional context

This has been tested on multiple terminal emulators, but the behaviour is unchanging. I have also tried adding process.stdout.end() to manually flush the stream, but that didn't work either. The only way I got it partially working was to output a \n to stderr.

More discussion has been done on Polykey-CLI#305 (comment)

Notify maintainers

@aryanjassal

[linear]

ENG-444 `secrets cat` command removes the last line without unix file endings

[aryanjassal]

This issue has been resolved by work done in #374

[CMCDragonkai]

In #374, writing buffers to STDOUT meant that terminal emulators could understand it and print a % at the end.

Generally writing to STDOUT or STDERR should always be buffers, and never assume the data is a "string".