So basiclly im trying to use this:
int main()
{
system("adb kill-server \n"
"adb devices \n"
"adb start-server & \n"
"var=$(adb shell \"pidof com.rok\")\n"
"AFTER=`echo $var | sed 's/\\r//g'`\n"
"echo \"$AFTER\"\n"
"adb shell \"kill -STOP $AFTER\"\n"
"adb shell sleep 2\n"
"adb shell \"kill -CONT $AFTER\"");
return 0;
}
thing is this works in Clion without any error, but i must do this in visual studio and in visual studio i cannot do it like that i have to do every system command alone like:
system("adb kill-server");
system("adb devices");
system("adb start-server");
system("var=$(adb shell \"pidof com.rok\")");
system("AFTER=`echo $var | sed 's/\\r//g'`");
system("adb shell \"kill -STOP $AFTER\"");
so now the thing is when i run it like this everything works except this two lines:
system("var=$(adb shell \"pidof com.rok\")");
system("AFTER=`echo $var | sed 's/\\r//g'`");
even though they perfectly works on clion they dont in visual studio, i cannot find a way to solve this problem, this is the error:
'var' is not recognized as an internal or external command,
operable program or batch file.
'AFTER' is not recognized as an internal or external command,
operable program or batch file.
can anyone explain why this happens? and how can i solve this problem?
Each call of system() creates it's own shell as a subprocess, that's why multiple subsequent system() calls don't work if you e.g. try to set shell variables or do a cd command (expecting subsequent commands running in a specific directory).
The easiest way to do it, is to create a little temporary script file containing all the commands and execute this one with a single system() call:
// A raw string literal to make escaping easier
// (see https://en.cppreference.com/w/cpp/language/string_literal)
std::string cmds = R"xxx(
adb kill-server
adb devices
adb start-server &
var=$(adb shell "pidof com.rok")
AFTER=`echo $var | sed 's/\r//g'`
echo "$AFTER"
adb shell "kill -STOP $AFTER"
adb shell sleep 2
adb shell "kill -CONT $AFTER"
)xxx";
std::ofstream cmdFile("tempCmdFile.cmd");
cmdFile << cmds;
cmdFile.close();
system("tempCmdFile.cmd");
You probably should tidy up the tempCmdFile.cmd up afterwards (i.e. remove it). But I hope you grasp what the code above does.
Also I am not so sure that
AFTER=`echo $var | sed 's/\r//g'`
will work in a windows shell, as you expect it to do. You probably need a different solution for that, or a *nix like shell to run it (e.g. MinGw provides one).
Related
TL;DR; I guess the shell that std::system use, is sh. But, I'm not sure.
I tried to print the shell, using this code: std::system("echo $SHELL"), and the output was /bin/bash. It was weird for me. So, I wanted to see, what happens if I do that in sh? And, the same output: /bin/bash. Also, if I use a command like SHELL="/usr/bin/something", to set the SHELL variable to another string, it will print the new string that I set to it (/usr/bin/something), and it looks it's not a good way to see what shell it's using. Then, I tried to check it, using the ps command, and the output was: bash, a.out, ps. It was weird to see bash in this list. So, I created a custom shell, and change the shell in gnome-terminal to it:
#include <iostream>
int main()
{
std::string input;
while (true)
{
std::string command;
std::getline(std::cin, command);
std::system(command.c_str());
}
}
Now, it's easier to test, and I think, the results is better.
Then, I tried to test the ps command again, but in the custom shell, and the results was: test_shell, ps.
It was weird again. How the shell isn't sh, nor bash? And, the final test I did was: echo $0. And, the results was sh, in both custom shell, and normal program.
Edit
It seems like /bin/sh is linked to /bin/bash (ll /bin/sh command's output is /bin/sh -> bash), and actually, it seems like the only difference between sh and bash is filename, and the files's contents are the same. I checked the difference between these files with diff command too:
$ xxd /bin/sh > sh
$ xxd /bin/bash > bash
$ diff sh bash
(+ Yes, $SHELL doesn't means the running shell (I didn't know that when I was testing, and I just wanted to see what happens))
The GNU sources (https://github.com/lattera/glibc/blob/master/sysdeps/posix/system.c) say
/bin/sh
So, whatever /bin/sh is hardlinked to is the shell invoked by std::system() on Linux.
(This is correct, as /bin/sh is expected to be linked to a sane shell capable of doing things with the system.)
According to cppreference.com, std::system
calls the host environment's command processor (e.g. /bin/sh, cmd.exe, command.com)
This means the shell used will depend on the operating system.
On any POSIX OS (including Linux), the shell used by std::system is /bin/sh. (Though as the OP points out, /bin/sh could be a symlink to another shell.)
As for the SHELL environment variable, as has been pointed out in the comments, this environment variable cannot be used to reliably identify the running shell program. SHELL is defined by POSIX to
represent a pathname of the user's preferred command language interpreter
(source)
Working on a C++ Unix program executed on the command line (MacOs).
I call system("history -s SOMETHING") in it to add SOMETHING to the history of the user's shell, but I guess the call is opening a new sub-shell.
My question is : can I execute the system call on the "current" shell (the one used to run the program) ?
To be clear I want to find the SOMETHING in my shell history when I quit the program.
Thanks !
As far as I know, it's not possible in general.
If you're using bash, and since this is only for you:
Enable history appending in .bashrc:
shopt -s histappend
Launch a login bash shell in main:
system("bash -li -c 'history -s SOMETHING'");
and then refresh your history:
history -n
The history -n can be automated - you can execute it inside your prompt, for instance.
Figuring out how to do that left as an exercise.
(Disclaimer: I have only tried this in Ubuntu under the Windows Subsystem for Linux, but it should work very similarly on a Mac.)
It isn't possible. The usual work around -- not applicable if there is other wanted output -- is to make your program prints the wanted command and then execute it. For instance
#include <iostream>
int main() {
std::cout << "history -s SOMETHING\n";
return 0;
}
and then
eval $(/path/to/my/exe)
For ease of use, you can put that in a shell function
myfn() {
eval $(/path/to/my/exe)
}
that you can simply use
myfn
I do this:
popen("xterm -e ' some bash script ' ","r");
and it works fine if I launch my application from a terminal command line.
but if I double click in the finder to launch it (i.e. non terminal), the application runs, but the xterm doesn't appear.
(xterm is maybe not the right solution on osx, what I want to do is to open a terminal from popen, interact with the user inside the terminal, and return the result of this interaction to the main program)
The output shown in xterm's window (or likely other terminals) will not be read by popen, so that part is unclear. However, you say that works from a terminal window.
Another problem is that the DISPLAY variable needed to run xterm may not be set in the environment where the finder is running. You can work around that by adding a suitable -display option to the command-line. For instance, if your application is running and displaying on the local machine (likely), you could try
popen("xterm -display :0.0 -e ' some bash script ' ","r");
When capturing output from xterm, there are two types of output to consider:
error messages from xterm itself are written to the standard error
the program running inside xterm, e.g., 'some bash script', will write to the xterm window.
For your example, you could capture the error messages in the pipe (from popen directly by redirecting the standard error in the command to xterm's standard output, e.g.,
popen("xterm -display :0.0 -e ' some bash script ' 2>&1 ","r");
Capturing the output of the bash script is harder. You could redirect the output of the bash script itself, e.g.,
popen("xterm -display :0.0 -e ' some bash script >mylogfile ' ","r");
but that interferes with interaction. A better solution might be to use the script program, doing something like this:
popen("xterm -display :0.0 -e script mylogfile ' some bash script ' ","r");
In Applescript, I have the following:
do shell script "/Applications/Vidalia.app/Contents/MacOS/Vidalia"
do shell script "/Applications/Firefox_3.6/Firefox.app/Contents/MacOS/firefox-bin -P Anon"
It works perfectly, but the issue is that it will wait for Vidalia to be CLOSED before it will then launch Firefox. I would like to open both at the same time with one script. I don't really understand the language and all of my searching has turned up nothing. How can I get these open simultaneously? That is the point, after all.
Any help is much appreciated.
Try using the open command to launch the applications:
do shell script "open /Applications/Vidalia.app"
do shell script "open /Applications/Firefox_3.6/Firefox.app --args -P Anon"
With do shell script, AppleScript will wait for the response of the process you're running. As you're calling it, there's no option but to wait for the process to terminate, which is when the application closes.
To solve this, you need to replace your shell commands with ones that provide no response and terminate right away. So try this:
do shell script "/Applications/Vidalia.app/Contents/MacOS/Vidalia &> /dev/null & /Applications/Firefox_3.6/Firefox.app/Contents/MacOS/firefox-bin -P Anon &> /dev/null &"
I didn't test this with the applications you're using, as I have neither installed; instead, I tested with iTunes and Bento, with which it worked as you're hoping.
I have a extremely complicated shell script, within which it calls a C++ program I want to debug via GDB. It is extremely hard to separate this c++ program from the shell since it has a lot of branches and a lot of environmental variables setting.
Is there a way to invoke GDB on this shell script? Looks like gdb requires me to call on a C++ program directly.
In addition to options mentioned by #diverscuba23, you could do the following:
gdb --args bash <script>
(assuming it's a bash script. Else adapt accordingly)
There are two options that you can do:
Invoke GDB directly within the shell script. This would imply that you don't have standard in and standard out redirected.
Run the shell script and then attach the debugger to the already running C++ process like so: gdb progname 1234 where 1234 is the process ID of the running C++ process.
If you need to do things before the program starts running then option 1 would be the better choice, otherwise option 2 is the cleaner way.
Modify the c++ application to print its pid and sleep 30 seconds (perhaps based on environment or an argument). Attach to the running instance with gdb.
I would probably modify the script to always call gdb (and revert this later) or add an option to call gdb. This will almost always be the easiest solution.
The next easiest would be to temporarily move your executable and replace it with a shell script that runs gdb on the moved program. For example, in the directory containing your program:
$ mv program _program
$ (echo "#!/bin/sh"; echo "exec gdb $PWD/_program") > program
$ chmod +x program
Could you just temporarily add gdb to your script?
Although the answers given are valid, sometimes you don't have permissions to change the script to execute gdb or to modify the program to add additional output to attach through pid.
Luckily, there is yet another way through the power of bash
Use ps, grep and awk to pick-out the pid for you after its been executed. You can do this by either wrapping the other script with your own or by just executing a command yourself.
That command might look something like this:
process.sh
#!/usr/bin/env bash
#setup for this example
#this will execute vim (with cmdline options) as a child to bash
#we will attempt to attach to this process
vim ~/.vimrc
To get gdb to attach, we'd just need to execute the following:
gdb --pid $(ps -ef | grep -ve grep | grep vim | awk '{print $2}')
I use ps -ef here to list the processes and their arguments. Sometimes, you'll have multiple instances of a program running and need to further grep down to the one you want
the grep -ve grep is there because the f option to ps will include the next grep in its list. If you don't need the command arguments for additional filtering, don't include the -f option for ps and ignore this piece
grep vim is where we're finding our desired process. If you needed more filtering, you could just do something like grep -E "vim.*vimrc" and filter down to exactly the process that you're trying to attach to
awk '{print $2}' simply outputs just the process' pid to stdout. Use $1 if you're using ps -e instead of ps -ef
My normal setup is to run such script that starts my process in 1 tmux pane and having typed something similar to the above in a bottom pane. That way if I need to adjust the filtering (for whatever reason), I can do it pretty quickly.
Usually though, it will be the same for a specific instance and I want to just attach automatically after its been started. I'll do the following instead:
runGdb.py
#!/usr/bin/env bash
./process.sh &
PID=$(ps -ef | grep -ve grep | grep -E "vim.*vimrc" | awk '{print $2}')
#or
#PID=$(ps -e | grep vim | awk '{print $1}')
gdb --pid $PID
This assumes that the original process can be safely run in the background.