I have inherited an ANSI C++ program that: has no GUIs and is supposed to run in batch mode, generating lots of data (we are talking 100,000+ ASCII files). We are thinking that in long term we’ll run it under UNIX. For now, I have a MacBook Air running OS X 10.9.4 and I loaded Xcode 5.1.1. It compiles without errors or warnings.
I need to test a program as follows:
<prompt> myprogram datain dataout1 datout2
Where is the compiled program? In which directory? Can I copy my datain file in that directory?
For repeated execution under Windows (Command Prompt window) I normally would have a batch file of the type:
myprogram datain1 dataout11 datout12
myprogram datain2 dataout21 datout22
myprogram datain3 dataout31 datout32
........
myprogram datainn dataoutn1 datoutn2
Can I do something similar with OS X? Where can I find the applicable documentation?
You will want to look for your terminal emulation program. See http://en.wikipedia.org/wiki/Terminal_(OS_X) for how to use it, and it should be the bash shell which is one of the unix shells
You can also do a shell script see
http://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO.html for some bash shell scripting info
For such a simple operation, you can write a shell script that will look almost exactly the same as the batch file you use on Windows. The key difference between Windows' cmd.exe and *nix shells here is that the current directory is not part of the search path for executables (the way it is on Windows), so if you put the shell script in the same folder as the compiled executable, you will need to prefix the program name with ./ (to mean "look in the current directory"). For example:
#!/bin/sh
./myprogram datain1 dataout11 datout12
./myprogram datain2 dataout21 datout22
./myprogram datain3 dataout31 datout32
........
./myprogram datainn dataoutn1 datoutn2
If the shell script and executable are not in the same folder, you can use either an absolute path or an appropriate relative path.
Also, to run the script you will either need to make it executable:
$ chmod +x myscript.sh
$ ./myscript.sh
or invoke the shell with the script as an argument:
$ sh myscript.sh
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)
I installed flatpak using guix, but it segfaulted on startup. I wanted to debug it, but guix installs a wrapper script for flatpak, so I get this error when trying to run it under gdb:
"/home/user/.guix-profile/bin/flatpak": not in executable format: file format not recognized
and I tried to edit the wrapper script to call gdb, but this wrapper script is not even editable by root, because it is owned by root and has read-only permissions.
Simply copy the script to your current working directory:
cp /home/user/.guix-profile/bin/flatpak .
Mark it as writable:
chmod +w flatpak
Edit the script with your favourite text editor, to replace the string exec -a with exec gdb --args.
And finally, run it with any arguments you provided before, when it misbehaved:
./flatpak remote-add flathub https://flathub.org/repo/flathub.flatpakrepo
In this particular case, this wasn't immediately super-useful, because a debug symbol output hasn't been built for this package. But at least I could get a backtrace out of gdb.
I have a C++ program that writes to stdout that I am trying to compile into a command line utility in XCode. I need the program compiled into a release build (which it seems, XCode calls an Archive - go figure), not run it as debug.
I basically want to pipe the output of my program into a textfile like this
MyProgram > TextFile.txt
I can compile the program into a command line and run it like this via a Bash shell like this:
Open MyProgram
This spawns a new process (not what I want). However, I could live with that if this worked:
Open MyProgram > TextFile.txt
...But it doesnt :-(. If I try to just run MyProgram directly from Bash, I get the error: -bash: MyProgram: command not found.
What am I doing wrong? How can I compile my command line tool to NOT require the Open command under Mac OSX?
Thanks for any help you can provide. I am picking up C++ on the Mac platform and I am beginning to find it quite it a bit more troublesome than Visual Studio. Does it ever get less painful to work with? :-)
Make your project a Command Line Tool. This will make it so you can run it from the command line directly.
Run it by typing ./MyProgram or ./MyProgram > TextFile.txt not open MyProgram.
I have a question regarding executing shell commands in c++. I'm building an application in winforms, vs 2008. My application has a button, when clicked should decode a binary file to a .csv file. I can decode files by first going to the right directory (cd Test_Copy2) and then execute a command in the command prompt (java -jar tool.jar -b x.fit x.csv). I tried a lot of different stuff but unfortunately got none to work!
I tried using:
system, _popen, ShellExecute(NULL, L"open", L"C:\\WINDOWS\\system32\\cmd.exe ", L"java -jar Tool.jar -b x.fit x.csv", L"C:\\Test_Copy2", SW_SHOWNORMAL)
Can anyone please provide me with an example on how to do that? I dont know where I'm going wrong, most of the time the command prompt opens but no command is executed!
If you really want to run the jar in a cmd.exe instance, you need to add one of the correct command line switches to cmd.exe for it to work the way you want it to:
/C Carries out the command specified by string and then terminates
/K Carries out the command specified by string but remains
For instance, your command string should be:
C:\\WINDOWS\\system32\\cmd.exe /c java -jar Tool.jar -b x.fit x.csv
You can use the system() function to execute shell commands.
For example:
system("DIR") executes the DIR command in the CMD shell. The default directory at the start is the directory you're .exe file is located.
'system("PAUSE")` executes the PAUSE command.
The command/s you wannt to execute should be passed as a constant string to the function.
Edit:
For you paritcular program the syntax (IMO) would be:
system("java -jar Tool.jar -b x.fit x.csv")
I have 3 questions. I am making a C++ executable to launch a Perl program I made. I will compile it for Winows, Mac OSX and Linux. It's pretty much just: system("perl progam.pl");
When compiled with Mac OSX, the program starts in ~. How would I get it to start in the dir it was launched from, or is it just a problem with the compiler?
I'm using - echo -n -e "\033[0;Program\007" - in an attempt to make the windows title "Program". Is this is best way?
I'm using - echo -n -e "\033[7;30;47m" - to make the background of the window black. Is this the best way?
Thanks.
This sounds like something Finder is doing. Launching the app from a shell should work as you expect.
Use tput
See answer to 2, above.
On Mac OS/Unix, invoking system does not change the current working dir. When executing program.pl the current working directory is the same from which you executed the C++ executable. When you launch the executable using Launch Services (e.g. the Finder) the working directory should be /.
On #1 you can refer to the current directory with ./ so system("perl ./progam.pl"); should do it assuming both scripts are sitting in the same folder. ../program.pl would be one level higher.
For #1, use getcwd & then pass an explicit path to system:
cwd=getcwd(NULL, PATH_MAX);
sprintf(cmd, "perl %s/program.pl", cwd);
system(cmd);
free(cwd);
If your perl program itself relies on a specific working directory, then do this instead:
sprintf(cmd, "cd %s && perl program.pl", cwd);
This is probably a silly question, but why are you making an application to launch a perl script? Just add the following to the top of your perl script and use "chmod a+x" to make it executable:
#! /usr/bin/perl
When you use the system command from C and C++, you are basically launching the default system shell and executing the given command in that shell. Doing that is not very portable and somewhat defeats the purpose of using C or C++ (since you could simply create a shell script that does the same thing). If you want to actually do this with C++, you should probably use popen or fork+exec to launch perl. Generally speaking, it isn't nice to end users to play with their Terminal in the manner that you have proposed; most users, by default, have the Terminal configured to display the most recently executed command or their current directory or some other information of their choosing, and changing that is -- on UNIX systems such as Mac OS X and Linux -- considered improper etiquitte. If you are trying to create a terminal interface, though, you might want to look at the curses library.