On Thu, 2008-09-11 at 18:21 +0200, Luca Bruno wrote:
> On Thu, 11 Sep 2008 17:09:26 +0100
> Neil Williams <codehelp@debian.org> wrote:
> > On Thu, 2008-09-11 at 15:35 +0200, Josselin Mouette wrote:
> > > Le jeudi 11 septembre 2008 à 14:39 +0200, Luca Bruno a écrit :
> > > > The proposal:
> > > > I know it's bad to break compatibility but I also think keeping things
> > > > with hacks and far from the GUI prospective can become obsolete and
> > > > non user-friendly.
Making everything have to conform to GUI requirements is also
non-friendly. reportbug must still be usable over SSH without requiring
SSH -X. IMHO the GUI requirements should be lower priority than existing
CLI behaviour.
> > I can't speak for others but my scripts use yesno():
> > yesno "May I include your sources.list (/etc/apt/sources.list)? " yep
> >
> > The frontend could execute their own shell wrapper that implements yesno
> > and sources the bug script (as reportbug does). The other yesno function
> > can do whatever is necessary to callback into the frontend, get the user
> > response and feed it back to the script.
> >
> > If the frontend can use yesno(), I think it's perfectly reasonable to
> > expect all packages using bug scripts to use yesno() and not cat <<EOF.
> >
> > > > Second solution: I don't know, I'm asking to you
> > >
> > > The second solution is to specify that these scripts should not be
> > > interactive. I don’t think there is much point in it, and it would
> > > simplify things a lot.
> >
> > We've been here before. Some people might value the opportunity to
> > refuse permission to include sources lists and other data - any
> > non-interactive frontend must make it absolutely clear that this data
> > has been included and it is up to the user to delete it.
> >
> > Cannot the other frontends do what reportbug does and implement a bash
> > function that scripts can call? The terminal can be hidden or run via
> > internal calls, just as long as it pauses and allows the user to make a
> > decision.
> >
> > I suspect the problem with using debconf will be that debconf a) expects
> > to be run as root and b) is too specialised in how it wants to store
> > data (which we don't want to do at this point). However, something that
> > implements a choice of frontends *without losing functionality* is the
> > best bet.
> >
>
> The problem comes also with yesno(), because the more sane (as far as
> I know) way to communicate is FIFO.
> You call the yesno() function, then it writes to the FIFO and request
> ui.yes_no() from python.
> But for cat <<EOF, which actually your script is using too, I had to
> export -f cat hacked to send lines to the FIFO in a particular way.
> So there's something like a protocol I've created to deal with the
> python UI.
My own scripts don't use cat <<EOF, although the function does use cat
to pass the file data into reportbug, that is cat "$file" >&3
> If scripts could use a function like display() that would solve the
> problem of "overriding" cat().
Why is display() any better? How is reportbug CLI meant to implement
display() ? The CLI doesn't want to display the file, it wants to read
it in and put it into the temporary file.
I don't see the problem here, you call the bug script from another shell
script that you write yourself. Your yesno() function does what is
needed to ask the user and get the feedback then passes that back to the
script and reads in the reply from the script. Then your own shell
script can communicate with whichever GUI code you need - maybe by
writing out a temporary file that the frontend adds to the displayed
content.
> Reportbug is ok with text and urwid (which also stops curses and
> switches to text), but the coming GTK+ interface won't support it.
Then the GTK+ frontend is broken and should be fixed so that it can
support the existing format of the bug scripts.
> You have to switch to the terminal and see what's happening, or
> alternatively embed a VTE in the wizard.
I don't see that at all. You simply wrap the existing shell code in your
own shell wrapper that calls something like zenity or another bespoke
interface that raises the necessary dialog, get the result and continues
within shell. Then when the sourced bug script has processed the results
of the bug script, it simply writes that out to a temporary file - or
appends it to whatever temporary file is currently in use.
Don't try to parse the bug script, run it within shell and handle the
IO.
Take a look at the source code for zenity and maybe emrecent (from
emdebian-tools) that controls zenity (or whiptail) from a CLI
environment (in this case, perl).
Let shell do the processing and just give your own shell script whatever
executable it needs to raise a dialog to ask the question. The GUI can
decide which temporary file receives the output of the bug script, the
shell script simply appends to it. Done.
#!/bin/sh
# pseudo-code - you can provide an executable instead of zenity if you like
# something like this with temp_file and bug_script passed on the command line.
# add some error checking and it should be OK
# my GUI reportbug bug script wrapper
bug_script=$1
temp_file=$2
exec 3>&1
yesno () {
zenity --title $package --question "This package wants to ask something"
if [ -n $0 ]; then
echo yep
fi
}
. $bug_script
echo $1 >> $temp_file
# copyright GPL-2+
# :-)
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: This is a digitally signed message part