Exported function does not work as expected in gtkdialog within bash script

[Member Robin]

Hello,

After switching the translation-info script from yad to gtkdialog I am facing problems running functions defined in the script from within the dialog action tag. The problem can get boiled down to the following:

#!/bin/bash

export testlabel="Leafpad"
export somefile="some.txt"

function foo {
leafpad $1
}
export -f foo

export MAIN_DIALOG='
<window>
	<vbox>
		<hbox>
			<text>
				<label>"Test exported function"</label>
			</text>
			<button>
				<label>'$testlabel'</label>
				<action>'foo' '$somefile'</action>
			</button>
			<button cancel></button>
		</hbox>
	</vbox>
</window>'
gtkdialog --program MAIN_DIALOG

exit 0

Result:
sh: 1: foo: not found

Tried also the other valid method mentioned in the manuals to invoke gtkdialog:

I=$IFS; IFS=""
for STATEMENTS in  $(gtkdialog --program MAIN_DIALOG); do
  eval $STATEMENTS
done
IFS=$I

Same result.

Let me say: I’s not about using leafpad, which could very well get written directly into the action tag, but it’s about the ability to use functions defined in the same script as the gtkdialog in which they are expected to get called. The command is simply not found, even though gtkdialog is started from within the script and should be a child process, inheriting all the exported variables and functions. In case of variables this works as you can see, but for the functions it fails, the moment gtkdialog is involved.

For comparison countercheck e.g. with Roxterm:

#!/bin/bash

function foo {
leafpad $1
}
export -f foo

roxterm

exit 0

Enter foo into the open Roxterm window, and this will launch leafpad as expected. So what is wrong with gtkdialog? Is this misbehaviour eventually restricted to the version we use in antiX? On stackexchangeI’ve read this is supposed to work. The more when using it from within the same script rather than having to source it from a second one as in the example found in the linked question.

I already tried to solve this by testing any sensible way of quoting the command within the action tag, all in vain.

Any explanation?
Any way to make this work on antiX?
Or is this not restricted to antiX (or debian) at all, as the example (from stackexchange) and reading manpages makes me believe?

Windows is like a submarine. Open a window and serious problems will start.

[Member Xecure]

Helpful

Up

1

::

GTKdialog cannot read exported functions at all. Maybe in the past it worked, with a “bash -c ‘foo'” command (based on the documentation), but it has never done it for me. I was so frustrated with it a went to search for a different tool and ported dialogbox from qt4 to qt5 and built it for antiX (and thanks to anticapitalista got it accepted and included in the repos).

It uses more resources than gtkdialog (40 MBs of RAM vs 10) and takes a bit longer to load (we are talking 1-3 seconds in extremely limited CPUs less than 1GHz), but it has everything I wanted working (except for tables and scrollable frames).

Going back on topic, if you want gtkdialog to communicate with functions (and bash -c “function_name parameter” doesn’t work, have the functions run in a separate script, like if it was a library, and that should work (like calling an external script as you call commands, possibly with full path).

• This reply was modified 1 year, 7 months ago by Xecure.

antiX Live system enthusiast.
General Live Boot Parameters for antiX.

[Member Robin]

Helpful

Up

0

::

Many thanks for your hints, @Xecure. I was already at the point of biting in my keyboard, mostly thinking I was too dimwitted for this only. It feels good to read I was not the only one getting frustrated from the ignorance of this piece of software…

Xecure wrote:

GTKdialog cannot read exported functions at all.

This is a bad joke isn’t it?

So I have just tested this dirty workaround to manage things within a single script anyway. Works as expected now, but you’ll have to mask all special characters while writing the code of the function, and export them in the truest sense of the word, which means: to another file.

#!/bin/bash

export testlabel="Leafpad"
export somefile="some.txt"

# function foo workaround
echo -e "#!/bin/bash\nleafpad \"\$1\"\n" > test.sh
chmod 755 test.sh

#function foo {
#leafpad $1
#}
#export -f foo

export MAIN_DIALOG='
<window>
	<vbox>
		<hbox>
			<text>
				<label>"Test exported function"</label>
			</text>
			<button>
				<label>'$testlabel'</label>
				<action>"/bin/bash test.sh $somefile"</action>
			</button>
			<button cancel></button>
		</hbox>
	</vbox>
</window>'
gtkdialog --program MAIN_DIALOG

rm -f "test.sh"

exit 0

This is what I call a really dirty workaround for something what should clearly work straight, as the manual shows.

Do you happen to know whether dialogbox you mentioned is in the repos only or is it included by default in antiX 21 ISO so I could use it for the script?

——————-
Addendum: This will probably work with cat using a here-document as well. In this case no masquerading is needed. I’m just checking.

Windows is like a submarine. Open a window and serious problems will start.

[Member Xecure]

Helpful

Up

1

::

Robin wrote:

I was already at the point of biting in my keyboard, mostly thinking I was too dimwitted for this only.

I was also questioning my knowledge and capacity when I was working with gtkdialog. The thing is that older versions seemed to work (based on documentation and internet posts), so I couldn’t understand what was going on.

Robin wrote:

Do you happen to know whether dialogbox you mentioned is in the repos only or is it included by default in antiX 21 ISO so I could use it for the script?

Not included by default, only (maybe) in the runit version (the runit-service-manager script forces dialogbox’ installation).

antiX Live system enthusiast.
General Live Boot Parameters for antiX.

[Member Robin]

Helpful

Up

0

::

Xecure wrote:

so I couldn’t understand what was going on.

You describe exactly what I was experiencing…

Xecure wrote:

Not included by default,

Then I’ll have to stick to gtkdialog and use my dirty workaround.

I have checked this meanwhile, the here-document works fine. This is probably the easiest way to replace the exported functions, nothing has to be masked and the original code meant for the function can mostly get used unchanged. Here is what works finally:

#!/bin/bash

export testlabel="Leafpad"
export somefile="some.txt"

export tempfile_01="/tmp/gtkdialog-bug-$$01.tmp"

# Dirty workaround for exported functions not available in gtkdialog for some reason
cat <<<'#!/bin/bash
leafpad "$1"
' > "$tempfile_01"
chmod 755 "$tempfile_01"

export MAIN_DIALOG='
<window>
	<vbox>
		<hbox>
			<text>
				<label>"Test exported function"</label>
			</text>
			<button>
				<label>'$testlabel'</label>
				<action>"/bin/bash $tempfile_01 $somefile"</action>
			</button>
			<button cancel></button>
		</hbox>
	</vbox>
</window>'
gtkdialog --program MAIN_DIALOG

rm -f "$tempfile_01"

exit 0

Many thanks for your support, Xecure! I’d never figured that fast, that it wasn’t me but the dialog application itself, which stops the show…

————-
Supplement: In case there are static variables (which are not subject of change within the gtk-dialog) used within the function, and you want to avoid exporting all of them for this workaround to be available in the temporary extra script, you’ll have to qoute them double+single within the here-document, so their values get written into it. e.g.

cat <<<'#!/bin/bash
leafpad "'$somefile'"
' > "$tempfile_01"
chmod 755 "$tempfile_01"

This is instead of exporting all the static variables or using positional parameters to transfer them one by one. In this case “‘$somefile'” will get expanded to some.txt while writing the temp-script.
————-
2nd. Supplement: Also all the gettext ($) markers are to be double+single quoted each,along with their respective strings, to get accepted by the .pot string extraction tools while preparing the translation set. E.g. the original line
--button=$"Display local Information":3 --button=$"Procede":5 --button=$"Cancel":7
is to look like this after the preparation for gettext.
--button="'$"Display local Information"'":3 --button="'$"Procede"'":5 --button="'$"Cancel"'":7
In the temporary script, created from this on runtime, they will look »normal« again, just like in the original line. I noticed it is not necessary to include the two settings TEXTDOMAINDIR= and TEXTDOMAIN= into the temporary script using the reference from the original script. Obviously the translations present in the main script’s translation files (.mo) will be used anyway.

Windows is like a submarine. Open a window and serious problems will start.

[Member Xecure]

Helpful

Up

0

::

Good you found a workaround.

I just gave up on gtkdialog. I was also looking for something that would update the dialog’s content when interacting with it (and not have to launch a new window each time). Now I just accept yad’s limitations and build around it (as it is included in antiX by default), and when I want more interaction or better control on the design, use dialogbox.

There isn’t much interest in GUI interfaces for shell scripts (people push to learn to program and use “proper languages and libraries” like C, C++ or python). Not much we can do about it.

antiX Live system enthusiast.
General Live Boot Parameters for antiX.

[Anonymous]

Helpful

Up

0

::

Does the tiny dialogbox package depend on (m)any additional Qt packages?
If not, and dialogbox is currently absent from the antiX21 sysV init beta2, someone please post in the betatesting topic to request its inclusion.

gtkdialog. The thing is that older versions seemed to work (based on documentation and internet posts)

What (in the year 2020) compelled the puppylinux woofCE crew to merge this commit?
github.com/woodenshoe-wi/gtkdialog/commit/7e6d56…

Those puppy -inherited docs, dating back prior to Debian dropping gtkdialog (after the “lenny” release), did presume a scenario wherein the system is configured to use bash, vs {dash,ash,sh}, as its “default, non-interactive, shell” interpreter. The puppy default, non-interactive, shell interpreter is “sh”. Under recent versions of antiX + Debian, it is “dash”.

https://sources.debian.org/src/gtkdialog/2:0.7.20-4/src/main.c/#L445
https://manpages.debian.org/bullseye/dash/dash.1.en.html
https://manpages.debian.org/bullseye/manpages-dev/system.3.en.html

the issue at hand :
When the system() call within gtkdialog’s main.c “shells out to” a (non-interactive) dash environment, the expected bash -exported envvars [[[for some reason]]] are unset… and the necessary (and expected) “bash parameter//variable expansion” when evaluating the passed-in “MAIN_DIALOG=” cannot be performed.

Does abiding the patched puppylinux docs//examples solve the problem?
^—> Within in the bash shell script, place the “export” subsequent to the statement in which the expansion is performed.

[Member Xecure]

Helpful

Up

0

::

So, this is a problem with POSIX compliant shells, which do NOT export functions (and only variables)? And gtkdialog is built thinking only in POSIX compliance in mind?

The linked for the examples fix doesn’t work (adding the export after };). They must have made some change in the gtkdialog source code or a change made in the past in the current gtkdialog in antiX/MX is to blame for the problem.

antiX Live system enthusiast.
General Live Boot Parameters for antiX.

[Member Xecure]

Helpful

Up

0

::

Anonymous wrote:

Does the tiny dialogbox package depend on (m)any additional Qt packages?

All dependencies are already installed (shares many dependencies with repo-manager, packageinstaller and gazelle installer).

Still, I think including it isn’t that great of an idea, taking into account that antix-base needed to “slim down” and qt5ct is nt included there, so the theming is a mess for qt5 apps.

If at some point gtk2 is removed from Debian completely and gtkdialog cannot survive the change, then porting all gtkdialog apps to dialogbox would be the best move, though it will take some effort and it will impact resource use (though gtk3 apps already use more RAM than gtk2, so any change would still “fatten” the apps.

antiX Live system enthusiast.
General Live Boot Parameters for antiX.

[Anonymous]

Helpful

Up

0

::

If at some point gtk2 is removed from Debian completely and gtkdialog cannot survive the change, then

FWIW, puppians have already modified their “version” of gtkdialog to support gtk3. As of my last check (Dec 2020), they were the only ones to have done so. Searching pkgs.org and repology.org will find the other distros (PCLinuxOS, gentoo) who are still providing a gtkdoalog package.

[Author]

Posts