Re: [RFC PATCH] gpioset: only print prompt when stdout is tty

[esben@xxxxxxxxxx]

Kent Gibson <warthog618@xxxxxxxxx> writes:

> On Tue, May 23, 2023 at 03:54:41PM +0200, Esben Haabendal wrote:
>> When gpioset interactive mode is used as intended, as a human controlled
>> interface, stdout should be a tty.
>> 
>
> Yeah, no, the interactive mode is also intended to be script driven -
> checkout the test suite, gpio-tools-tests.bat, as an example of it being
> driven using a coproc from bash.
> 
> Removing the prompt would break the handshaking with the controlling
> script - that is how it determines the slave process is up.

I see.  I use a process supervisor, which should ensure that the gpioset
process stays alive.  And if a client writes to the fifo while the
process is shortly down, it will pick up the request when it starts up.

A proper gpio daemon would of-course need a request-reply mechanism, so
the requester can know if the request succeeded.  But that obviously is
something slightly more involved than removing a single printf() call.

> I'll try running your patch through the test suite tommorrow, but I'm
> pretty sure it will break it - IIRC the code you removed was put there
> precisely to get the test suite to run.
>
> Have you tried running the test suite?

Yes, I have now.  And I see that they fail with my RFC PATCH.  The use
of coproc is obviously not compatible with it.

But I cannot help feeling that the use of coproc to drive a
command-prompt interface, while well suited for writing a test for such
an prompt based interactive interface, it is not how you would want to
talk with a daemon.

>> By leaving out the prompt when stdout is not a tty, gpioset interactive mode can
>> be used as a really simple deamon for controlling GPIOs by connecting it to a
>> FIFO.
>
> It can do that already - just direct the output to /dev/null.

If I direct the output to /dev/null, I cannot see what good the prompt
does.  I am directing the output to a log file, and by sending "get"
commands to gpioset, I end up with a log of the gpio states.

> Which you would need in your case anyway - the prompt isn't the only
> output - try piping a get command to your daemon and see what happens.

I know.

> This works for me as a simple daemon script:
>
> #!/bin/bash
>
> pipe=/tmp/gpiosetd
>
> mkfifo $pipe
>
> trap "rm -f $pipe" EXIT
>
> # as bash will block until something is written to the pipe...
> echo "" > $pipe &

I believe this is not just needed because of bash.  If you don't have a
writer on the fifo, the gpioset will end up in a busy loop in readline
until a writer appear, spamming a prompt out on output while eating up
100% cpu.

> gpioset -i GPIO23=0 < $pipe > /dev/null
>
> Does that not work for you?

That is basically what I do.  Just output directed to a log file
(actually, a pipe to a process writing to rotated log files) instead of
/dev/null, and then no prompt noise in the log files.

Anyway, what about adding a new CLI option. Either something like '-I'
for no-prompt interactive mode, or '-n' to be used with '-i' for the
same?

This would make all existing usage of gpioset work just as it is now,
but allowing use without a prompt when that is desired?

/Esben