awnumar/gravity

Can "only" read 4095 bytes from stdin on Linux

awnumar opened this issue · 2 comments

This is an issue to track the problem of reading more than 4095 bytes from stdin.

On UNIX systems, terminal input is silently truncated to 4095 bytes: https://stackoverflow.com/questions/18015137/linux-terminal-input-reading-user-input-from-terminal-truncating-lines-at-4095

There are a few solutions I can think of, with varying degrees of success:

  • Warn the user before input that only 4095 bytes will be read at most. This is very annoying and would expect the user to count the bytes before adding them. We can't check the size of the input because we'd never read more than the max anyways, so we wouldn't know if it exists.

  • Use a library like termbox-go to read in raw mode. The behaviour would be similar to getch(). This would work but would be unclean to implement. Termbox-go is pretty lightweight but it takes over the entire terminal window. On the other hand, it's multi-platform. Needs thought and experimentation.

  • Use gocui. This would achieve the same thing as termbox-go but with extra functionality for other parts of the CLI. However, its API is unstable and it has a few very major bugs at the moment. This option is maybe a long-term one for when the package is more mature.

  • Disallow input from terminal altogether. Only work with files. This would severely reduce the functionality of the program, but maybe would be a viable solution? In this case we might have to worry about securely reading and writing plaintext to disk.

This issue will be updated with any progress.

From an initial look, gocui may be the best route to go down.

This is no longer a concern (#32) but may become one again in the future. Gocui is still (maybe) relevant in the near-term for a good-looking CLI.

If this issue becomes a concern again then this will be reopened.