[Gtk-sharp-list] kernel support.

[Dag Wieers]

On 17 Jun 2003, Jonathan Pryor wrote:

> There's one problem with your proposed shell wrapper: it doesn't work
> correctly in the presence of symbolic links, since when invoking the
> symbolic link "$0" will be the name of the symbolic link, not the name
> of the *target* of the symbolic link.
> 
> MCS has a solution, but it depends on autoconf (mono's scripts/mcs.in
> file is processed, including the full path to mcs).  As such, it may be
> undesirable.
> 
> So, here's my attempted solution.  It checks for the presence of
> symlinks, and looks up the target of the symlink (using readlink) if
> necessary, before passing off the program to mono:
> 
>     #!/bin/sh
>     # Starts a CIL program whose name is patterned after the filename of
>     # this script.  The CIL program executed is "$0".exe.
> 
>     file=$0
> 
>     # If file is a symlink, find where it's pointing to
>     if [ -L $file ] ; then
>       if ! (readlink -f "$file") > /dev/null 2>&1; then
>         echo `basename "$0"` ": missing required program readlink!"
>         exit -1
>       fi
>       file=`readlink -f "$file"`
>     fi
> 
>     exec mono "$file.exe" "$@"
> 
> Thoughts?

You're right. I didn't think of that.

Maybe we'd better use the absolute path to the .Net binary. In that case I 
would even let the build-process write out this file as you mentioned for 
MCS. (Or the RPM SPEC file, as I'm doing currently.)

That was my first idea anyway, but I figured it could be more 
straight-forward by using $0.

PS Some binaries on your system don't work if you link to them, because 
they were designed that way. So I'm not sure whether that should work by 
design.

--   dag wieers,  dag@wieers.com,  http://dag.wieers.com/   --
[Any errors in spelling, tact or fact are transmission errors]