pythondialog-users Mailing List for pythondialog

Hello,

Just a short mail to check that this mailing list still works and
confirm for those wondering that pythondialog 3.5.3 has been released in
order to make it clear that the pythondialog home page has moved to

  https://pythondialog.sourceforge.io/

The previous URL, which didn't use HTTPS, still works and automatically
redirects to the new one (accessing the old domain with the HTTPS scheme
appears to be impossible because SourceForge wants different domains for
its old HTTP-only and the new HTTPS-based infrastructure, for the sake
of clean cookie management[1]).

Regards

[1] https://sourceforge.net/blog/introducing-https-for-project-websites/#comment-32584

-- 
Florent

Dear users,

I have released pythondialog 3.5.1. The main change is that the
packaging now uses setuptools instead of distutils, which allows us to
provide pythondialog in wheel format[1]. If you installed using the
recommended method (pip), nothing should change for you, as pip should
always be able to install wheels. Two other changes may warrant your
attention:

  - In case you run a pythondialog-based program with the PATH variable
    unset in the environment (which I hope is very unlikely), you should
    read the explanations for version 3.5.1 on the news page[2] and
    probably upgrade (and/or define a sane PATH variable in your
    environment, or use an absolute path for the 'dialog' argument of
    the Dialog constructor).

  - I have released the Python 2 backport[3] with all these changes
    (setuptools-based packaging + change in the default used when PATH
    is unset), but this will most probably be the last release of this
    backport. Python 2 itself reaching its end of life on January 1,
    2020,[4] the Python 2 backport of pythondialog is now unsupported.

That's all, folks!

Regards

[1] https://www.python.org/dev/peps/pep-0427/
[2] http://pythondialog.sourceforge.net/news.html#3.5
[3] https://pypi.org/project/python2-pythondialog/
[4] https://www.python.org/doc/sunset-python-2/

-- 
Florent

Hi
Sent an email to Thomas Dickey the Dialog maintainer for this one.
Don't think it's a python issue.

Cheers,
Paraic 

----------------------------------------------------------------------

Message: 1
Date: Tue, 3 Jan 2017 13:19:49 +0000
From: Paraic O'Ceallaigh <poc...@fe...>
Subject: [Pythondialog-users] Using the buildlist and selecting the
	right	order
To: "pyt...@li..."
	<pyt...@li...>
Message-ID:
	<343...@VS...>
Content-Type: text/plain; charset="utf-8"

Hi

I have a question around the widget for buildlist in pythondialog.

I have it running and using space to select but the way in which it selects is strange. I assumed that it would select the items in the left side one by one and place them in the same order on the right side but that is not the case.

It actually does this if I use just the space bar, but if I use the arrow key to select a different item that the one highlighted it inserts it out of order but I can't quite make out what the order is. I thought it might be alphabetical but it doesn't seem to be.

Is there a way I can guarantee that the order selected will be the same when moved to the right side?

My code is to select a bunch of currencies for a rateboard which is read into a list from a txt file. The code works fine and I get the order it was selected in as expected, its just the way the buildlist widget works which is confusing.



Any help appreciated.



Pythondialog 3.5, dialog 1.3-20160828 on Debian



code, tag = d.buildlist(text="Please Select correct order for your Buy Rateboard. SPACE moves an item from one column to the other.",

                  items=[(lines[9], "EUR", 1),

                    (lines[22], "USD", 1),

                    (lines[1], "AUD", 0),

                    (lines[4], "CAD", 0),

                    (lines[2], "BGN", 0),

                    (lines[21], "TRY", 0),

                    (lines[8], "DKK", 0),

                    (lines[18], "SEK", 0),

                    (lines[0], "AED", 0),

                    (lines[23], "ZAR", 0),

                    (lines[5], "CHF", 0),

                    (lines[17], "PLN", 0),

                    (lines[19], "SGD", 0),

                    (lines[16], "NZD",0)],visit_items=True)



[cid:image001.png@01D265C4.0F54D960]





This email, including any attachments, is confidential.  If you are not the named recipient, please contact the sender and delete all copies of this email from your computer system(s).
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 12042 bytes
Desc: image001.png

------------------------------

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot

------------------------------

_______________________________________________
Pythondialog-users mailing list
Pyt...@li...
https://lists.sourceforge.net/lists/listinfo/pythondialog-users


End of Pythondialog-users Digest, Vol 15, Issue 1
*************************************************

--
Fortress Shield (by ParaTech, LLC)

Hi,

Sorry, not much time...

Your problem seems to be dialog-related: pythondialog doesn't control
what happens inside the widget, it justs starts it, retrieves the
results and presents them in a way that is nice for Python code.

Paraic O'Ceallaigh <poc...@fe...> wrote:

> Pythondialog 3.5, dialog 1.3-20160828 on Debian

3.5 is maybe your Python version, but this can't be pythondialog (latest
is 3.4.0).

dialog 1.3-20160828 on Debian unstable seems rather broken to me: the
pythondialog demo which passes perfectly with dialog 1.2-20150513, fails
with 1.3-20160828 when using --menu (the dialog error message seems
quite wrong), and even if I comment this, it fails later with
--radiolist (same kind of... weird message). Without digging further,
I consider this version (dialog 1.3-20160828) too buggy to be usable.

I've also been very disappointed by the changes in dialog from
2016/04/24 which, AFAICS, make it again impossible to have reliable
arbitrary string handling, just for the sake of color \Z escapes, which
I consider much less important than reliable string handling.

With dialog 1.2-20150513 (a usable version), only Enter seems to select
elements in --buildlist, and the order seems to be the same for selected
items as they had on the left (i.e., as you said, except I don't manage
to select anything with arrows).

-- 
Florent

Hi

I have a question around the widget for buildlist in pythondialog.

I have it running and using space to select but the way in which it selects is strange. I assumed that it would select the items in the left side one by one and place them in the same order on the right side but that is not the case.

It actually does this if I use just the space bar, but if I use the arrow key to select a different item that the one highlighted it inserts it out of order but I can't quite make out what the order is. I thought it might be alphabetical but it doesn't seem to be.

Is there a way I can guarantee that the order selected will be the same when moved to the right side?

My code is to select a bunch of currencies for a rateboard which is read into a list from a txt file. The code works fine and I get the order it was selected in as expected, its just the way the buildlist widget works which is confusing.



Any help appreciated.



Pythondialog 3.5, dialog 1.3-20160828 on Debian



code, tag = d.buildlist(text="Please Select correct order for your Buy Rateboard. SPACE moves an item from one column to the other.",

                  items=[(lines[9], "EUR", 1),

                    (lines[22], "USD", 1),

                    (lines[1], "AUD", 0),

                    (lines[4], "CAD", 0),

                    (lines[2], "BGN", 0),

                    (lines[21], "TRY", 0),

                    (lines[8], "DKK", 0),

                    (lines[18], "SEK", 0),

                    (lines[0], "AED", 0),

                    (lines[23], "ZAR", 0),

                    (lines[5], "CHF", 0),

                    (lines[17], "PLN", 0),

                    (lines[19], "SGD", 0),

                    (lines[16], "NZD",0)],visit_items=True)



[cid:image001.png@01D265C4.0F54D960]





This email, including any attachments, is confidential.  If you are not the named recipient, please contact the sender and delete all copies of this email from your computer system(s).

Hello,

I am pleased to announce the release of pythondialog 3.4.0. You can read
a summary of the changes in this version at:

  http://pythondialog.sourceforge.net/news.html#3.4

For your convenience, here is a text dump of this summary:

Main changes in version 3.4.0

   * The Python 2 backport has been updated to this version.

   * Add method Dialog.editbox_str(). This is a convenience wrapper
     around Dialog.editbox() that automatically creates and deletes a
     temporary file containing the initial box contents, which is passed
     as a string (Dialog.editbox() needs it in a file).

   * Add the week_start common option, mapped to dialog's --week-start
     option (it is useful with the calendar widget). The value may be an
     integer or a string (cf. dialog's manual page for more details).

-- 
Florent

Hi again,

Paraic OCeallaigh <par...@gm...> wrote:

> Thanks for the feedback and the sample code. I do reckon the
> EditBoxStr function would be useful.
>
> I have it writing back to a tmp file now so all is good.

OK, I'll add almost the same method[1] as Dialog.editbox_str() in the
next release.

Regards

  [1] slight differences because pythondialog wraps OSError...

-- 
Florent

Hi Florent

Thanks for the feedback and the sample code. I do reckon the
EditBoxStr function would be useful.

I have it writing back to a tmp file now so all is good.

Rgds

Paraic


-------------------

Hi Paraic,

Paraic OCeallaigh <paraic.iam@...> wrote:

> I am trying to use Editbox in a menu system to edit a configuration file.
> I have successfully loaded the file into the editbox and can navigate and
> edit text fine, but then when I press OK, it doesn't save the file.
> I'm probably missing some basic understanding of how this works - do I need
> to save the text that returns from the function in some way?

Absolutely. The 'filepath' argument of Dialog.editbox() is only used to
specify the *initial* contents of the dialog box (this is written in the
doctring and pythondialog Manual). After this initialization of the
widget, the editing process is only done in memory, thus it is up to you
to save the returned string to a file or whatever storage you want, if
you want the result to be saved at all (you could send it to the
network, or wherever you want, really).

Doing otherwise would restrict the generality of the widget a lot. For
instance, when you get the resulting string, you may want to validate its
syntax before maybe storing it to a file, and notify the user if the
syntax is invalid, probably starting a new editbox with the edited
contents loaded from a temporary file to allow the user to fix his
errors, etc. (in a loop, until syntax is fine or the user gives up).

I agree the initial file contents could be taken from a string instead
of a file. Dialog.editbox() takes it from a file because it is a direct
wrapper around dialog's --editbox option, which works this way. If it's
really useful to have a function taking a string instead of a file path
to specify the initial box contents, that can be done very easily in a
wrapper function or method. Something like this should do the trick
(untested):

import dialog
import tempfile

class MyDialog(dialog.Dialog):
    def myEditBoxStr(self, initial_contents, *args, **kwargs):
        tmpfile = tempfile.NamedTemporaryFile(
            mode="w", prefix="yourProgramName.tmp", delete=False)
        try:
            with tmpfile as f:
                f.write(initial_contents)
            # The temporary file is now closed. According to the tempfile
            # module documentation, this is necessary if we want to be able
            # to reopen it reliably regardless of the platform.

            res = self.editbox(tmpfile.name, *args, **kwargs)
        finally:
            # The test should always succeed, but I prefer being on the
            # safe side.
            if os.path.exists(tmpfile.name):
                os.unlink(tmpfile.name)

        return res

If this is really useful, I could add some similar wrapper to
pythondialog as a Dialog.editboxStr() method, or something like that.

> I had a look at the dem.py but I don't see the editbox in the demo saving
> anything after it loads the file (not surprising since its the /etc/passwd
> it loads!)

That is correct!

Regards

-- 
Florent

Hi Paraic,

Paraic OCeallaigh <par...@gm...> wrote:

> I am trying to use Editbox in a menu system to edit a configuration file.
> I have successfully loaded the file into the editbox and can navigate and
> edit text fine, but then when I press OK, it doesn't save the file.
> I'm probably missing some basic understanding of how this works - do I need
> to save the text that returns from the function in some way?

Absolutely. The 'filepath' argument of Dialog.editbox() is only used to
specify the *initial* contents of the dialog box (this is written in the
doctring and pythondialog Manual). After this initialization of the
widget, the editing process is only done in memory, thus it is up to you
to save the returned string to a file or whatever storage you want, if
you want the result to be saved at all (you could send it to the
network, or wherever you want, really).

Doing otherwise would restrict the generality of the widget a lot. For
instance, when you get the resulting string, you may want to validate its
syntax before maybe storing it to a file, and notify the user if the
syntax is invalid, probably starting a new editbox with the edited
contents loaded from a temporary file to allow the user to fix his
errors, etc. (in a loop, until syntax is fine or the user gives up).

I agree the initial file contents could be taken from a string instead
of a file. Dialog.editbox() takes it from a file because it is a direct
wrapper around dialog's --editbox option, which works this way. If it's
really useful to have a function taking a string instead of a file path
to specify the initial box contents, that can be done very easily in a
wrapper function or method. Something like this should do the trick
(untested):

import dialog
import tempfile

class MyDialog(dialog.Dialog):
    def myEditBoxStr(self, initial_contents, *args, **kwargs):
        tmpfile = tempfile.NamedTemporaryFile(
            mode="w", prefix="yourProgramName.tmp", delete=False)
        try:
            with tmpfile as f:
                f.write(initial_contents)
            # The temporary file is now closed. According to the tempfile
            # module documentation, this is necessary if we want to be able
            # to reopen it reliably regardless of the platform.

            res = self.editbox(tmpfile.name, *args, **kwargs)
        finally:
            # The test should always succeed, but I prefer being on the
            # safe side.
            if os.path.exists(tmpfile.name):
                os.unlink(tmpfile.name)

        return res

If this is really useful, I could add some similar wrapper to
pythondialog as a Dialog.editboxStr() method, or something like that.

> I had a look at the dem.py but I don't see the editbox in the demo saving
> anything after it loads the file (not surprising since its the /etc/passwd
> it loads!)

That is correct!

Regards

-- 
Florent

Hi
I am trying to use Editbox in a menu system to edit a configuration file.
I have successfully loaded the file into the editbox and can navigate and
edit text fine, but then when I press OK, it doesn't save the file.
I'm probably missing some basic understanding of how this works - do I need
to save the text that returns from the function in some way?
I had a look at the dem.py but I don't see the editbox in the demo saving
anything after it loads the file (not surprising since its the /etc/passwd
it loads!)

Anyhow any help or understanding appreciated.

Paraic

Forwarding Ebbesen's reply:

> Hi Florent,

> thank you for your answer. I overcame both my space-bar and my
> file-dialog problem by making use of "menu" instead of "fselect" i.e. I
> use glob to get the file names with a specific extension from a specific
> directory and then iterate over the file names to generate the menu
> choices. Then, the user can simply pick an entry and hit OK to get the
> file path.

> Thanks again, Soren

> P.S. You are welcome to upload our conversation to the mailing list.

Hi Ebbesen,

Thanks for the feedback. I am glad to hear you could find a satisfactory
solution to your problems.

Regards


P.S.: I am guilty for the forwarding delay...

-- 
Florent

Hello,

"Ebbesen  Soren" <seb...@id...> wrote:

> Thanks you very much for the input!

You are welcome.

> I have one additional question: I'm working on another project using
> pythondialog with a touch screen. It works well, apart from the dialog
> fselect. The problem here is that I need to hit the space bar to select a file
> (i.e. copy the file-name to the input field below the browser). However, the
> touch screen only renders mouse clicks so I cannot get the file-name into the
> input field. Is there a way around this?

pythondialog can't do that natively in its present state, AFAIK. It is
probably possible, in similar ways as mentioned in my previous mail, to
translate the touch screen events into keyboard events or terminal
input, but the best solution is probably to make dialog behave a bit
like mc (Midnight Commander), which is able to recognize mouse clicks in
several terminal emulators (tested in XTerm, Konsole and the Linux
console, not sure about other terminal emulators). Since mc is based on
ncurses like dialog, the technology is the same. The only thing is that
you want to work with a touch screen instead of a mouse, but it seems to
me it is only one more case to deal with in the relevant software
component, i.e., ncurses and/or terminal emulators.

Well, there still is some complexity if this has to be handled at
terminal emulator level, which I would expect, because depending on what
you use (Linux console or X terminal, or Wayland terminal or...), the
drivers to read touch screen "clicks" are not the same (Linux kernel in
the first case, X.org in the second one; one could also consider
Wayland, OS X...). If I were in your place, I would talk to Thomas
Dickey about this, because he knows the whole terminal software stack
(ncurses, dialog and XTerm maintainer!).

> Oh, one more question: In order to not confuse the user, I'd like to show only
> the contents of a single specific directory and only files with a specific
> extension. In other words, is it possible to remove the "Directories" element
> in fdialog and additionally specify a file extension such that only files with
> this extension are shown?

This sounds like a customization of the fselect widget and must be
implemented in dialog (in C) before pythondialog can offer it. Again,
your best bet here is to contact Thomas Dickey or an ncurses mailing
list. I am sure Thomas would gladly accept a well-written patch. :-)

Sorry for not being able to provide more concrete help...

> Finally, I could't figure out how to reply to your answer to my original
> thread on the mailing list, sorry...

Ah, what is the problem exactly? Is there no error message? I am
replying to the list for the benefit of other users, since that was
apparently your intention (and putting you in Cc just in case, please
tell me if this is unwanted).

Regards

-- 
Florent

Hello,

"Ebbesen  Soren" <seb...@id...> wrote:

> I have connected a DIY game controller to my Raspberry Pi. I would like to
> navigate a dialog with the output of the game controller rather than a normal
> keyboard. I've created a Python script that can read the output of the game
> controller and store it in a variable, so that part is working. I just need to
> fix something somewhere to change from the keyboard to my own custom variable
> which is triggered by the controller. Can this be done?
>
> I looked through Dialog.py but I didn't see anything about keyboard events.

Correct, this is handled at ncurses level, on which dialog is based
(maybe directly in dialog sometimes too, but I don't think so).

> Maybe the right place to fix this is not even in pythondialog but rather in
> the underlying dialog utility?

I don't think you need to modify dialog for this.

> I've actually made it work using pygame and ncurses directly but I would like
> to take advantage of the features of pythondialog to build a proper dialog.

I think there are mainly two ways to do what you want:
  - send appropriate byte sequences to the controlling terminal. I would
    try writing to a device returned by os.ttyname(). You should be able
    to obtain the codes for arrow keys for instance with something like:

      cat >/tmp/whatever

    Then type Ctrl-V followed by the key you are interested in, then
    Enter, Ctrl-D to close the file, then inspect /tmp/whatever with a
    hex editor or od(1).

    Another approach at the same level would be to use pseudo-terminals
    (pty), I believe. Python has os.openpty() and a 'pty' module for
    this.

    I have no experience with this kind of stuff, so I can't promise it
    works this way.

  - simulate the keyboard events at kernel or X server level. I have
    good experience sending mouse events to the Linux kernel using
    python-evdev:

      http://python-evdev.readthedocs.org/en/latest/

    but it can also send keyboard events. There are other modules doing
    the same, I only know this one works. This approach requires write
    permissions to /dev/uinput; you may want to use an udev rule such
    as:

      SUBSYSTEM=="misc", KERNEL=="uinput", GROUP="your-group", MODE="0664"

    to automatically set this up at each boot.

    There are also many tools/hacks to simulate events at the X server
    level (xdo, PyAutoGUI...) but my attempts with this approach have
    not been successful. I remember trying XSendEvent and
    XTestFakeKeyEvent in C++ as well as xdo from the command line, but
    this didn't work well for me.

Finally, unsuitable for dialog, but using D-Bus to control other
programs can be very effective. Using the following simple patch:

I have connected a DIY game controller to my Raspberry Pi. I would like to navigate a dialog with the output of the game controller rather than a normal keyboard. I've created a Python script that can read the output of the game controller and store it in a variable, so that part is working. I just need to fix something somewhere to change from the keyboard to my own custom variable which is triggered by the controller. Can this be done?

I looked through Dialog.py but I didn't see anything about keyboard events. Maybe the right place to fix this is not even in pythondialog but rather in the underlying dialog utility?

I've actually made it work using pygame and ncurses directly but I would like to take advantage of the features of pythondialog to build a proper dialog.

Your input is appreciated!

/soren

Hi,

Paraic OCeallaigh <par...@gm...> wrote:

> I have a fully working script but in the interest of catching something
> unexpected, I would like to catch any errors in the script itself and have
> it displayed in a infobox or similar, allowing the user to click OK and
> continue.
> Right now any errors I generate crash the script and are echoed to the
> command prompt. This is not desired as the script is a login menu which
> should not allow access to the shell. All others methods of getting to the
> shell have bee captured except these errors.

The normal approach would be something like:

  d = ...               # setup your Dialog instance

  try:
      all_the_rest()
  except:               # should be the same as "except BaseException:"
      d.msgbox(...)

This will even catch KeyboardInterrupt (generated when the Python script
receives SIGINT, typically when using Ctrl-C---but maybe dialog gets it
instead of python in this particular case, this is worth a little
check). If you don't want that, you can use "except Exception:" instead
of "except:". If you want to print some details about the problem, you
could catch the exception with "except BaseException as e:" or "except
Exception as e:" and use str(e) or something similar in the message to
be printed.

Of course, there are some kinds of error conditions that are likely to
prevent the script from printing the msgbox (e.g., if someone uninstalls
dialog while the script is running; hard disk corruption preventing
correct execution of dialog or Python; MemoryError...). It's a bit as if
taking "all" precautions not to fall when walking. Should an earthquake
start right under your feet, it would be difficult not to fall
nevertheless...

Regards


P.S.: if you really use your script as a login shell, I'm a bit
      surprised that you could obtain an interactive shell in case the
      script is terminated by an unhandled exception. I would rather
      expect you to get back to the login prompt. I assume you ran the
      program from an interactive shell rather than as a login shell, or
      that you are just concerned about the traceback being displayed on
      the terminal in case of an unhandled exception.

-- 
Florent

Hi all
I have a fully working script but in the interest of catching something
unexpected, I would like to catch any errors in the script itself and have
it displayed in a infobox or similar, allowing the user to click OK and
continue.
Right now any errors I generate crash the script and are echoed to the
command prompt. This is not desired as the script is a login menu which
should not allow access to the shell. All others methods of getting to the
shell have bee captured except these errors.

Any help appreciated.

Thanks
Paraic

Hi Paraic,

Paraic OCeallaigh <par...@gm...> wrote:

> Thank you for a very comprehensive answer. I have figured out the use
> of programbox and I am very pleased with the results.  Instead of
> filling the "args" option with specific commands I wrote a bash script
> and inserted that into the args and it outputs nicely into programbox
> with a few 'sleep' commands to make it readable.

Glad to see you managed to come up with something that works for you.

> One question I had was, there is an option to use colors
> ("--enable-colors") but I am unsure how to use it. Is there a chance
> to use it to format the output being displayed to programbox, if I
> wanted to put a certain color on one part of the text? I tried tput in
> the bash script and it just outputs the escape codes and doesn't add
> any color.

Where did you find --enable-colors? I only have --colors here. Is it a
typo?

It seems this option doesn't work with the programbox widget in dialog.
It does work with msgbox (in this particular case, but see below):

  dialog --colors --msgbox 'abc\Zb\Z1def\Znghi' 0 0

It also works in pythondialog:

  msg = r"Excellent! Press \Zb\Z1OK\Zn to see..."
  d.msgbox(msg, colors=True)

but it doesn't seem to work with programbox. Actually, it does for the
optional title but not for the piped output:

  echo 'abc\Zb\Z1def\Znghi' | \
  dialog --colors --programbox 'ABC\Zb\Z1DEF\ZnGHI' 0 0

*but* if I change the text to include spaces, as in:

  dialog --colors --msgbox 'Optional aaa\Zb\Z1title\Zn...' 0 0

or:

  echo 'abc\Zb\Z1def\Znghi' | \
  dialog --colors --programbox 'Optional aaa\Zb\Z1title\Zn...' 0 0

then I obtain something like this:

  Optio
  aaatitle

(where 'title' is in bold red, OK)

I just took the \Z* sequences from dialog(1), so maybe it is simply that
I don't understand the "grammar" of these escape sequences. Maybe you
can explain this? I don't know if these sequences correspond to a
well-known standard. They don't look like ANSI escape sequences at
least... Maybe their interpretation by dialog is buggy? I suggest you to
discuss this with Thomas Dickey, the dialog maintainer
(<http://invisible-island.net/dialog/dialog.html>).

> P.S os.system is gone now from my script! thanks for that.. :)

Good. :)
Since you said you were beginning with Python, I also wanted to point
you to the textwrap module which you may find helpful. Example:

  textwrap.fill(longString, width=79)

This may be useful if you have long lines that are truncated in the
output of programs you monitor. Although pretty simple to implement
oneself, textwrap.indent() is also very convenient for nice text
formatting.

I also wanted to say that if you don't want to bother with progressbox
or programbox in the middle of a pythondialog-based program and don't
care about visual unity, you can just print to the terminal between
dialog calls. If you want the program to wait for the user to press
Enter before proceeding to the next dialog, you can use
'input("Press Enter to continue...")' (the function was named
'raw_input()' in Python 2).

Regards

-- 
Florent

Hi Florent

Thank you for a very comprehensive answer. I have figured out the use
of programbox and I am very pleased with the results.  Instead of
filling the "args" option with specific commands I wrote a bash script
and inserted that into the args and it outputs nicely into programbox
with a few 'sleep' commands to make it readable.

One question I had was, there is an option to use colors
("--enable-colors") but I am unsure how to use it. Is there a chance
to use it to format the output being displayed to programbox, if I
wanted to put a certain color on one part of the text? I tried tput in
the bash script and it just outputs the escape codes and doesn't add
any color.

thanks

Paraic

P.S os.system is gone now from my script! thanks for that.. :)

-------

Hi,

Paraic OCeallaigh <paraic.iam@...> wrote:

> Thanks for a great product! I have several menu systems on many Linux
> servers using it in Production.

That's nice to hear, thank you.

> My issue:
> I am trying to use programbox to show a running display of a health check
> on a Linux box.
> I would run several os.system() commands such as service xxxx status and df
> and top etc whcih would append their stdout to a file in /tmp.
> I would like to see these commands send output to a programbox (or
> progressbox) either via some kind of pipe or tailing the file in /tmp.

First advice: don't use os.system() unless you have a compelling reason.
It does too many undesirable things like arguments splitting around
spaces and parameter expansion, that are completely unnecessary when
using Python (we have lists/sequences, no need to special-case the space
character, the ";", etc.) and often open your code to security problems,
unless you are very careful (using shlex.quote() or similar). I
recommend you to replace such calls with:
  - the glob module (glob.glob() or glon.iglob() typically) if you need
    to expand shell-style patterns;
  - the subprocess module for most cases where you need to run a
    separate program, capture its stdout/stderr output or feed him data
    via its stdin;
  - for complex cases where the subprocess module doesn't offer what you
    need, you can do the work by hand with os.fork() and os.execvp() (or
    os.execvpe() or... there are a few similar functions in the 'exec'
    family) + possibly os.dup2() to redirect stdin/out/err to a file or
    pipe, os.devnull/subprocess.DEVNULL, etc.). You can read
    Dialog._call_program() in dialog.py for an example of this, actually
    written before the subprocess module was born.

Using os.system(), very dangerous things can happen if your program
reads an argument such as "; rm -rf /;" from an untrusted source and
includes it in the command line. Variable/parameter expansions also
represent a high risk (for instance, I read that the Steam installer [a
shell script] ran a command equivalent to 'rm -rf /*' on customers'
systems because of some stupid "rm -rf "$VARIABLE/*" where $VARIABLE
happened to have an empty expansion. *** Don't use os.system()***. Write
convenience wrappers around 'subprocess' if you need, but don't use
os.system(). You will even gain in efficiency by not running unneeded
shell processes (in case you didn't realize, os.system() runs the
command via a shell, which is quite unneccessary in general).

************************************************************************
To address your question more specifically, I would need to know the
versions of Python and pythondialog you want this to work with, and how
precisely you want the output of the commands to be gathered and
displayed.
************************************************************************

First, if you want to run one programbox or progressbox per external
program (I suspect this is not what you want, but it is the simplest
approach, so let's start with it), the code running "find /usr/bin" in
demo.py (MyApp.programbox_demo()) is basically what you need, except you
can maybe simplify the /dev/null handling if you know the precise Python
versions you are targetting. Probably you'll want to use
'stderr=subprocess.STDOUT' in the subprocess call in order to see the
stderr output of external processes instead of it being thrown away.

OTOH, if you want to have one programbox or progressbox widget
continuously display the output of several commands, the best way would
probably be to:
  - create a pipe(7) whose reading end will be used by dialog for the
    whole widget life time, and whose writing end will receive the
    output of the programs, possibly mixed with output from your Python
    script;
  - start a child process (let's call it C1) with os.fork() that will
    inherit the file descriptor[1] corresponding to the writing end of
    the pipe, and use it to transmit the data you want to be displayed
    in the programbox or progressbox widget; each of the external
    programs will be started as a child process of C1, and C1 should
    wait(2) for the completion of every one of them;
  - in the main process, run d.programbox() or d.progressbox(), where d
    is your Dialog instance. This will last as long as there is at least
    one writer that hasn't closed the writing end of the pipe (a file
    descriptor can be duplicated with dup(2) [os.dup() in Python] and
    friends, as well as inherited by child processes upon fork(2)
    [os.fork() in Python]; each of these operations increases the
    "reference count" of the fd, which determines when the process
    reading from the pipe will see EOF instead of blocking in the
    read(2) system call, because this is when the "reference count" of
    the writing end of the pipe drops to 0 and all data previously in
    the pipe has been read that the reader process is told "there is no
    more data, this is over" [EOF]). Then your main process can wait for
    the child process C1 to exit.

[1] An integer, i.e., low-level (OS-level) "file", different from a
    Python file object. It is often a good idea to close the file
    descriptors you don't need in the child, e.g., the reading end of
    the pipe in C1. Sometimes, it is even necessary, otherwise some
    operation may block (writing end of the pipe in the main process,
    that would make the dialog reader process believe, if the fd were
    not closed, that there is still the possibility of data being sent
    through the pipe). Closing a file descriptor in a child does not
    close it for the parent; it just closes a duplicate fd, decrementing
    its "reference count".

This is exactly what MyApp.progressboxoid() in demo.py does, except that
instead of spawning child processes with their stdout and stderr file
descriptors assigned to the writing end of the pipe, it creates a Python
file object from the file descriptor corresponding to the writing end of
the pipe and writes to it as with any file object. This is the following
part of MyApp.progressboxoid():

   # Python file objects are easier to use than file descriptors.
   # For a start, you don't have to check the number of bytes
   # actually written every time...
   # "buffering = 1" means wfile is going to be line-buffered
   with os.fdopen(write_fd, mode="w", buffering=1) as wfile:
       for line in text.split('\n'):
           wfile.write(line + '\n')
           time.sleep(0.02 if params["fast_mode"] else 1.2)

(os.fdopen() can be replaced with open() in not-too-old Python versions,
but beware, arguments may vary slightly)

In order to start a child process from C1, running an external program
with its stdout and stderr redirected to the writing end of the pipe,
you could use something like:

  class YourException(Exception): # Name it appropriately (UnableToRunBlaBla...)
      pass


  program = "systemctl"
  args = [program, "status", "foobar.service"]
  try:
      with subprocess.Popen(args, stdin=subprocess.DEVNULL, stdout=write_fd,
                            stderr=subprocess.STDOUT,
                            universal_newlines=True) as proc:
          out = proc.stdout.read()
  except OSError as e:
      raise YourException(
          "unable to find or execute {0!r}".format(program)) from e

where 'write_fd' is the file descriptor corresponding to the writing
end of the pipe, cf. MyApp.progressboxoid().

Then you can inspect proc.returncode to determine the exit status of the
systemctl child process (if proc.returncode >= 0), or the signal that
killed him, if any (this is if proc.returncode < 0; the signal number is
-proc.returncode in this case).

There are very slightly shorter alternatives to subprocess.Popen() in
the subprocess module that are convenient in simple cases (run() in
Python 3.5 and later; otherwise, call(), check_output(), etc. but these
seem to be deprecated in Python 3.5). Anyway, subprocess.Popen() is the
most powerful one used as a basis for the others, it is not even
difficult to use, and not deprecated either.

I suggest you study MyApp.progressboxoid() and tell me precisely which
lines you don't understand. This may seem a bit complex at first, but it
is robust and uses resources efficiently. If you use pipes to transfer
the output of external programs to dialog, this output won't accumulate
in memory and your processes can run for years producing huge amounts of
data without any problem. This is essentially using the basic mechanisms
provided for this purpose by the OS (i.e., fork(2), exec(3) and
pipe(2)/pipe(7)). It is likely that the external programs you'll want to
run will differ very little if at all in the way they need to be
handled. Thus, you'll probably be able to use a common function or
method to handle all of them (this is essentially what pythondialog does
in dialog.py for the myriad of possible dialog commands, otherwise it
would be totally unmaintainable).

Note: you mentioned 'top'; in its default mode of operation, its output
      is probably unsuitable for sending to a pipe (except if it behaves
      differently when its stdout is not a terminal, this is possible).
      Probably something like "batch mode" (top's -b option) would be
      appropriate.

If you've followed this advice and still didn't manage to get something
working, post a minimal example of what you have tried.

> Would you be able to guide me on how best to do that and some sample code
> if possible? I looked at the demo.py and couldn't quite figure out the code
> to do it there. My python is still beginner-ish but very keen to learn.
>
> Any help appreciated

HTH :-)

-- 
Florent



On Wed, Nov 25, 2015 at 11:10 PM, Paraic OCeallaigh <par...@gm...>
wrote:

> Hi
> Thanks for a great product! I have several menu systems on many Linux
> servers using it in Production.
>
> My issue:
> I am trying to use programbox to show a running display of a health check
> on a Linux box.
> I would run several os.system() commands such as service xxxx status and
> df and top etc whcih would append their stdout to a file in /tmp.
> I would like to see these commands send output to a programbox (or
> progressbox) either via some kind of pipe or tailing the file in /tmp.
>
> Would you be able to guide me on how best to do that and some sample code
> if possible? I looked at the demo.py and couldn't quite figure out the code
> to do it there. My python is still beginner-ish but very keen to learn.
>
> Any help appreciated
>
> Paraic
>

Hi,

Paraic OCeallaigh <par...@gm...> wrote:

> Thanks for a great product! I have several menu systems on many Linux
> servers using it in Production.

That's nice to hear, thank you.

> My issue:
> I am trying to use programbox to show a running display of a health check
> on a Linux box.
> I would run several os.system() commands such as service xxxx status and df
> and top etc whcih would append their stdout to a file in /tmp.
> I would like to see these commands send output to a programbox (or
> progressbox) either via some kind of pipe or tailing the file in /tmp.

First advice: don't use os.system() unless you have a compelling reason.
It does too many undesirable things like arguments splitting around
spaces and parameter expansion, that are completely unnecessary when
using Python (we have lists/sequences, no need to special-case the space
character, the ";", etc.) and often open your code to security problems,
unless you are very careful (using shlex.quote() or similar). I
recommend you to replace such calls with:
  - the glob module (glob.glob() or glon.iglob() typically) if you need
    to expand shell-style patterns;
  - the subprocess module for most cases where you need to run a
    separate program, capture its stdout/stderr output or feed him data
    via its stdin;
  - for complex cases where the subprocess module doesn't offer what you
    need, you can do the work by hand with os.fork() and os.execvp() (or
    os.execvpe() or... there are a few similar functions in the 'exec'
    family) + possibly os.dup2() to redirect stdin/out/err to a file or
    pipe, os.devnull/subprocess.DEVNULL, etc.). You can read
    Dialog._call_program() in dialog.py for an example of this, actually
    written before the subprocess module was born.

Using os.system(), very dangerous things can happen if your program
reads an argument such as "; rm -rf /;" from an untrusted source and
includes it in the command line. Variable/parameter expansions also
represent a high risk (for instance, I read that the Steam installer [a
shell script] ran a command equivalent to 'rm -rf /*' on customers'
systems because of some stupid "rm -rf "$VARIABLE/*" where $VARIABLE
happened to have an empty expansion. *** Don't use os.system()***. Write
convenience wrappers around 'subprocess' if you need, but don't use
os.system(). You will even gain in efficiency by not running unneeded
shell processes (in case you didn't realize, os.system() runs the
command via a shell, which is quite unneccessary in general).

************************************************************************
To address your question more specifically, I would need to know the
versions of Python and pythondialog you want this to work with, and how
precisely you want the output of the commands to be gathered and
displayed.
************************************************************************

First, if you want to run one programbox or progressbox per external
program (I suspect this is not what you want, but it is the simplest
approach, so let's start with it), the code running "find /usr/bin" in
demo.py (MyApp.programbox_demo()) is basically what you need, except you
can maybe simplify the /dev/null handling if you know the precise Python
versions you are targetting. Probably you'll want to use
'stderr=subprocess.STDOUT' in the subprocess call in order to see the
stderr output of external processes instead of it being thrown away.

OTOH, if you want to have one programbox or progressbox widget
continuously display the output of several commands, the best way would
probably be to:
  - create a pipe(7) whose reading end will be used by dialog for the
    whole widget life time, and whose writing end will receive the
    output of the programs, possibly mixed with output from your Python
    script;
  - start a child process (let's call it C1) with os.fork() that will
    inherit the file descriptor[1] corresponding to the writing end of
    the pipe, and use it to transmit the data you want to be displayed
    in the programbox or progressbox widget; each of the external
    programs will be started as a child process of C1, and C1 should
    wait(2) for the completion of every one of them;
  - in the main process, run d.programbox() or d.progressbox(), where d
    is your Dialog instance. This will last as long as there is at least
    one writer that hasn't closed the writing end of the pipe (a file
    descriptor can be duplicated with dup(2) [os.dup() in Python] and
    friends, as well as inherited by child processes upon fork(2)
    [os.fork() in Python]; each of these operations increases the
    "reference count" of the fd, which determines when the process
    reading from the pipe will see EOF instead of blocking in the
    read(2) system call, because this is when the "reference count" of
    the writing end of the pipe drops to 0 and all data previously in
    the pipe has been read that the reader process is told "there is no
    more data, this is over" [EOF]). Then your main process can wait for
    the child process C1 to exit.

[1] An integer, i.e., low-level (OS-level) "file", different from a
    Python file object. It is often a good idea to close the file
    descriptors you don't need in the child, e.g., the reading end of
    the pipe in C1. Sometimes, it is even necessary, otherwise some
    operation may block (writing end of the pipe in the main process,
    that would make the dialog reader process believe, if the fd were
    not closed, that there is still the possibility of data being sent
    through the pipe). Closing a file descriptor in a child does not
    close it for the parent; it just closes a duplicate fd, decrementing
    its "reference count".

This is exactly what MyApp.progressboxoid() in demo.py does, except that
instead of spawning child processes with their stdout and stderr file
descriptors assigned to the writing end of the pipe, it creates a Python
file object from the file descriptor corresponding to the writing end of
the pipe and writes to it as with any file object. This is the following
part of MyApp.progressboxoid():

   # Python file objects are easier to use than file descriptors.
   # For a start, you don't have to check the number of bytes
   # actually written every time...
   # "buffering = 1" means wfile is going to be line-buffered
   with os.fdopen(write_fd, mode="w", buffering=1) as wfile:
       for line in text.split('\n'):
           wfile.write(line + '\n')
           time.sleep(0.02 if params["fast_mode"] else 1.2)

(os.fdopen() can be replaced with open() in not-too-old Python versions,
but beware, arguments may vary slightly)

In order to start a child process from C1, running an external program
with its stdout and stderr redirected to the writing end of the pipe,
you could use something like:

  class YourException(Exception): # Name it appropriately (UnableToRunBlaBla...)
      pass


  program = "systemctl"
  args = [program, "status", "foobar.service"]
  try:
      with subprocess.Popen(args, stdin=subprocess.DEVNULL, stdout=write_fd,
                            stderr=subprocess.STDOUT,
                            universal_newlines=True) as proc:
          out = proc.stdout.read()
  except OSError as e:
      raise YourException(
          "unable to find or execute {0!r}".format(program)) from e

where 'write_fd' is the file descriptor corresponding to the writing
end of the pipe, cf. MyApp.progressboxoid().

Then you can inspect proc.returncode to determine the exit status of the
systemctl child process (if proc.returncode >= 0), or the signal that
killed him, if any (this is if proc.returncode < 0; the signal number is
-proc.returncode in this case).

There are very slightly shorter alternatives to subprocess.Popen() in
the subprocess module that are convenient in simple cases (run() in
Python 3.5 and later; otherwise, call(), check_output(), etc. but these
seem to be deprecated in Python 3.5). Anyway, subprocess.Popen() is the
most powerful one used as a basis for the others, it is not even
difficult to use, and not deprecated either.

I suggest you study MyApp.progressboxoid() and tell me precisely which
lines you don't understand. This may seem a bit complex at first, but it
is robust and uses resources efficiently. If you use pipes to transfer
the output of external programs to dialog, this output won't accumulate
in memory and your processes can run for years producing huge amounts of
data without any problem. This is essentially using the basic mechanisms
provided for this purpose by the OS (i.e., fork(2), exec(3) and
pipe(2)/pipe(7)). It is likely that the external programs you'll want to
run will differ very little if at all in the way they need to be
handled. Thus, you'll probably be able to use a common function or
method to handle all of them (this is essentially what pythondialog does
in dialog.py for the myriad of possible dialog commands, otherwise it
would be totally unmaintainable).

Note: you mentioned 'top'; in its default mode of operation, its output
      is probably unsuitable for sending to a pipe (except if it behaves
      differently when its stdout is not a terminal, this is possible).
      Probably something like "batch mode" (top's -b option) would be
      appropriate.

If you've followed this advice and still didn't manage to get something
working, post a minimal example of what you have tried.

> Would you be able to guide me on how best to do that and some sample code
> if possible? I looked at the demo.py and couldn't quite figure out the code
> to do it there. My python is still beginner-ish but very keen to learn.
>
> Any help appreciated

HTH :-)

-- 
Florent

Hi
Thanks for a great product! I have several menu systems on many Linux
servers using it in Production.

My issue:
I am trying to use programbox to show a running display of a health check
on a Linux box.
I would run several os.system() commands such as service xxxx status and df
and top etc whcih would append their stdout to a file in /tmp.
I would like to see these commands send output to a programbox (or
progressbox) either via some kind of pipe or tailing the file in /tmp.

Would you be able to guide me on how best to do that and some sample code
if possible? I looked at the demo.py and couldn't quite figure out the code
to do it there. My python is still beginner-ish but very keen to learn.

Any help appreciated

Paraic

Hello,

I am pleased to announce the release of pythondialog 3.3.0. You can read
a summary of the changes in this version at:

  http://pythondialog.sourceforge.net/news.html#3.3

For your convenience, here is a text dump of this summary:

Main changes in version 3.3.0

   * The Python 2 backport has been updated to this version; it is now
     up-to-date.

   * Allow passing dialog arguments via a temporary file
     In order to prevent information leak through the process table
     (which normally shows all commands executed by any user, along with
     their arguments), pythondialog can now write dialog arguments to a
     temporary file and call dialog with the --file option to point him
     to this temporary file, where it will read the “real” arguments
     (such as --msgbox, box titles, messages to display in boxes, etc.).
     This new behavior is enabled by default starting from pythondialog
     3.3.0 if the dialog version is 1.2-20150513 or later. The Dialog
     class constructor accepts a new keyword-only argument,
     pass_args_via_file, that allows one to explicitly choose whether to
     use the feature or not.

     Dialog.setup_debug() offers a new expand_file_opt parameter to
     allow producing debug log files with full dialog commands as
     before, instead of dialog calls containing only one --file option
     followed by a path to a temporary file.

     Similarly, examples/demo.py accepts a new option (-E,
     --debug-expand-file-opt) to allow obtaining the same dialog
     commands as before in the file generated by --debug (i.e., with the
     --file options expanded instead of referring to the temporary
     files).

   * Bug fix in Dialog._dialog_version_check() (which is typically used
     to check whether a given widget is available in the selected dialog
     version): the message passed when raising InadequateBackendVersion
     had a hardcoded “the programbox widget” substring where it should
     have been using the feature parameter.

-- 
Florent

Hello,

I am pleased to announce the release of pythondialog 3.2.2. You can read
a summary of the changes in this version at:

  http://pythondialog.sourceforge.net/news.html#3.2

For your convenience, here is a text dump of this summary:

Main changes in version 3.2.2

    * The Python 2 backport has been updated to this version; it is now
      up-to-date.

    * Fix backend version check for buildlist, programbox, rangebox and
      treeview.

    * Bug fixes related to old versions of dialog (e.g., 1.1-20100428)
      and Python (3.0 and 3.1, untested on 3.0—please report if you care
      about this ancient version). Thanks to Jakub Warmuz for the report
      concerning old dialog versions.

      (This includes a fix for a crash in examples/demo.py when the
      dialog backend is too old to have the buildlist widget.)

-- 
Florent

Hi,

Jakub Warmuz <jak...@gm...> wrote:

> I did a quick test run of the letsencrypt client and I can now confirm
> that the problem has been fixed and everything else seems to work
> OK. Thank you for a very prompt response, great job!

I'm glad it works fine. Your report was useful, thank you.
Good luck with your project!

-- 
Florent

On Sat, Apr 04, 2015 at 10:17:55PM +0200, Florent Rougon wrote:
> I have uploaded version 3.2.2rc1 for both Python 3 (tested with Python
> 3.1 and 3.4) and Python 2 (tested with Python 2.6 and 2.7). All these
> work with dialog from Debian squeeze as well as unstable. Please test on
> your side and report.

I did a quick test run of the letsencrypt client and I can now confirm
that the problem has been fixed and everything else seems to work
OK. Thank you for a very prompt response, great job!

People working on the "dialog" part of the project will probably want
to make some more thorough testing of this new RC as soon as the time
allows it.

-- 
Kuba

Hello again,

I have merged all changes from the master branch into the py2 branch.
This means that the Python 2 backport should now have all improvements
that were made to the reference implementation since version 3.0.1,
including the "autowidgetsize feature".

I have uploaded version 3.2.2rc1 for both Python 3 (tested with Python
3.1 and 3.4) and Python 2 (tested with Python 2.6 and 2.7). All these
work with dialog from Debian squeeze as well as unstable. Please test on
your side and report.

Regards

-- 
Florent