From: Kent Gibson <warthog618@gmail.com>
To: esben@geanix.com
Cc: linux-gpio@vger.kernel.org
Subject: Re: [RFC PATCH] gpioset: only print prompt when stdout is tty
Date: Wed, 24 May 2023 16:12:16 +0800 [thread overview]
Message-ID: <ZG3G4FMUYmB8Ogfv@sol> (raw)
In-Reply-To: <87lehe9ncs.fsf@geanix.com>
On Wed, May 24, 2023 at 09:53:39AM +0200, esben@geanix.com wrote:
> Kent Gibson <warthog618@gmail.com> writes:
>
> > On Wed, May 24, 2023 at 08:30:33AM +0200, esben@geanix.com wrote:
> >> Kent Gibson <warthog618@gmail.com> writes:
> >>
> >
> > Yeah, it isn't a whole load of fun, but it isn't intended as a full on
> > daemon. It is an option that was added in v2 so you CAN now write a
> > shell script that can request lines and change them as necessary - without
> > releasing them. It might not be pleasant but now it is possible.
> >
> > If that doesn't suit you then look for another solution as you are now
> > beyond the scope that gpioset was intended for.
>
> I guess I will have to do that. Although I don't agree that I am out of
> scope. I just want to do exactly what you have described is in scope for
> gpioset. I just don't want the prompt when not using a tty, and the
> reason for the prompt being there is to make the test work, not for a
> real-world use-case. Anyway, I can do my own thing. No problem.
>
Not just for testing.
In the real world the prompt is there so the controlling script can tell
a command is completed - same as a human would.
> >> > 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.
> >
> > I don't see that.
> >
> > What I see is that bash blocks until something writes to the fifo - not
> > even launching gpioset until that happens.
>
> Ok.
>
> What I am saying is if you actually do manage to run gpioset with stdin
> connected to a fifo, and the fifo not having any writers, you will end
> up eating up the cpu in a small busy loop.
>
> Because of the problem you describe, you just haven't gotten to that
> point though.
>
No, that is wrong. I mean I've tested it. Just now. Again. To be sure.
The only reason it would spin is if you connect it to a pipe that always
indicates it is ready to read. And the named fifo doesn't.
> > That is typically not what you want - you want the line requested and
> > set NOW, and you can update it later through the fifo.
> > The echo is just there to get bash over the hump.
> > (btw, if there is a better way I would love to know it)
>
> I haven't really investigated that. I just made the process running
> gpioset hold a dummy writer open to the fifo.
>
Yeah, I don't know what you are doing, as you haven't shared details, but
if it beahves as you say then it obviously broken.
But that is not due to gpioset.
> > With the named fifo, as used here, gpioset will start, request and set
> > the line, and then will block until something writes to the fifo.
> >
> >> > 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.
> >
> > So redirect stdout through a filter to remove the prompt?
>
> Yes, I could do that. But having an extra process running, and managing
> to keep that alive... If I need to carry a tiny out-of-tree patch to
> avoid that, I will do that.
>
If that is easier for you.
> >> 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?
> >
> > I'm not keen on adding options to gpioset to massage the output for
> > different use cases - there are already better tools for that.
>
> Ok.
>
> That I guess leaves me with no options than working around gpioset,
> using filters and what else is needed to do what I need.
> Or out-of-tree patching.
>
You missed writing your own daemon. Or asking ChatGPT.
But you do have options.
Have a good one.
Cheers,
Kent.
next prev parent reply other threads:[~2023-05-24 8:12 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-23 13:54 [RFC PATCH] gpioset: only print prompt when stdout is tty Esben Haabendal
2023-05-23 15:36 ` Kent Gibson
2023-05-24 6:30 ` esben
2023-05-24 7:32 ` Kent Gibson
2023-05-24 7:53 ` esben
2023-05-24 8:12 ` Kent Gibson [this message]
2023-05-24 8:35 ` esben
2023-05-24 8:50 ` Kent Gibson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZG3G4FMUYmB8Ogfv@sol \
--to=warthog618@gmail.com \
--cc=esben@geanix.com \
--cc=linux-gpio@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.