One, apparently rare, limitation found using gtkwialog on systems that do not use bash as the underlying system shell /bin/sh
(and legacy gtkdialog has that limitation anyway)
I spent one hour tonight converting Precord to use gtkwialog -b. That went fine and worked perfectly when underlying system shell was bash (which is no big deal since old version worked under legacy gtkdialog too with bash as system shell...).
But when I changed /bin/sh to be dash, the legacy gtkdialog version simply couldn't work at all because Precord is written in bash and uses a great many bash export -f functions. That being of course known and expected... But:
Though all the <action> contructs in the gtkwialog -b version of Precord can all find these functions, there is one other construct that happens to be used in current Precord that also calls up one of the bash functions and that is the <input> tag in one of the entry widgets (which calls bash function DateFile1). Unfortunately, none of the code I have added helps with that <input> tag situation, so that is a current limitation. Indeed, despite studying the code, I frankly do not yet know how <input> calls up exported functions - it is certainly not via the system() call.
I can only surmise, from the complex code involved, that it directly reads the function code from the shell environment, via perhaps a gtk library call, and then sends that function code to be processed via the mechanisms I have optionally modified. If so, legacy gtkdialog <input> command processing may expect a shell to interpret the function via system(), which does of course only work if underlying system shell is bash. So calling bash functions from <input> constructs certainly won't work with legacy gtkdialog.
Unfortunately, if my surmise turns out to be correct, then because the execution of that bash exported function requires an instance of bash to be running, which isn't the case with the gtkwialog -a or -b mod glib async or sync calls either (which don't call up any shell process) then that construct simply cannot work whichever mode is used when bash is not the underlying system shell. It is a small limitation, but one that has to be borne in mind.
In summary:
Though gtkwialog -b (or -a) mode can be used to convert many or even most legacy gtkdialog apps to work with dash, it does currently have at least this one newly found limitation:
you cannot call bash functions from <input> tags, only from <action> tags if underlying system shell is dash. There may be similar limitation; just remember -a and -b modes are specifically mainly related to <action>tag commandline_string opertion
I will have to therefore make a slight modification to Precord to workaround that remaining dash-related issue.
The easiest way around this for new programs is to never use exported bash functions in <input> tags.
Example of code that will not work when dash is the system shell:
Here is a simple exemplar program that will work using /bin/sh as bash but not when /bin/sh is dash, despite gtkwialog -b being used. Doesn't work with legacy gtkdialog either of course, when /bin/sh is dash:
Code: Select all
#! /bin/bash
hello (){
echo "hello world"
}
export -f hello
export MAIN_DIALOG='
<vbox>
<entry>
<variable>ANYTHING</variable>
<input>hello</input>
</entry>
</vbox>
'
gtkwialog -b --program=MAIN_DIALOG
I'll write more on this limitation if I find more or any solution in code, but truthfully I think it probably has to be accepted as a limitation of both gtkdialog and gtkwialog. Fortunately, it is a limitation that can easy be avoided in the case of gtkwialog; not gtkdialog which cannot work at all with dash as system shell when bash exported functions being used anywhere.
Hopefully you understand what I'm talking about, but if not, just accept that as one limitation that has to be avoided if writing dash compatible apps in this manner.
I'm now looking through some other familiar bash/gtkdialog to see which will suffer from this limitation. I'll list any I've looked at here:
1. peasywifi, does not use <input> tags in the above manner so should convert nicely with gtkwialog -b for use with underneath dash shell (though its shebang would also need changed to #!/bin/bash for the exported functions to work.
2. My program cast2chrome should also convert nicely.
3. As fredx181 has I believe already proved, debdog-install (and xenialdog-install) should convert nicely (don't think these call exported functions anyway)
4. My program domyfile should convert nicely.
5. Despite being derived from Precord (albeit a long chain of ancestry) it looks like weX will convert nicely.
6. peasypdf should convert nicely (and probably most peasy apps).
7. ffconvert looks like it will convert okay.
Hmmm... I can't find any other problematic ones... only Precord... trust me to try to convert that first!
Quite a number of old Puppy util/apps don't use bash export -f at all, so they shouldn't generally need to be converted at all - just use gtkwialog in legacy mode (needs no switch for that).
Oh well, time will tell - I'll try converting cast2chrome next and come back to finish Precord later. If there is any particular app you'd like me to check (and maybe even convert), just let me know.
All going well with a couple of conversions in the next few days, I'll upload the source code to the DD organization github repository thereafter since I'm not planning any non-compatible changes if most basically converting fine.
wiak