I have a project that must hide a file into an image , first I used command prompt and it goes well. Now I am trying to apply this commands using C++ programming language, but each time it gives me that system can't find the specified path although it exists and work well using command prompt.
This my code:
system("cd\\"); \\access C
system("cd x"); \\X is name of folder in C
system("copy /b pic.jpg + file.rar NEWPICTURE.jpg");
This is the source of commands: http://www.instructables.com/id/How-to-Hide-Files-Inside-Pictures/
Every time you call system(), a new shell process is created to run that single command. When that shell exits, its local context, including working directory and environment variables, is lost. The next call to system() copies the context of the parent process (your program) all over again.
Your options are to pass a command list/pipeline to a single system() call, or to use functions that affect your own process context, such as chdir().
Related
I used system("source ~/.bash_profile") to reload it, but it does not work. Is there any other function or code to reload the bash with C++ program in linux?
The command source ~/.bash_profile works, if you're actually in the process running the bash shell you want to affect.
When you started your C++ program, that started up in a different process, a child of the bash process, and therefore unable to modify the environment of that bash process.
And, in fact, it's even worse than that since a system() call in a C++ program almost certainly runs another process to do that work, so it's twice removed from the bash process.
And, in fact, it's worse even than that, since source is a bash internal command, meaning you'd have to start up a bash shell to execute it :-)
Hence, what you end up with is the following hierarchy of processes, all of which can really only affect their own environment, not anything above them:
original-bash
|
C++-program
|
bash-run-by-system
So I'm trying to run a series of commands via using system(), however I noticed that changes don't carry on. For example, I define a variable p as user input set /p p=Enter name (or in powershell $p=Read-Input "Enter Name"
Now if I want to use P again, I use system("echo %p%") (or %p I forgot which), but p is undefined here since a new system call creates a new cmd call. I also tried system("CD test") yet the CD remains the same and doesn't change in the next system call.
How can I make sure the system calls use each others' variables and such?
Each call of system has it's own environment, by definition.
On Linux and Mac, you can use popen and MSVC has a similar _popen.
That said, Remy's comment is a viable alternative. You can still use system to start curl after you've called SetCurrentDirectory() from your own code. Your problem is that successive children don't inherit each others environment; they all inherit from the parent process (i.e. your C++ code). So get that parent right.
I have a simple program that reads in a basic config file which contains a user provided path. I'm trying to use that path to call system to execute a .bat that resides at the location provided. I'm able to pass the stored path directly into system and it attempts to run the .bat fine, but it needs to try and run it as an admin. I came across the following post: How to call system() in an opened administrator program and gives it the same privileges?
I'm building the string as indicated in the above post, but when I try and pass this new string into system, it tells me "The system cannot find the file specified". Here's the (most likely wrong) way I'm building the string that I pass into system.
std::string adminFilePath = "runas /user:<admin-user> \"";
adminFilePath.append(configFileSettings.path.c_str()); //Append the path of the file that we got from the config file.
adminFilePath.append("\"");
system(adminFilePath.c_str());
My assumption is that I'm should be trying to build a basic string representing what I'd type right into a cmd window to execute the .bat, but obviously I'm wrong somewhere.
Check file name, that you dont use single . Check current folder for program you'really running if path is relative Do not use system... especially if you have non-an so folder/file names. system () is ancient attempt to implement posix function and supports only ANSI and may be confused by modern quoted arguments as well. Use execve or spawn.
In fact, you can avoid running runas at all Requesting administrator privileges at run time
I have a fortran program in which I usually use scripts of commands, for example, in a terminal I write:
$program
then I enter into the program (the terminal shows "$program>") and accepts either commands or a script that I call by typing manually "#script":
$program>#script
then the fortran program opens the file named "script", which contains a series of commands or tasks that are executed.
What I want to do now is to type directly in a terminal:
$program #script
to run the program with the commands contained in the file "script".
I want to do this to be able to create sh scripts to run the program many times without having to enter into the program each time to write manually the name of each script.
Does anybody know how could I do this in fortran. I guess that the way is to start the fortran program by saying that if something was typed in a terminal after the name of the program, then the fortran program should be able to read it and use it internally. No matter which type of variable is given after typing "program", the program should be able to read it directly from the terminal. Any idea will be greatly appreciated.
Thanks in advance.
You may be able to do this:
program <<EOF
#script
EOF
Details may depend slightly on which shell you're scripting in, and on the details of the program you're trying to run.
Also, this is a shell scripting question, not much related to Fortran.
Fortran 2003 defines some intrinsics that allow you to retrieve the command line arguments provided to your executable.
The functions you are interested in are get_command_argument, command_argument_count and get_command.
get_command retrieves the entire command line.
command_argument_count returns an integer with the number of arguments passed on the command line.
get_command_argument gets the nth argument passed on the command line.
Note that this is functionality you'll need to add to your Fortran program, and if you do not have the ability to recompile it, then you cannot make this work using this approach.
In the case modifying the Fortran is not possible, then you may use programs such as expect which let you automate input into programs that provide prompting.
I am writing a bash script that runs a C++ program multiple times. I use getenv() and putenv() to create, get, and update environment variables in the C++ program. After the C++ program ends, the bash script needs to grab these variables and perform some basic logic. The problem is that when the C++ program exits, the environment variables disappear. Is there any way to permanently store these variables after the program's termination so that the bash script can use them? If not, what is the best way to share variables between a bash script and a C++ program? The only solution I can think of is writing output to files. I do not want to print this data in the console. Any help would be greatly appreciated.
Each process has its own copy of the environment variables, which are initialised by copying them from the parent process when the new process is launched. When you change an environment variable in your process, the parent process has no knowledge of this.
In order to pass back information from a child to a parent, you will need to set up some other kind of communications channel. It could be files on disk, or a pipe, or (depending on the capabilities of your parent, bash might not be able to do all this) shared memory or some other IPC mechanism. The parent program would then be responsible for changing its own environment variables based on information received from the child.
I personally have only ever been able to do this in 16-bit DOS assembler, by tracing the pointer to the previous process until it points at itself, which means that you've reached the first instance of COMMAND.COM, and then altered its environment manually.
If your program returned the variables via standard output as string, like this:
FOO=23; BAR=45;
Then, bash could call it like this:
eval `./your_program`
end $FOO and $BAR will be accessible to bash.
To test this try:
eval `echo "FOO=23; BAR=45;"`
echo "$FOO $BAR"
Of course, in this method the program does not change environment variables of calling process (which is not possible), but just returns a string that is then evaluated by bash and the evaluation sets the variables.
Do not use this method if your program processes input from not trusted source. If someone tricked your program to print "rm -rf /" to the standard output you would be doomed.
As far as i know under a "standard" GNU/Linux environment you can set environment variables in 3 ways:
using command line utilities like export
editing files like ~/.profile or ~/.bashrc for an user or the equivalent files under /etc for system
feeding temporary values to a command like this CXX=g++ CUSTOM_VERSION=2.5 command
the last one is usually used to customize builds and it's good because doesn't harm the system and does not interfere with any system settings or values or files and everything is back to normal after the execution of the command. It's the best way if you like to have a temporary modification for a particular set of variables.
There is no way for a program to set environment variables in its parent. Or, well, no legitimate way. Hacking into its process with ptrace does not count. :-)
What you should do is output the environment variables on standard output. Have the shell script read them and set them. If the environment variables are all that you output the call is very simple:
`program`
The back-ticks will capture the output of the program. Then it will replace the back-ticks with the output. Which will be commands to set shell variables. Then later in your shell script be sure to do:
export VAR1
export VAR2
You need the export commands in order to move them into the environment that is passed to programs launched from the shell.
You cannot set environment variables which survive the life-time of your process, so the easiest solution is to write to output files as you suggested or write to specific filehandles handed down from Bash:
C++:
int main (int argc, char* argv[])
{
// missing error handling
int fd = atoi(argv[1]);
const char* env = "BLAH=SMURF";
write(5, env, strlen(env));
return 0;
}
Bash:
# discard stdout and stderr, redirect 5 to stdout so that it can be captured
# and tell the process that it should write to 5 (the first 5)
VARIABLES=`./command 5 2>&1 1>/dev/null 5>&1`
This is probably a crack-pot idea but it should work :)