I'd like to wrap a MyBatScript.bat script inside a MyTest.exe. Then I'd like to invoke MyTest.exe with arguments, thus:
MyTest.exe arg1 arg2
format of passing arguments can be different if need be.
I'd like arg1 and arg2 to be passed on to MyBatScript.bat as %1 and %2 and MyBatScript.bat executed.
How Can I do this?
Thanks!
This depends entirely on which language you compile the .exe from. Here's an example using C#:
static void Main(string[] args)
{
StringBuilder buildArgs = new StringBuilder();
foreach(string arg in args)
{
buildArgs.Append(arg);
buildArgs.Append(" ");
}
System.Diagnostics.Process.Start(#"C:\MyBatScript.bat", buildArgs.ToString());
}
This would be the Main function of a ConsoleApplication.
Executing a batch file from within your EXE is really just invoking the cmd.exe program with the batch file as a parameter. You could therefor pass any additional parameters this batch file accept along as well.
Related
I have a premain as below for attaching an agent to a remote process.
public static void premain(String args, Instrumentation instrumentation) {
System.out.println("Premain");
File file ;
try {
file = (new File("Agent.jar"));
ByteBuddyAgent.attach(file,"18467");
}
catch (Exception e)
{
e.printStackTrace();
}
}
Here, I want to pass the process id and couple of other arguments. Is there anyway to do this. Looks like it takes one single argument.
java -javaagent:/path/to/agent.jar -cp jar-under-test.jar Foo.Main
How can i pass the argument here?
You would need to encode the argument in any manner you find appropriate. Instead of spaces as used for the arguments to main, use commas for example but escape all existing commas, for example by doubling them. In the agent, split by single commas and reverse the escaping for the resulting segments.
Is there a way to put a argument into a method in batch script? I know I can do that in java programming.
Example #1 (Java)
public class Test {
public static void main (String [] args) {
Test t1=new Test();
System.out.print(t1.method1(false));
}
public int method1 (boolean val1) {
if (val1==false) {
return 0;}
else {
return 1;}
}
}
I want to have something like this so when the method runs, depending on the argument, the method will produce varying results.
Example #2 (Batch - partial pseudocode)
:method1
::With an argument a1 (by default a1=1)
if %a1%==1 echo Option #1
if %a1%==2 echo Option #2
So when I call method1, depending on the argument, I could have two results.
Is there a way to do that? Or suggestions on how one method can have different results? Thanx
Try the inline help for the call built-in statement.
C:\>call /?
Calls one batch program from another.
CALL [drive:][path]filename [batch-parameters]
batch-parameters Specifies any command-line information required by the
batch program.
If Command Extensions are enabled CALL changes as follows:
CALL command now accepts labels as the target of the CALL. The syntax
is:
CALL :label arguments
A new batch file context is created with the specified arguments and
control is passed to the statement after the label specified. You must
"exit" twice by reaching the end of the batch script file twice. The
first time you read the end, control will return to just after the CALL
statement. The second time will exit the batch script. Type GOTO /?
for a description of the GOTO :EOF extension that will allow you to
"return" from a batch script.
<continutes>
Is there a way to get the command line arguments in go "tests",
When you call go test obviously your main is not run, so is there a way to process command line arguments,
One way would be to use the flags packages and check for the command line arguments in each test or function being tested, but that is not ideal for that you need to do this in lots and lots of places, unlike the way you to it just in main when you run the application.
One may think it is a wrong thing to do, and that it is against purity of unit-tests:
not all tests are unit tests
it is very functional not to rely on "ENV" variables and actually pass the stuff as arguments in command line,
For the record I ended up putting an init() function in one of my _test files, and set the variable that is set through flags when the main is called this way.
Environmental configs are best kept in environment variables, in my experience. You can rely on global variables like so:
var envSetting = os.Getenv("TEST_ENV")
Alternatively, if using flags is a requirement, you could place your initialization code inside a function called init().
func init() {
flags.Parse()
myEnv = *envFlag
// ...
}
An alternative approach is to make main() be a stub that merely calls into another function after arguments are processed by flag.Parse(), for example:
var flagvar int
func init() {
flag.IntVar(&flagvar, "flagname", 1234, "help for flagname")
}
func main() {
flag.Parse()
submain(flag.Args)
}
func submain(args []string) {
...
}
Then in your tests, flag variables can be set and arguments established before calling submain(...) simulating the command line establishment of flags and arguments. This approach can be used to maximize test coverage without actually using a command line. For example, in main_test.go, you might write:
func TestSomething(t *testing.T) {
flagvar = 23
args := []string{"a", "b", "c"}
submain(args)
...
}
You can directly test main function and pass arguments.
Simple example showing a flag, and a pair of positional arguments
Note: Do NOT call it 'TestMain' that has a special meaning to the testing framework as of Go 1.8.
package main
import (
"os"
"testing"
)
func TestMainFunc(t *testing.T) {
os.Args = append(os.Args, "--addr=http://b.com:566/something.avsc")
os.Args = append(os.Args, "Get")
os.Args = append(os.Args, `./some/resource/fred`)
main()
// Test results here, and decide pass/fail.
}
os.Args[1] = "-conf=my.conf"
flag.Parse()
Notice that the config file name is hard-coded.
What is the syntax I should use to make my Smart Device app written in.net CF 2.0 accept arguments, so I can start exe in he following manner:
Process.Start("IExplore.exe", "www.northwindtraders.com");
Should the Main() be modified?
If so, how?
Sure, you simply change Main to accept a string array input.
static void Main(string[] args)
{
// do stuff
}
I have a winform app that is writing to console and it seems to work well. I'm using this code:
AttachConsole(-1)
Console.Out.WriteLine("Hellow world")
FreeConsole()
The question is:
If I run the app's exe file from command line, and try to redirect the output into a file. It doesn't work.
For example:
C:\ > myapp.exe > c:\output.txt
I still get the output to console screen (c:\output.txt file is created but empty), but I want it to to be saved into c:\output.txt
What's going wrong ? How to do that?
Many thanks!
You can have your cake and eat it too if you first check if output was redirected. Here's a little helper class that contains the P/Invoke voodoo:
using System;
using System.Runtime.InteropServices;
public static class ConsoleEx {
public static bool OutputRedirected {
get { return FileType.Char != GetFileType(GetStdHandle(StdHandle.Stdout)); }
}
public static bool InputRedirected {
get { return FileType.Char != GetFileType(GetStdHandle(StdHandle.Stdin)); }
}
public static bool ErrorRedirected {
get { return FileType.Char != GetFileType(GetStdHandle(StdHandle.Stderr)); }
}
// P/Invoke:
private enum FileType { Unknown, Disk, Char, Pipe };
private enum StdHandle { Stdin = -10, Stdout = -11, Stderr = -12 };
[DllImport("kernel32.dll")]
private static extern FileType GetFileType(IntPtr hdl);
[DllImport("kernel32.dll")]
private static extern IntPtr GetStdHandle(StdHandle std);
}
Usage:
bool redir = ConsoleEx.OutputRedirected;
if (!redir) AttachConsole(-1);
// etc...
You are attaching to the parent process to provide output, which in your case is probably cmd.exe. The parent process' stdout stream has not been redirected and therefore continues to display the output on the screen.
I am not aware of a direct approach. If you do not call AttachConsole you will find that the redirect works as expected, but of course then you loose the option to have a console window. However, there is a work around that I think is reasonable.
If you want the output to go to a console window then you provide your application with a commandline switch that indicates this requirement, something like
C:\> myapp.exe /console
When the /console argument is present you call AttachConsole and the output will be written to the console. When this switch is not present you do not make the call to AttachConsole and you will be able to redirect the output to a file.