GtkDialog - tips

[wiak]

@step:

Just for anyone else reading your 'solution', you missed out a dollar on the first line; minor typo I realise but should be:

Code: Select all

sub_func() { foo; echo "$@"; }

Yes, I like this methodology; a pretty precise/neat way of re-calling the script (parent) from the child (such as gtkdialog) and using the parent script functions whilst appropriately shifting in the commandline parameters in the case statement. It was what I was looking for and wondering how to do it.

wiak

EDIT: @misko: Just noticed you sent same about $ missed out (which didn't anyway actually effect the operation of the program aside from the output text), sorry.

[wiak]

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

Yeah, well... that's a good point. It isn't of course. Hmmm, yes, that is a problem - only option I can think of would be that gtkdialog always execs /bin/bash -c rather than current /bin/sh -c but that would be crippling the use of gtkdialog in other shells... Oh well, step's solution and similar will have to do... Really it's a pity ash or dash or similar didn't just have that export -f functionality without needing the rest of bash bloat then this issue wouldn't arise.

EDIT: Hmmm (I hate to give up...) but you could pass in the name of the shell you want it to use, to gtkdialog as a command line argument...

wiak

[step]

wiak and misko_2083 thanks, typo fixed.

BTW, I find that this way of organizing code is useful also when scripting YAD buttons.

[wiak]

.

[technosaurus]

Weird, I swore it used popen instead of system.
Its been a while since I have used gtkdialog, but IIRC, you can put all the functions you would export via bashisms in a file and use that with the event file option ... I think it is -e.
(export -f is a bashism)
Jwm uses system also, we tried switch to fork/exec but it caused nuanced problems that i don't recall. Better to just put your functions in an event file.

Btw, you can do SHELL=/bin/bash && myprog

[wiak]

.

[wiak]

.

[wiak]

.

[fredx181]

Code:

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'd like to try. How can I apply step's workaround above in an existing gtkdialog script that has export -f functons like this ?

Code: Select all

func_test(){
....
....
}
export -f func_test

Fred

[wiak]

Something like this, Fred. In practice you might want to improve the quoting round $program.

I had /bin/sh -> dash when I ran this, but doesn't matter can be bash or ash etc.

Of course you can put the case statement higher up in the program so when it gets called to access functions later the variables don't actually need to be exported again...

wiak

Code: Select all

#!/bin/sh

#Functions
sub_now (){
   date > /tmp/date
}
#you avoid using export -f since a bashism

sub_filemanager (){
 pcmanfm &
}

#Variables
program="$0"; export program

script='
<vbox>
  <entry>
    <variable>ENTRY_DATE</variable>
    <input>cat /tmp/date</input>
  </entry>
  <button>
    <label>Refresh</label>
    <action>$program @now</action>
    <action>refresh:ENTRY_DATE</action>
  </button>
  <button>
    <input file stock="gtk-home"></input>
    <action>$program @filemanager</action>
  </button>
</vbox>'
export script

#Main body - this is step's main pattern along with recalling the script 
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

gtkdialog -p script

[step]

Here's another example

Code: Select all

#!/bin/dash
# or busybox sh/ash even bash

func_test() {
set -x
  yad --center --button=gtk-ok --buttons-layout=center "--text=
func_test arguments: $1, $2, $3
.  using exported variable: $VARIABLE
.  click OK to exit"
}

VARIABLE="hi there!"; export VARIABLE 

MAIN_DIALOG='
<window>
	<vbox>
	<frame Test>
			<hbox>
				<button>
					<label>Click me</label>
					<action>. "'"$0"'" @test 1 2 3</action>
					<action function="exit">Exit by button</action>
				</button>
			</hbox>
		<hbox>
			<button ok></button>
			<button cancel></button>
		</hbox>
	</frame>
	</vbox>
</window>
'
export MAIN_DIALOG

case $1 in
	-d | --dump) echo "$MAIN_DIALOG" ;;
	@*) sub=func_${1#@}; shift; $sub "$@"; exit $? ;; # relay func'tions 
	*) gtkdialog --program=MAIN_DIALOG ;;
esac 
echo done

[wiak]

@step: Something wrong with your code line:

Code: Select all

               <action>. "'"$0"'" @test 1 2 3</action> 

EDIT: @step: Sorry, FALSE ALARM... your code is working on my system now. My computer must have had an one two electron too many and gone on the blink...! But okay again now. Whew, what a relief... It was really weird though. I didn't change the code since; I just rebooted...
EDIT2: @step: Em no... your code really isn't working for me




It is not calling up yad via the func test as intended. Works the way I did it with program="$0"; export program, but I'd like to see what you intended above. i.e. works with:

Code: Select all

program="$0"; export program

Code: Select all

               <action>$program @test 1 2 3</action>

I have /bin/sh as dash currently.

gtkdialog doesn't seem to see $0 as the script name; rather it sees it as sh.

as you can find via:

Code: Select all

<action>echo $0 >/dev/tty</action>

Beats me currently why too... gtkdialog is pretty weird sometimes. If you ran
(inside the parent script) either:

Code: Select all

( echo $0 )

or

Code: Select all

sh -c "echo $0"

you would indeed get the name of the parent script...

I can't help thinking that gtkdialog 'weirdness' is also what caused my recent C programming fix attempt to fail. gtkdialog appears to somehow not be getting the parent environment inherited. weird, or what is it? Or maybe there is something wrong with my gtkdialog (I think I may have left in my recompiled one... oops... EDIT: no I didn't)

wiak

[misko_2083]

@wiak variable "$0" needs to be exported then
it will launch the script with exec:

Code: Select all

#!/bin/dash
# or busybox sh/ash/dash, unless this script really needs bash in which case
# stop now

func_test() {
set -x
  yad --center --button="gtk-ok":0 --buttons-layout=center --text="
func_test arguments: $1, $2, $3
.  using exported variable: $VARIABLE
.  click OK to exit"
}

VARIABLE="$0"
export VARIABLE
echo $VARIABLE

MAIN_DIALOG='
<window>
   <vbox>
   <frame Test>
         <hbox>
            <button>
               <label>Click me</label>
               <action>exec "$VARIABLE" @test 1 2 3 </action>
                <action function="exit">Exit by button</action> 
            </button>
         </hbox>
      <hbox>
         <button ok></button>
         <button cancel></button>
      </hbox>
   </frame>
   </vbox>
</window>
'
export MAIN_DIALOG

case $1 in
   -d | --dump) echo "$MAIN_DIALOG" ;;
   @*) sub=func_${1#@}; shift; $sub "$@"; exit $? ;; # relay func'tions
   *) gtkdialog --program=MAIN_DIALOG ;;
esac

echo done 

[wiak]

@wiak variable "$0" needs to be exported then
it will launch the script with exec:

Well, that's basically what I already said above misko. Variable needed exported, which is the way I did it in my program example (in post just before step's one), but why I'm wondering does step's own code not work?

Like I said if the script is made to contain line: sh -c "echo $0" the output of that is the parent script name (which is what I would expect), whereas echo $0 within gtkdialog is giving sh as the name (which I don't understand).

EDIT: @step: Sorry, FALSE ALARM... your code is working on my system now. My computer must have had an one two electron too many and gone on the blink...! But okay again now. Whew, what a relief... It was really weird though. I didn't change the code since; I just rebooted...
EDIT2: @step: Em no... your code really isn't working for me

wiak

[MochiMoppel]

I had /bin/sh -> dash when I ran this, but doesn't matter can be bash or ash etc.

If it matters or not depends very much on the function code. With this approach it is not possible to run a bash specific function from gtkdialog when the parent script is not called by bash. Following example works only with bash shebang. Even with #!/bin/sh is would choke on the cat statement with a syntax error and the whole script would crash. Commenting out this statement would at least start gtkdialog and would make all buttons (except first ) work.

The third button calls bash and instructs it to process external code. This should always work, no matter what shell the parent script or gtkdialog are using. IMO a strong point for using external code files when your goal is portability.

The 4th button calls external POSIX compliant code. No need for bash here. Gtkdialog's sh shell can handle this. Much more effient. Would be weird to call heavy bash from a light dash only to handle script that dash could process itself.

Code: Select all

#!/bin/bash
sub_bash_only (){ 
T="Bash function worked!"
cat <(echo "$T") | gxmessage -file - # <= This will crash script unless script is run in bash
} 
sub_posix (){ 
T="POSIX compliant function worked!"
gxmessage "$T"
} 
export program="$0" 
export MAIN_DIALOG=' 
<vbox>
<button label="Execute Bash function"> 
 <action>$program @bash_only</action> 
</button>
<button label="Execute POSIX compliant function"> 
 <action>$program @posix</action> 
</button>

<button label="Execute external bash code"> 
 <action>bash /tmp/bashfunction</action> 
</button>
<button label="Execute external POSIX code"> 
 <action>/tmp/posixfunction</action> 
</button>
</vbox>' 

case $1 in 
@*) sub=sub_${1#@}; shift; $sub "$@"; exit $? ;; 
esac

# Write file with bash code. No shebang
[ ! -e /tmp/bashfunction ]  && echo 'T="Bash file worked"; cat <(echo "$T") | gxmessage -file -' > /tmp/bashfunction  
[ ! -e /tmp/posixfunction ] && echo 'gxmessage "Posix file worked"' > /tmp/posixfunction && chmod +x /tmp/posixfunction
gtkdialog

[wiak]

With this approach it is not possible to run a bash specific function from gtkdialog when the parent script is not called by bash....Even with #!/bin/sh is would choke on the cat statement with a syntax error and the whole script would crash....

The third button calls bash and instructs it to process external code. This should always work, no matter what shell the parent script or gtkdialog are using. IMO a strong point for using external code files when your goal is portability.

Well the point of step's method here is that the original script is being called again later as if it is an external code file, so the methodology is independent of the underlying system shell. I'm not sure what you mean when you say "not possible to run a bash specific function from gtkdialog when the parent script is not called by bash". Certainly the main script needs #!/bin/bash first line if using bashisms but I presume that's not what you are meaning.

wiak

[wiak]

edit... things going wrong here... erased post cos was accidentally testing with /bin/sh -> bash when I thought I was using /bin/sh -> dash. Pity.

I think I need to sleep.

@step: Turns out your code example with
. "'"$0"'"
in the gtkdialog still isn't working for me, but my method is:

program="$0";export program

and then in the gtkdialog using

$program
instead of
. "'"$0"'"

but still I don't see why $0 not working in step's gtkdialog example. Note, "'"$0"'" works if /bin/sh -> /bin/bash in my tests but not if it is a link instead to dash. Please correct me if I am wrong...

wiak

[misko_2083]

@wiak variable "$0" needs to be exported then
it will launch the script with exec:

Well, that's basically what I already said above misko.

oops

@wiak variable "$0" needs to be exported then
it will launch the script with exec:

Variable needed exported, which is the way I did it in my program example (in post just before step's one), but why I'm wondering does step's own code not work?

wiak

Probaly because gtkdialog runs sh -c $0 ...
if the variable MAIN_DIALOG is modified then there is no need to export $0

Code: Select all

#!/bin/dash
# or busybox sh/ash/dash, unless this script really needs bash in which case
# stop now

func_test() {
  yad --center --button="gtk-ok":0 --buttons-layout=center --text="
func_test arguments: $1, $2, $3
.  using exported variable: $VARIABLE
.  click OK to exit"
}

VARIABLE="hi there!"
export VARIABLE

VAR="\'$0\' @test 1 2 3"

MAIN_DIALOG='
<window>
   <vbox>
   <frame Test>
         <hbox>
            <button>
               <label>Click me</label>
               <action>VAR</action>
                <action function="exit">Exit by button</action> 
            </button>
         </hbox>
      <hbox>
         <button ok></button>
         <button cancel></button>
      </hbox>
   </frame>
   </vbox>
</window>
'

case $1 in
   -d | --dump) echo "$MAIN_DIALOG" ;;
   @*) sub=func_${1#@}; shift; $sub "$@"; exit $? ;; # relay func'tions
   *) echo "$MAIN_DIALOG" | sed 's!VAR!'"$VAR"'!g' | gtkdialog -s ;;
esac

echo done

[wiak]

The third button calls bash and instructs it to process external code. This should always work, no matter what shell the parent script or gtkdialog are using. IMO a strong point for using external code files when your goal is portability.

Oh I see what you are getting at. Yes, external code files with or without bash in the command to access them works of course in terms of portability. However, was mainly just explaining how step's methodology worked in terms of using it with gtkdialog. It is up to the programmer to use correct #!/bin/dash or bash or sh at the top of the actual script. Certainly shouldn't be using #!/bin/sh if the code inside is actually using bashisms (even though that would still work on Puppy systems since /bin/sh is linked to bash there - that can't of course be relied on. So step's pattern is generally entirely portable in my opinion. Though I still don't see why his example isn't working with $0 used in his gtkdialog. I do of course understand why my example works with $program, but that is another matter.

wiak

[wiak]

.