\g pipe is not well implemented

[okbob]

When I use \g | then I expect so usql will be in backround and should not to read from /dev/tty. But it is not true.

You can check - "select * from pg_class \g | pspg" is working from psql, but don't work from usql (the usql still read the data from /dev/tty).

[kenshaw]

@okbob thanks. We'll try to get this fixed before the 1.0 release. Bare with us as usql is built solely by volunteers, and the good folks in the PostgreSQL community have roughly 2 decades on us in terms of being able to work out the bugs/kinks.

[okbob]

pá 30. 4. 2021 v 12:40 odesílatel Kenneth Shaw ***@***.***> napsal:

@okbob <https://github.com/okbob> thanks. We'll try to get this fixed before the 1.0 release. Bare with us as usql is built solely by volunteers, and the good folks in the PostgreSQL community have roughly 2 decades on us in terms of being able to work out the bugs/kinks.

sure :) Pavel If I remember well, the details about correct implementation of input, output streams were long. The related code in psql is very short, but this is a little bit dark zone of POSIX API, and for expected behaviour some signal's handling should be enabled, disabled. Try to read related psql code.

…

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#249 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEFO424JE3KCBSJFWC5VDTTLKCLHANCNFSM4336CR6Q> .

[nineinchnick]

I reproduced this with less. The problem starts occurring when less consumes all input. This is when usql closes the stdin of the pager. Looks like pspg might consume input more eagerly and the issue is much more visible.
psql runs the pager after forking. I don't think is possible in Go, or even if it is, it might not be worth it. I'll see if I can somehow close usql's stdin or otherwise pause the readline library we're using.

Thanks a ton for reporting this!

[okbob]

pá 30. 4. 2021 v 17:21 odesílatel Jan Waś ***@***.***> napsal:

I reproduced this with less. The problem starts occurring when less consumes all input. This is when usql closes the stdin of the pager. Looks like pspg might consume input more eagerly and the issue is much more visible. psql runs the pager after forking. I don't think is possible in Go, or even if it is, it might not be worth it. I'll see if I can somehow close usql's stdin or otherwise pause the readline library we're using.

I am not an expert on this area - just the usual pattern for using pipe or pagers is using by popen function. I am not sure if you can run pager or other processes and communicate via pipes without forking.

…

Thanks a ton for reporting this! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#249 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEFO4YLXOD2DRNMYNZ2SHTTLLDHZANCNFSM4336CR6Q> .