I am building a program which helps in memory debugging of C programs. I call
execlp("gnome-terminal","gnome-terminal","-e",command,(char*)0);
to open a new terminal window where the program to be debugged runs. I do this to not have my debugging info intermixed with the users program output. Because I need to set up an environmental variable before running the users program, command var is actually the name of the shell script where I pass the users program as the first arg.
Here is my script:
#!/bin/bash
export LD_PRELOAD="./mylib.so"
$1
This works fine for programs with no arguments but what happens if the user also supplies args with his program?
For example I wish to call my script like that :
myScript.sh usersProgram arg1 arg2 etc
How can I correctly run the users program inside the script and pass all the arguments to it?
Thank you
Use "$#", which will handle all arguments properly.
Assuming that args to program always start from the 2nd arg, I'd suggest doing it like this:
#!/bin/bash
PROG=$1
shift
$PROG "$#"
Practically, just specifying "$#" instead of the three lines above will also work. But this way, you can easily do some manipulation based on $PROG before actually executing it.
Related
When trying to use the r or run commands in lldb I get an error like this: error: shell expansion failed (reason: invalid JSON). consider launching with 'process launch'.
It works when I just use process launch but I really do not feel like doing that.
Is there any way I could make either an alias or make shell expansions not fail?
The way lldb does shell expansion is to run a little tool called lldb-argdumper (it is in Xcode.app/Contents/SharedFrameworks/LLDB.framework/Resources on macOS) with the command arguments that you passed. lldb-argdumper wraps the contents of argv as JSON, and writes that to stdout. lldb then parses the JSON back into args and inserts the args one by oneinto the argc/argv array when it launches the process.
Something in the output is not getting properly wrapped. You can probably see what it is by looking at the output of lldb-argdumper with your arguments. Whatever it is, it's a bug, so if you can reproduce it please file with your example with http://bugs.llvm.org.
(lldb) command alias run-no-shell process launch -X 0 --
will produce an alias that doesn't do shell expansion. You can also put this in your ~/.lldbinit.
I ran into this recently. TL;DR: make sure your shell does not echo anything during initialization. Run <your-shell> -c date to confirm; only the date should be printed.
The problem was that my shell's initialization file was echoing some stuff, which was getting prepended to lldb-argdumper's JSON output. (lldb doesn't run lldb-argdumper directly; it invokes your default shell to run lldb-argdumper.)
Specifically, I use fish as my shell, which does not have separate initialization paths for interactive and non-interactive sessions. (See this issue for discussion of whether this is good.) bash and zsh have separate init files for interactive/non-interactive sessions, which makes avoiding this problem slightly easier.
I am writing scripts in tcl for a project I am working on.
I wanted to automate things as much as possible and wanted to not touch the source code of the script as far as possible. I want to run the main script file from a .bat or .job file sort of thing where I pass the command to execute the script along with the arguments.
I have referred to this post on stackoverflow:
How to run tcl script in other tcl script?
And have done pretty much the same thing. However, since my script is naked code rather than a single huge proc, I dont have the "args" parameter to read the arguments I wanted to pass.
For example, if script1.tcl is the main file containing the naked code, I want a file script2.job or script2.bat such that,
<command-to-run-script1.tcl> <mandatory-args> <optional-args>
is the content of the file.
Any suggestions on how I can implement the same?
To run a Tcl script, passing in some arguments, do:
tclsh script1.tcl theFirstArgument theSecondArgument ...
That's how it works in CMD scripts/BAT files on Windows, and in shell scripts on all Unixes. You might want to put quotes around some of the arguments too, but that's just absolute normal running of a program with arguments. (The tclsh might need to be tclsh8.5 or tclsh85 or … well, it depends on how it's installed. And script1.tcl might need to be a full path to the script.)
Inside the script, the arguments (starting at theFirstArgument) will appear in the Tcl list in the global argv variable. Note that this is not args, which is a feature of procedures. There are lots of ways of parsing the list of arguments, but any quoting supplied during the call itself should have been already stripped.
Here's a very simple version:
foreach argument $argv {
puts "Oh, I seem to have a >>$argument<<"
}
You probably need something more elaborate! There's many possibilities though, so be sure to be exact to get more focussed ideas.
If you're calling Tcl from another Tcl script, you need to use exec to do it. On the other hand, you can make things a bit easier for yourself in other ways:
exec [info nameofexecutable] script1.tcl theFirstArgument theSecondArgument ...
The info nameofexecutable command returns the name of the Tcl interpreter program (often tclsh8.5 or wish86 or …)
I want to invoke a C executable with two arguments both of type string from a script. Am working with busybox shell. There is a script that is called whenever a USB device is plugged. Now I want to invoke my C executable from that script. I tried calling it with /usr/bin/myExecutable param1 param2 & but no use. It is not being called. How can I invoke the C executable from the busybox shell script?
There could be many reasons behind this. I mean what myExecutable program does. Does
it print something on the standard output(terminal)or this program is written to do
some background job.
In any case we can check the status of the last command executed under shell. shell
store the information in the special variable $?. If the last command was successful
it would return 0 otherwise it would return >0.
If possible, please share the output of the following command from your machine.
$/usr/bin/myExecutable param1 param2 &
$echo $?
I'm working on an old C software. There is one ksh script which executes a C program, which then creates some other processes and ends. These processes remain alive.
I'm trying to set an environment variable inside my ksh script, so that it could be accessible in the newly created processes that are still alive.
I have tried this way :
#!/bin/ksh
VARIABLE=value
export VARIABLE
my_c_program
But that doesn't work... I have tried to :
change my ksh script to bash
create a wrapper script that creates and exports the variable and then executes the original ksh script (which just executes the C program)
sourcing my ksh script (or my wrapper script when trying with 2.) instead of executing
it
But nothing from that worked.
The only thing that works for now is when I explicitly, by hand, execute the command :
export VARIABLE
In the current bash terminal.
Why? Isn't it possible to do the export inside a script instead of doing it manually?
Everything is ok actually...
The fact is that the process I thought was the child of the C program executed in my ksh script was the child of another process executed before. The C program was just sending a message via shared memory to tell the other program to execute its child.
So indeed the environment variable never went from my C program to the other's child. The only time when I had that variable set in the child is when I executed the other program (the one which is the real parent of the child) in a shell where the variable was exported.
The code above looks correct and it should work. Another way to do it is:
VARIABLE=value my_c_program
which exports the variable just for the program. Afterwards, the variable will be set but other external processes don't get a copy.
So why doesn't your script work? It's hard to tell but here are some tips to debug the issue:
Use #!/bin/ksh -x to enable debug output. Save the output in a file and then grep VARIABLE to make see what happens with it.
Check for typos.
Another shell script is like an external process. So create a script
#!/bin/ksh
echo $VARIABLE
and call it instead of my_c_program just to make sure passing the variable on works.
Maybe the C does something unexpected. Use a debugger to make sure it does what you expect.
In linux, argc and argv count arguments in terminal. But in Windows, I can't find anywhere to put the second arguments. Actually every time when I run the program, it creates that ugly black window and I even have no chance to give any argument. So are these two variables useless in Windows platform? Or there's another way to use it?
If you start from the command prompt, you can give the arguments there.
Start menu -> run -> "cmd" -> "MyProgram.exe arg1 arg2"
If you start your program from the command line as in linux, you are still able to pass arguments. Also if you create a Shortcut to an .exe you can place arguments for it there.
The int main(int argc, char**argv) interface is defined by C standards, so if Windows claims to have a ISO C99 compliant language implementation it should accept them, at least on the command line.
argc and argv are very usefull if properly used as arguments of main(). Probably the mistake (from my assumption) you are doing is that you are double clicking the executable rather than running the exe in the console and hence you are not getting a chance for entering the second argument.
In case you have document which states the proper use of the executable, then is should be followed and in case you have the source then check in that what arguments the main accepts and provide them in the command prompt after the name of the executable.
myexe.exe arg1 arg2
You can also use them in windows. As it needs command line interface you can use cmd.
Just compile your program and run your program on cmd like this: "filename" "argument1" "argumrnt2"...
For eg:look here
you can use argc argv[] in windows also one option is save your program in the bin folder of your c compiler may be turbo c++ or code blocks or whatever
I uses code blocks then open your cmd move to bin folder usind cd command then compile your program using command gcc *.c it will give you a file named a.exe like in linux it gives a.out the for run you can use command simply
a "argument1" " argument2"...... OR
a.exe "argument1" " argument2"......
i prefers first obviously every one prefers short command
second option is set environment variable of c by process given below
1.copy address of bin folder of compile
2.open properties of "This pc" left side press advance sysytem settings
3.press environment variable
4.under user variables press new
5.put varible name as Path p capital value paste the address copied from bin
press ok ok ok
now you can save your program anywhere and compile and run using cmd
__________****ENJOY****_________________