[Mono-devel-list] Re: [Gtk-sharp-list] kernel support.
dag at wieers.com
Tue Jun 17 17:03:54 EDT 2003
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
> 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:
> # Starts a CIL program whose name is patterned after the filename of
> # this script. The CIL program executed is "$0".exe.
> # 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
> file=`readlink -f "$file"`
> exec mono "$file.exe" "$@"
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
-- dag wieers, dag at wieers.com, http://dag.wieers.com/ --
[Any errors in spelling, tact or fact are transmission errors]
More information about the Mono-devel-list