Port stdin to lua's stdin
tilkinsc opened this issue · comments
Lua5.1, Lua5.2, and Lua5.3 currently has no way of getting stdin input outside of manual in-console input. No matter what you pipe to luaw or lua, nothing actually gets sent to io.stdin for in-script use. In a recent update, I made it enabled to where you can use | and < to send files and strings to the program via stdin. I don't think I really set it up too good, but it works and I have a patch that I am working out at the time of writing.
The patch comes down to when what runs. ARGS.restore_console exists because I need to flag to re-enable tty for the post-exist flag -p. I will not be able to get stdin into my program and use -p without the hack, as this is due to Windows and Linux. It was a nasty hack that goes against the prettiness of the code I have, but hey. The hack has to do with organizing this process to allow tty to be reenabled and also be able to give scripts their data they want. Without the organization patch, piping and trying to -e a string will not work per trying to io.stdin:read() due to when the hack comes into effect.
More importantly though, Lua's code in liolib.c, if I am not mistaken, opens up 2 new files and treats them as a high level stdin and stdout. Using getc will allow for this ofc... you don't have to use the stdin file handle, in fact echo print('hi') | lua -i breaks in puc-lua the same way it does LuaConsole.... thus the hack I just brought up. Although, the cutesy that the puc-lua console is, it actually just executes whatever you pipe through it aka autodetection. Limiting, I know.
Lua kindly puts the files in the registry. So sweet of them, I think I might as well take the files for myself and fix the pipeline on user switch request. Idk if it will break the io lib. If it does I can use other synthetic ways I am sure. Although, its good to keep in mind that people are definitely now allowed to pipe streams to the program - in that 'stdin' could not be used for processing socket streams of data at varying intervals. I don't want to create an io library lol.
C:\git\LuaConsole\lua-5.3.5\src>echo print('hi') | lua -i
Lua 5.3.5 Copyright (C) 1994-2018 Lua.org, PUC-Rio
> hi
>
C:\git\LuaConsole\lua-5.3.5\src>
So with a little more read-into the code, I discovered puc-lua does infact use stdin and stdout in 53-51 for IO correctly. However, piping is still broken due to the fact of tty breaks aka the state at which getc will actually block and actually grab input in which it processes, puc-lua expects piped data to be eaten as a .lua file, and the state in which tty can be re-enabled and used when code might expect to either read from stdin or from console input.
However, good news.
By processing the stdin input first, you can define the rule of 'tty doesnt work when piping, even if the code io.stdin:read()'s.' A work around for this work around would be to read the pipe into buffered segments and be queued. However, this adds a lot of code complexity just to store the data. It also breaks the possibility to send a file remotely via a REPL-like environment aka breaks sockets giving files that are bigger than the buffer or requiring the need to dynamically load code of the buffer's size.
Once tty is re-enabled, the pipe stdin will not give its data to the tty stdin. This creates the problem at when do I re-enable tty. This breaks io.stdin:read() as a non-blocking EOF function until its re-enabled. The solution would be to give the user a switch determining the place to enable the tty for ability to REPL or even use stdio in say a -e or -l or file execution. The downside is its either input from stdio or manual input from stdio, as during the execution of a script re-enabling the tty is pretty much unsafe due to the detection of such need. The hack of the century is retaining the stdio information and re-enabling the tty without lost information.
As soon as I can figure this situation out, the ability to pipe data into lua rather than as a file for LuaConsole will be added.
The need to store the file or be switched is irrelevant because it can be piped directly to lua via a function provided by lua. However, reinstating the data pipeline is a must for new data and will take some time to figure out how to do that.