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

Forum Forums antiX-development Development Exported function does not work as expected in gtkdialog within bash script

  • This topic has 9 replies, 3 voices, and was last updated Sep 21-10:21 pm by skidoo.
Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • #67602
    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?

    #67603
    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 3 weeks, 3 days ago by Xecure.

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

    #67607
    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…

    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.

    #67612
    Member
    Xecure
    Helpful
    Up
    1

    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.

    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.

    #67615
    Member
    Robin
    Helpful
    Up
    0

    so I couldn’t understand what was going on.

    You describe exactly what I was experiencing…

    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.

    #67623
    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.

    #67645
    Member
    skidoo
    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.

    #67649
    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.

    #67652
    Member
    Xecure
    Helpful
    Up
    0

    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.

    #67660
    Member
    skidoo
    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.

Viewing 10 posts - 1 through 10 (of 10 total)
  • You must be logged in to reply to this topic.