GtkDialog - tips

[MochiMoppel]

<tree hover_expand="true" hover_selection="true">

hover_expand ? Since row expansion is not implemented in gtkdialog this should have no effect whatsoever. Does it work for you somehow?

[mister_electronico]

Sorry MochiMoppel ,I was looking for play around with different things and I forget to delete it.

It makes No sense, I was looking for how to put icons in the items when they come from a file.

Sorry

See you.

[technosaurus]

In case anyone is interested in adding some graphics to bash scripts:
https://developers.slashdot.org/story/1 ... s-for-bash

[Keef]

...and it works too. Not that I have the slightest idea what to do with it, but I can always stare at the demos.
It compiles on Quirky Xerus64 with just the addition of ftgl (from PPM). Also compiled on Slacko 571 (Sailor's recent offering) and also got ftgl from PPM. Other dependencies may be needed depending on your distro.

[wiak]

...and it works too. Not that I have the slightest idea what to do with it, but I can always stare at the demos.

You seem to be one of the few people that actually tests anything new Keef (at least that's the impression I sometimes get)! I had a look at the bash/opengl thing too, but opengl games type programming isn't of much use to me personally, and it seems to be a pretty straight binding from bash to opengl so main job would be learning opengl programming anyway, which I'm not likely to do. Wasn't sure why it was posted under GtkDialog tips - hoped it was an alternative bash to gtk widget kind of toolkit, but it isn't as far as I can see. I suppose was posted here because it is driven from bash, like gtkdialog is, so that would explain it.

wiak

[don570]

A warning when using notebook tabs in a gtkdialog app...

Let us say that you are using an Entry Widget in one tab of notebook,
and want to have a similar Entry Widget in another tab.....

You MUST use different variable names for each Entry Widget,
Otherwise confusing data will be passed to shell when exiting.

As example see PTM timer 2.2
http://murga-linux.com/puppy/viewtopic.php?t=112410

_________________________________________________________

[wiak]

The most frustrating/horrible aspect of gtkdialog (bash scripts embedding gtkdialog GUI constructs etc) is that it runs as a child process of the bash script and changes to variables in child processes do not get passed back by default to the parent bash process.

But worse than that, gtkdialog by default actually interacts with the underlying system shell (and not really the calling bash program), which, if its dash, for example, will muck most bash/gtkdialog programs up totally (since dash can't see exported bash functions often used in typical bash/gtkdialog scripts).

Hence, to get our typical bash/gtkdialog scripts to work as designed we are forced usually to make the default system shell /bin/bash, which limits the program's compatibility with other Linux systems such as pure Debian, slows down system startup scripts, and encourages us to often use unnecessarily bashisms in our script programs.

And then there is the program complexity resulting from the fact the dialog is just all held in an exported variable resulting in all the tricks required to use and process that. We get used to it... true... but hardly an ideal programming environment - more of a fudge.

And these real frustrations are on top of the clumsy pseudo-xml syntax.

But it works... and I do use it often and in terms of ease of use it becomes a matter of "what you are familiar with using"... Painful though, and needs so many 'work-arounds' especially for complex process handling if you don't want zombies left lying around.

wiak

[MochiMoppel]

The most frustrating/horrible aspect of gtkdialog (bash scripts embedding gtkdialog GUI constructs etc) is that it runs as a child process of the bash script

Horrible? Doesn't any program you start from a script run in a subshell? Gtkdialog doesn't really need a bash script to run but not using one ... well, this can be hell.

and changes to variables in child processes do not get passed back by default to the parent bash process.

Of course not. This would defeat one of the purposes of a subshell. Where does Linux allow you to change variables of a calling parent process from a subprocess? I sometimes like to do that but I understand that this is a no-go.

But worse than that, gtkdialog by default actually interacts with the underlying system shell (and not really the calling bash program), which, if its dash, for example, will muck most bash/gtkdialog programs up totally (since dash can't see exported bash functions often used in typical bash/gtkdialog scripts).

This is interesting. AFAIK gtkdialog uses sh. My system shell is bash, my script runs in bash, still gtkdialog would use sh in its <action> subshells.
What output do you get from this bash/gtkdialog script when you run it with a dash system shell?

Code: Select all

#!/bin/bash
echo '<button label="Print shell"><action>echo $0</action></button>'|gtkdialog -s

I would expect that the output is 'sh'.

[wiak]

Em... to be frank you sound a bit aggressive, and I'm not sure why or maybe it is just how your sharpness comes over to me.

Of course a child process cannot directly reflect its environment back to the parent. I'm a system level C programmer originally so yes I do know that much. I won't comment further why I find that truth a real pain when using bash/gtkdialog to start stop and pause processes with signals and so on. I simply find it a pain - you are welcome to find it not a pain.

This is interesting. AFAIK gtkdialog uses sh. My system shell is bash, my script runs in bash, still gtkdialog would use sh in its <action> subshells.

Yes, gtkdialog uses sh. Obviously if your system sh points to /bin/bash you have no problems with your bash/gtkdialog programs. But try your mm_view program, which I note you have written, on a Debian system, where sh points to dash. You will find it won't work and you'll have a hell of a job making it work aside from reconfiguring sh to point to bash, which most in the Debian world wouldn't want to do (or they would have bash configured as sh from the very start). I tend to use XenialDog, Puppy, Tiny Core and Slitaz in that order. I resign myself to having sh as link to /bin/bash, because it proves too painful writing bash/gtkdialog scripts to not use export -f bash function calls.

wiak

[MochiMoppel]

Obviously if your system sh points to /bin/bash you have no problems with your bash/gtkdialog programs.

Occasionally I do have problems as running sh linked to /bin/bash is not the same as running /bin/bash directly. Still not a big issue.

I resign myself to having sh as link to /bin/bash, because it proves too painful writing bash/gtkdialog scripts to not use export -f bash function calls.

Why would it be painful? You have options, and if you want to avoid quotation hell you could always use external script files, couldn't you?

[wiak]

Why would it be painful? You have options, and if you want to avoid quotation hell you could always use external script files, couldn't you?

Well, yes, I could use external script files instead, and quite a number of. bash/gtkdialog programmers on this forum, for example Zigbert, basically patterned external script functions as a much-copied Puppy utils programming style. With all due respect I happen to hate that style, preferring the much simpler to read single script with the functions inside it. The individual functions tend to be small and hardly invite individual modularisation, but certainly a single externally functions script would be an acceptable workaround. Another alternative is to call bash exported functions via bash -c, rather than directly, then it doesn't matter that system sh links to dash, but sometimes using bash shell calls like that causes problems and additional complexity, so, like most here, I take the lazy way out and make sh link to bash.

wiak

[wiak]

And the painful fact is, most puppy app/utils are not thus portable to other Linux distributions since pretty much everyone here is using export -f liberally whether their scripts are broken up into modular external scripts or not. So not portable to Slitaz, which by default, uses busybox ash for sh, and not as I said to Debian, which uses dash. Either you are forced to link sh to bash, or you'd have to rewrite the programs, which can be a major rewrite.

wiak

[wiak]

Had gtkdialog been itself created to use bash rather than sh the problem would not exist. Then it would indeed be sufficient to simply call gtkdialog from inside a bash script whether underlying sh was ash, dash, or some other Posix-complient shell only. But then bash required on system (which however is a simple addition to any system and no need to force sh to link to bash). But I believe Thunor wanted it to use sh, per its original design, advocating users could use painful bash -c constructs to work round the compatibility issues. Pity, I think though it does seem a fudge to force system sh calls via bash within gtkdialog itself, so no easy solution.

wiak

[MochiMoppel]

Had gtkdialog been itself created to use bash rather than sh the problem would not exist.

I would be happy had it been created to use at least the system shell, which apparently it does not.
My environment variable SHELL is assigned to /bin/bash. Gtkdialog doesn't care. It seems to be hardcoded to use sh. I don't speak C but you do. Maybe you can determine why gtkdialog insists on using sh.

[wiak]

Had gtkdialog been itself created to use bash rather than sh the problem would not exist.

I would be happy had it been created to use at least the system shell, which apparently it does not.
My environment variable SHELL is assigned to /bin/bash. Gtkdialog doesn't care. It seems to be hardcoded to use sh. I don't speak C but you do. Maybe you can determine why gtkdialog insists on using sh.

Well, gtkdialog does use the 'system' shell, which means it calls the shell via C 'system' call, but C system call means:

Code: Select all

#include <stdlib.h>
int system(const char *command);
Description
system() executes a command specified in command by calling /bin/sh -c command, and returns after the command has been completed.

What would fix the issues, when using gtkdialog with bash, would be if /bin/bash -c were directly used instead of /bin/sh -c and, yes, more flexibly, if gtkdialog would read in the shell environment variable SHELL and adjust the actual shell used with -c accordingly that would be close to ideal. But it doesn't do the latter.

As things stand, in gtkdialog you can call shell functions with either the function name only (as a string), which results in them being interpreted by /bin/sh -c as /bin/sh -c "function", or you call the function using bash -c "function", which results in them being interpreted by /bin/sh -c '/bin/bash -c "function"' (which is more than a bit messy and likely to have other side effects). Well using bash -c "string_containing_command" does work, so fact is, we should be writing our gtkdialog programs that way for portability (at least when the string includes a reference to a bash exported function), but no-one on Puppy hardly ever does.

Since gtkdialog using /bin/sh -c to access functions then to see functions exported by bash using export -f, /bin/sh needs to be a link to /bin/bash to work... (unless bash -c "" syntax used when required throughout the gtkdialog xml constructs).

wiak

EDITED to fix quote marks a little so as to be a bit more accurate.
I suppose I should really try a quick mod of gtkdialog since at a quick glance it does look like a few extra lines of C could read SHELL and use fork and exec to use whatever shell SHELL points to (using getenv in C) rather than system call with /bin/sh -c. However, I am injured and tired just now (difficult to sleep and concentrate) so not sure I will get round to that try. I'm only really guessing since my quick glance at the gtkdialog source code has been only that, but maybe just need a quick fix around line 585 of gtkdialog.c, but there may well be more to it.

https://github.com/01micko/gtkdialog/bl ... tkdialog.c

[wiak]

Effectively, you end up needing something like:

Code: Select all

execl("/bin/sh", "sh", "-c", command, (char *) NULL);

changed to

Code: Select all

execl("/bin/bash", "bash", "-c", command, (char *) NULL);

or whatever, say, SHELL says the shell should be.

But to be robust, there is more to it, cos the parent should then wait for the child process to terminate and more. Basically needs a new C function call, which is a modified copied of existing system.c (though a much simpler, few lines of code: check SHELL, fork, exec, as above would maybe do in practice...).

EDIT:

One potential problem might be that the shell executed might need to be passed an appropriate environment (variables) so other form of exec maybe needed (I don't know off the top of my head, but maybe execle or execve). One quick explanation of all these different exec calls is given on Wikipedia:

https://en.wikipedia.org/wiki/Exec_(system_call)

(I can't get that link to format properly as a url, sorry. url tags just make post invisible).

wiak

[wiak]

.

[step]

@wiak, I use the following scripting pattern to work around the lack of export -f in non-bash Bourne shells, and keep all sub-functions in a single file. As far as my testing goes, it works for dash, ash, bourne sh, and bash. It should work for ksh (untested). Save to file, chmod +x file, run: dash file, see:
hi
there
done

Code: Select all

sub_func() { foo; echo "$@"; }
foo() { echo $VARIABLE; }
VARIABLE=hi; export VARIABLE
#Main body
case $1 in
  @*) sub=sub_${1#@}; shift; $sub "$@"; exit $? ;; # relay sub_func'ions
  # add cases for typical script option parsing, i.e., --help, -x, etc.
esac
# ...
if true; then
  # call sub-function (fork)
  "$0" @func there
  # process $? from @func if needed
fi
# ...
echo done

I think this is more portable as far as gtkdialog scripting than changing the underlying system call. Of course, your gtkdialog XML needs to call "$0" @func instead of just "func". This pattern isn't specific to gtkdialog programming, it works for any script for which you want to keep exported functions inside the main file.

[wiak]

Ah yes, step, that's exactly the type of pattern I jotted down myself today as a workaround - i.e. using case just as you have done (almost... I put all my functions in a totally separate but single file). Better than tons of little external function scripts. Thanks.

The way you've organised it is much better than my rough draft though. I may well use what you suggest!

wiak

EDIT: Having said that, there is no reason I can see that modifying gtkdialog.c itself to use appropriate sh, as determined by SHELL variable contents, wouldn't likely be completely portable (though I don't know intracacies of ksh and so on, so I might be wrong). If so, these kind of workarounds would no longer be required.

[misko_2083]

Save to file, chmod +x file, run: dash file, see:
hi
there
done

Code: Select all

sub_func() { foo; echo "@"; }
foo() { echo $VARIABLE; }
VARIABLE=hi; export VARIABLE
#Main body
case $1 in
  @*) sub=sub_${1#@}; shift; $sub "$@"; exit $? ;; # relay sub_func'ions
  # add cases for typical script option parsing, i.e., --help, -x, etc.
esac
# ...
if true; then
  # call sub-function (fork)
  "$0" @func there
  # process $? from @func if needed
fi
# ...
echo done

Small typo @step
sub_func() { foo; echo "$@"; }

@wiak Is it safe to run any string from enviroment variable SHELL?