Problem with .net app under linux, doesn't work from shell script

Question

I'm working on a .net post-commit hook to feed data into OnTime via their Soap SDK. My hook works on Windows fine, but on our production RHEL4 subversion server, it won't work when called from a shell script.

#!/bin/sh
/usr/bin/mono $1/hooks/post-commit.exe "$@"

When I execute it with parameters from the command line, it works properly. When executed via the shell script, I get the following error: (looks like there is some problem with the process execution of SVN that I use to get the log data for the revision):

Unhandled Exception: System.InvalidOperationException: The process must exit before getting the requested information.
  at System.Diagnostics.Process.get_ExitCode () [0x0003f] in /tmp/monobuild/build/BUILD/mono-1.9.1/mcs/class/System/System.Diagnostics/Process.cs:149
  at (wrapper remoting-invoke-with-check) System.Diagnostics.Process:get_ExitCode ()
  at SVNLib.SVN.Execute (System.String sCMD, System.String sParams, System.String sComment, System.String sUserPwd, SVNLib.SVNCallback callback) [0x00000]
  at SVNLib.SVN.Log (System.String sUrl, Int32 nRevLow, Int32 nRevHigh, SVNLib.SVNCallback callback) [0x00000]
  at SVNLib.SVN.LogAsString (System.String sUrl, Int32 nRevLow, Int32 nRevHigh) [0x00000]
  at SVNCommit2OnTime.Program.Main (System.String[] args) [0x00000]

I've tried using mkbundle and mkbundle2 to make a stand alone that could be named post-commit, but I get a different error message:

Unhandled Exception: System.ArgumentNullException: Argument cannot be null.
Parameter name: Value cannot be null.
  at System.Guid.CheckNull (System.Object o) [0x00000]
  at System.Guid..ctor (System.String g) [0x00000]
  at SVNCommit2OnTime.Program.Main (System.String[] args) [0x00000]

Any ideas why it might be failing from a shell script or what might be wrong with the bundled version?

Edit: @Herms, I've already tried it with an echo, and it looks right. As for the $1/hooks/post-commit.exe, I've tried the script with and without a full path to the .net assembly with the same results.

Edit: @Leon, I've tried both $1 $2 and "$@" with the same results. It is a subversion post commit hook, and it takes two parameters, so those need to be passed along to the .net assembly. The "$@" was what was recommended at the mono site for calling a .net assembly from a shell script. The shell script is executing the .net assembly and with the correct parameters, but it is throwing an exception that does not get thrown when run directly from the command line.

Edit: @Vinko, I don't see any differences in the environment other than things like BASH_LINENO and BASH_SOURCE

Edit: @Luke, I tired it, but that makes no difference either. I first noticed the problem when testing from TortoiseSVN on my machine (when it runs as a sub-process of the subversion daemon), but also found that I get the same results when executing the script from the hooks directory (i.e. ./post-commit REPOS REV, where post-commit is the above sh script. Doing mono post-commit.exe REPOS REV works fine. The main problem is that to execute, I need to have something of the name post-commit so that it will be called. But it does not work from a shell script, and as noted above, the mkbundle is not working with a different problem.

Answer 1

Just a random thought that might help with debugging. Try changing your shell script to:

#!/bin/sh
echo /usr/bin/mono $1/hooks/post-commit.exe "$@"

Check and see if the line it prints matches the command you're expecting it to run. It's possible your command line argument handling in the shell script isn't doing what you want it to do.

I don't know what your input to the script is expected to be, but the $1 before the path looks a bit out of place to me.

Answer 2

Are you sure you want to do

/usr/bin/mono $1/hooks/post-commit.exe "$@"

$@ expands to ALL arguments. "$@" expands to all arguments join by spaces. I suspect you shell script is incorrect. You didn't state exactly what you wanted the script to do, so that does limit our possibilities to make suggestions.

Answer 3

Compare the environment variables in your shell and from within the script.

Answer 4

Try putting "cd $1/hooks/" before the line that runs mono. You may have some assemblies in that folder that are found when you run mono from that folder in the shell but are not being found when you run your script.

Answer 5

After having verified that my code did work from the command line, I found that it was no longer working! I went looking into my .net code to see if anything made sense.

Here is what I had:

        static public int Execute(string sCMD, string sParams, string sComment,
                                  string sUserPwd, SVNCallback callback)
        {
            System.Diagnostics.Process proc = new System.Diagnostics.Process();
            proc.EnableRaisingEvents = false;
            proc.StartInfo.RedirectStandardOutput = true;
            proc.StartInfo.CreateNoWindow = true;
            proc.StartInfo.UseShellExecute = false;
            proc.StartInfo.Verb = "open";
            proc.StartInfo.FileName = "svn";
            proc.StartInfo.Arguments = Cmd(sCMD, sParams, sComment, UserPass());
            proc.Start();
            int nLine = 0;
            string sLine = "";
            while ((sLine = proc.StandardOutput.ReadLine()) != null)
            {
                ++nLine;
                if (callback != null)
                {
                    callback.Invoke(nLine, sLine);
                }
            }
            int errorCode = proc.ExitCode;
            proc.Close();
            return errorCode;
        }

I changed this:

            while (!proc.HasExited)
            {
                sLine = proc.StandardOutput.ReadLine();
                if (sLine != null)
                {
                    ++nLine;
                    if (callback != null)
                    {
                        callback.Invoke(nLine, sLine);
                    }
                }
            }
            int errorCode = proc.ExitCode;

It looks like the Process is hanging around a bit longer than I'm getting output, and thus the proc.ExitCode is throwing an error.

Answer 6

It is normal for some processes to hang around for a while after they close their stdout (ie. you get an end-of-file reading from them). You need to call proc.WaitForExit() after reading all the data but before checking ExitCode.