Well, you need to specify the directory somehow, right? There is no such thing as a miracle. One way quite typical for Unix/Linux is putting many paths in the PATH environment variable, which I don't particularly like. Also, you need to understand, that some application can rely on the "working directory" of the application, but this is not the case on the Unix-like; the working directory is not included in the pass by default, that way many command lines look like "
./application_executable_module", with "
./". So you need to devise some method of setting the path to your batch file, such as set up by initial configuration or installation procedure which can prescribe the directory in some configuration file. You can find the configuration file location by the location of the main executable module of your entry assembly, that is, the executable directory. Please see the recipe in my recent answer:
How to find my programs directory[
^].
Also, you normally don't need to use "/bin/sh", which is in fact just another application, one of the command interpreters. Besides, its location is always included in the PATH environment variable. When you execute a shell script, you don't normally specify it, right? And this is because the shell application is prescribed in the script/batch file itself, like in this form: "
#!/bin/bash". So, you can do this instead:
test.StartInfo = new ProcessStartInfo("/usr/bin/R", "CMD BATCH /usr/Scripts/program /usr/Scripts/output");
In this code line, I just copied your command line broken into the name of main executable module of your application assembly and its command line parameters, with all your absolute path. In really functional applications, there are no cases when a hard-coded path can be useful, no matter it if is relative or absolute. The path should be always calculated during run time based on some configuration file(s), application location, user "special folders", etc.
—SA
Submit an article or tip