tcl-mac

[MACTCL] getcwd

[Michael M. <mic...@na...>]

Can someone give me a quick pointer?  I have a Tcl/Tk script embedded in a C
program that's bundled as an OS X application.  I need to determine the full
path of where the application is located.  When I tried using the standard C
"getcwd" command to find the location of the app, I would expect it to
return "/Applications/MyApp.app/Contents/MacOS" or something similar.
Instead, it just returns "/".  Can someone tell me how to get the full path
of the current app?  I included sample code below for reference.

<-------- START FILE -------->
#include <stdio.h>
#include <unistd.h>

main()
{
    char str[120];
    getcwd(str, 120);
    printf("pwd = %s\n", str);
}
<--------- END FILE --------->

Please note that I'm an experienced UNIX/C programmer, but I don't know a
whole lot about building Mac OS X applications yet.

Re: [MACTCL] getcwd

[Benjamin R. <Ben...@ep...>]

Hi Michael,


Michael McFarlane <mic...@na...> writes:
> Can someone give me a quick pointer?  I have a Tcl/Tk script
> embedded in a C program that's bundled as an OS X application.  I
> need to determine the full path of where the application is located.

In C you are not supposed to do that.  There are frameworks to search
for your resources, and everything that you would want to find should
be either in your resource directory or not in your application bundle
in the first place.  For getting at resources see
<http://developer.apple.com/documentation/CoreFoundation/Reference/CFBundleRef/Reference/Introduction.html>.

If you still insist to navigate your application bundle yourself, the
functions from the process manager would also help:
<http://developer.apple.com/documentation/Carbon/Reference/Process_Manager/prmref_main/function_group_1.html>.

And than of course there is [info nameofexecutable].  And if you just
want to know where your script files are, evaluate [info script] at
the toplevel from within the script.

> When I tried using the standard C "getcwd" command to find the
> location of the app,

Getcwd() has nothing to do with the path of the application.  As in
all other OSs the working directory is freely changeable by the
program and its initial value is inherited from the parent.  You
probably know it better from [cd]/[pwd].


benny

[MACTCL] Execl

[Michael M. <mic...@na...>]

Does anyone know of a way to achieve the functionality of the Tclx =B3execl=B2
call on the Mac version of Tcl/Tk?  The execl call effectively replaces the
current Tcl/tk process with a new program as specified in the arguments for
the execl call.  This is precisely the behavior I=B9m seeking, but the Mac
version of Tclx apparently doesn=B9t implement this feature.

Thanks for any help or suggestions!
Mike M.

RE: [MACTCL] Execl

[Jeff H. <je...@ac...>]

exec .... &
exit

??

  Jeff Hobbs, The Tcl Guy, http://www.ActiveState.com/ 

Michael McFarlane wrote:


Does anyone know of a way to achieve the functionality of the Tclx "execl"
call on the Mac version of Tcl/Tk?  The execl call effectively replaces the
current Tcl/tk process with a new program as specified in the arguments for
the execl call.  This is precisely the behavior I'm seeking, but the Mac
version of Tclx apparently doesn't implement this feature.

Thanks for any help or suggestions!
Mike M.

Re: [MACTCL] Execl

[Michael M. <mic...@na...>]

What I'm doing, in a nutshell, is building a wrapper inside an application
bundle that accepts user inputs, then launches a new program based upon
those inputs while still running within the framework of the bundle.

I can do this with a shell script.  For instance, if I specify a shell
script as my CFBundleExecutable, and it contains the following lines:

    #!/bin/sh
    exec MyProgram

Then MyProgram will take over from the shell script and the O/S thinks that
all is still well with the app (icon stays in the dock, menus are still
active, etc.).  However, if my CFBundleExecutable is a Tcl/Tk script
containing the following:

    exec MyProgram &
    destroy .

Then MyProgram will launch just fine, but the "destroy ." command seems to
tell the O/S that the app has terminated.  In other words, the icon
disappears from the dock, menus go away, etc.

I think that execl would provide an equivalent to the shell "exec" command,
but unfortunately it's not implemented for the Mac.


On 2006-05-26 15:36, "Jeff Hobbs" <je...@ac...> wrote:

> exec .... &
> exit
> 
> ??
> 
>   Jeff Hobbs, The Tcl Guy, http://www.ActiveState.com/
> 
> Michael McFarlane wrote:
> 
> 
> Does anyone know of a way to achieve the functionality of the Tclx "execl"
> call on the Mac version of Tcl/Tk?  The execl call effectively replaces the
> current Tcl/tk process with a new program as specified in the arguments for
> the execl call.  This is precisely the behavior I'm seeking, but the Mac
> version of Tclx apparently doesn't implement this feature.
> 
> Thanks for any help or suggestions!
> Mike M.
> 
> 
> 
> -------------------------------------------------------
> All the advantages of Linux Managed Hosting--Without the Cost and Risk!
> Fully trained technicians. The highest number of Red Hat certifications in
> the hosting industry. Fanatical Support. Click to learn more
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
> _______________________________________________
> Tcl-mac mailing list
> Tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac

Re: [MACTCL] Execl

[Daniel A. S. <st...@ic...>]

Michael,

On 27/05/2006, at 7:06, Michael McFarlane wrote:

> What I'm doing, in a nutshell, is building a wrapper inside an  
> application
> bundle that accepts user inputs, then launches a new program based  
> upon
> those inputs while still running within the framework of the bundle.
>
> I can do this with a shell script.  For instance, if I specify a shell
> script as my CFBundleExecutable, and it contains the following lines:
>
>     #!/bin/sh
>     exec MyProgram
>
> Then MyProgram will take over from the shell script and the O/S  
> thinks that
> all is still well with the app (icon stays in the dock, menus are  
> still
> active, etc.).

this is because /bin/sh is not linked to higher level libraries and  
does not have any connection to the window manager when it execs; if  
it did, this would not work, c.f. below

> However, if my CFBundleExecutable is a Tcl/Tk script
> containing the following:
>
>     exec MyProgram &
>     destroy .
>
> Then MyProgram will launch just fine, but the "destroy ." command  
> seems to
> tell the O/S that the app has terminated.  In other words, the icon
> disappears from the dock, menus go away, etc.
>
> I think that execl would provide an equivalent to the shell "exec"  
> command,
> but unfortunately it's not implemented for the Mac.

that's incorrect, [execl] works just fine, but you need tcl  
configured --without-corefoundation (which will cause it not to work  
with TkAqua), or otherwise you need to [fork] before you [execl],  
c.f. example (1) below.

it is not possible on Mac OS X to replace an established GUI app with  
another one having the same windows & menus etc, due to the way the  
underlying services are implemented: an execve'd process does not  
inherit its parent's mach ports, which is how most IPC on Darwin  
works, in particular communication with the windowserver (or the  
CFRunLoop notifier in tcl configured --with-corefoundation).

AFAICS the only way to achieve something similar to what you want is  
to exec your CFBundleExecutable again from your main tk script e.g.  
with a cli arg indicating which of your subprogs to run (which will  
create a new instance of your app and you can then quit the first  
instance), you would then make your CFBundleExecutable a shell script  
that just looks at its cli arg and execs the corresponding sub  
program (or if there is no arg, your main tcl/tk script).

It appears that on Tiger you can do [package require Tk] from an  
unthreaded tclsh in both parent and child of a [fork], c.f. example  
(2), so that may be another way to get what you want if all your  
subprograms are tk scripts; but AFAIR this didn't work on earlier  
systems, see the list archive.
Note that you need an unthreaded tcl due to a generic deadlock issue  
with naked [fork] in threaded tcl on all platforms (missing  
pthread_atfork handling).

Cheers,

Daniel

-- 
** Daniel A. Steffen        Dept. of Mathematics  **
** Macquarie University     NSW 2109 Australia    **

------------------------- (1) --------------------
#!/bin/sh
#\
exec tclsh "$0" "$@"
package require Tclx
if {[fork]} {
	puts "parent"
} else {
	puts "child"
	execl /bin/sh {-c "echo subshell"}
}

------------------------- (2) --------------------
#!/bin/sh
#\
exec tclsh "$0" "$@"
package require Tclx
if {[fork]} {
	package require Tk
	tk appname parent
} else {
	package require Tk
	tk appname child
}

Re: [MACTCL] Execl

[Daniel A. S. <st...@ic...>]

On 27/05/2006, at 8:34, Daniel A. Steffen wrote:

> It appears that on Tiger you can do [package require Tk] from an  
> unthreaded tclsh in both parent and child of a [fork], c.f. example  
> (2), so that may be another way to get what you want if all your  
> subprograms are tk scripts; but AFAIR this didn't work on earlier  
> systems, see the list archive.
> Note that you need an unthreaded tcl due to a generic deadlock  
> issue with naked [fork] in threaded tcl on all platforms (missing  
> pthread_atfork handling).

of course I forgot that there is an issue even with unthreaded  
corefoundation tcl, because the CFRunLoop notifier implementation  
always uses a helper thread which does not survive fork. I have just  
committed a fix for this using a pthread_atfork handler to reinstall  
the notifier in the child after the fork:
	http://sourceforge.net/tracker/index.php? 
func=detail&aid=923072&group_id=10894&atid=310894
Note that pthread_atfork() is available starting with OS X 10.4 Tiger  
only, so tcl built on earlier releases will not include this fix.

Because vfork() is used by the core on OS X (since it always execve's  
after a fork), the atfork handler does not run for [exec] and [open  
|], i.e. core commands don't get any performance impact; the handler  
only gets called when an extension/embedder calls fork() directly,  
such as TclX's [fork].

On Tiger, this now makes [fork] safe to use from tcl with --disable- 
threads irrespective of corefoundation configuration option; but it  
doesn't fix the generic stale locked mutex issue with threaded tcl  
and fork discussed in the bug above, so threaded CF tcl can still  
deadlock in the child if any locks are held in the parent at the time  
of the [fork]...

Cheers,

Daniel

-- 
** Daniel A. Steffen        Dept. of Mathematics  **
** Macquarie University     NSW 2109 Australia    **

Re: [MACTCL] Execl

[Michael M. <mic...@na...>]

Daniel, thanks a lot for the responses.  I can see from your responses that
I'm out of my league here, so I'll come up with a plan B.


On 2006-05-27 00:43, "Daniel A. Steffen" <st...@ic...> wrote:

> 
> On 27/05/2006, at 8:34, Daniel A. Steffen wrote:
> 
>> It appears that on Tiger you can do [package require Tk] from an
>> unthreaded tclsh in both parent and child of a [fork], c.f. example
>> (2), so that may be another way to get what you want if all your
>> subprograms are tk scripts; but AFAIR this didn't work on earlier
>> systems, see the list archive.
>> Note that you need an unthreaded tcl due to a generic deadlock
>> issue with naked [fork] in threaded tcl on all platforms (missing
>> pthread_atfork handling).
> 
> of course I forgot that there is an issue even with unthreaded
> corefoundation tcl, because the CFRunLoop notifier implementation
> always uses a helper thread which does not survive fork. I have just
> committed a fix for this using a pthread_atfork handler to reinstall
> the notifier in the child after the fork:
> http://sourceforge.net/tracker/index.php?
> func=detail&aid=923072&group_id=10894&atid=310894
> Note that pthread_atfork() is available starting with OS X 10.4 Tiger
> only, so tcl built on earlier releases will not include this fix.
> 
> Because vfork() is used by the core on OS X (since it always execve's
> after a fork), the atfork handler does not run for [exec] and [open
> |], i.e. core commands don't get any performance impact; the handler
> only gets called when an extension/embedder calls fork() directly,
> such as TclX's [fork].
> 
> On Tiger, this now makes [fork] safe to use from tcl with --disable-
> threads irrespective of corefoundation configuration option; but it
> doesn't fix the generic stale locked mutex issue with threaded tcl
> and fork discussed in the bug above, so threaded CF tcl can still
> deadlock in the child if any locks are held in the parent at the time
> of the [fork]...
> 
> Cheers,
> 
> Daniel