On Wed, Jun 29, 2022 at 2:56 PM Bartosz Golaszewski <brgl@xxxxxxxx> wrote: > > On Wed, Jun 29, 2022 at 12:58 PM Andy Shevchenko > <andy.shevchenko@xxxxxxxxx> wrote: > > > > On Wed, Jun 29, 2022 at 12:48 PM Kent Gibson <warthog618@xxxxxxxxx> wrote: > > > On Wed, Jun 29, 2022 at 12:27:13PM +0200, Andy Shevchenko wrote: > > > > On Wed, Jun 29, 2022 at 11:27 AM Jiří Prchal <jiri.prchal@xxxxxxxxxxx> wrote: > > > > ... > > > > > > Do not use shell. Use proper programming language that may give you an > > > > easier way of handling this, i.e. _context_. Shell tools are > > > > _context-less_ and here is the problem you are trying to solve, but > > > > from the wrong end. > > > > > > Actually my proposed gpioset for v2 will support running interactively > > > so it can maintain context and be driven from shell - for cases where > > > basic scripting will suffice. > > > > Dunno if it's the right direction and if I missed any (additional) discussion. > > As far as I remember the idea was to introduce DBus aware daemon that > > should handle the context of the line and at the same time consider security > > And it's still very much on the roadmap. > > > implications. Allowing shell to be context-aware is a hidden mine > > field. What will happen if the script/user forgets to move the line to > > the proper state and the chip will drain a lot of current? So, at > > least PM concerns just popped up immediately to my mind. What else can > > be problematic? So, I dunno, it's a good idea to allow shell to leave > > a line in some state when the user actually doesn't care about it > > anymore. At the bare minimum this mustn't be default behaviour. > > > > It's not much different from letting your current gpioset run in the > background, is it? > > Kent just submitted his first version of gpioset, you can take a look > at it and review it. :) So far from Kent's and yours explanations there is no evidence to raise an alarm. -- With Best Regards, Andy Shevchenko