I need to run a program that requires certain inputs that are listed in a input.txt file. I want to be able to call up this file when I execute the program so I can modify the input.txt file if needed before executing the rest of the code.
I'm running on Mac OS X.
What I have is:
call system('notes input.txt')
I get the following message :
sh: notes: command not found
Is there a special way to call the app notes, or is my error somewhere else?
you're not specifying a full filesystem path in the string ("notes input.txt") which the SYSTEM function sends to a command shell. That means you're hoping there's a binary named "notes" somewhere in your shell's $PATH , and your shell is telling you that's not true. The Notes app is not named "notes", and it doesn't live somewhere pointed to by the shell's $PATH. That's why you get this error message. Try passing to the shell the full path of both the binary you want to run, and the file you want to edit:
CALL SYSTEM("/Applications/Notes.app/Contents/MacOS/Notes /path/to/input.txt")
(NB: that path is where the Notes app lives on my Mac; YMMV.)
Try
call system("/Applications/TextEdit.app/Contents/MacOS/TextEdit /path/to/input.text")
The /Applications/TextEdit.app location is a bit misleading as it is actually a folder. In Finder if you option-click on it you can select to view contents (Not sure of the exact wording of the option as I don't have my mac on me at the moment). Alternatively, cd /Applications/TextEdit.app; ls to view the contents. The executable should be stored in a subdirectory as shown above.
Related
When running scripts in bash, I have to write ./ in the beginning:
$ ./manage.py syncdb
If I don't, I get an error message:
$ manage.py syncdb
-bash: manage.py: command not found
What is the reason for this? I thought . is an alias for current folder, and therefore these two calls should be equivalent.
I also don't understand why I don't need ./ when running applications, such as:
user:/home/user$ cd /usr/bin
user:/usr/bin$ git
(which runs without ./)
Because on Unix, usually, the current directory is not in $PATH.
When you type a command the shell looks up a list of directories, as specified by the PATH variable. The current directory is not in that list.
The reason for not having the current directory on that list is security.
Let's say you're root and go into another user's directory and type sl instead of ls. If the current directory is in PATH, the shell will try to execute the sl program in that directory (since there is no other sl program). That sl program might be malicious.
It works with ./ because POSIX specifies that a command name that contain a / will be used as a filename directly, suppressing a search in $PATH. You could have used full path for the exact same effect, but ./ is shorter and easier to write.
EDIT
That sl part was just an example. The directories in PATH are searched sequentially and when a match is made that program is executed. So, depending on how PATH looks, typing a normal command may or may not be enough to run the program in the current directory.
When bash interprets the command line, it looks for commands in locations described in the environment variable $PATH. To see it type:
echo $PATH
You will have some paths separated by colons. As you will see the current path . is usually not in $PATH. So Bash cannot find your command if it is in the current directory. You can change it by having:
PATH=$PATH:.
This line adds the current directory in $PATH so you can do:
manage.py syncdb
It is not recommended as it has security issue, plus you can have weird behaviours, as . varies upon the directory you are in :)
Avoid:
PATH=.:$PATH
As you can “mask” some standard command and open the door to security breach :)
Just my two cents.
Your script, when in your home directory will not be found when the shell looks at the $PATH environment variable to find your script.
The ./ says 'look in the current directory for my script rather than looking at all the directories specified in $PATH'.
When you include the '.' you are essentially giving the "full path" to the executable bash script, so your shell does not need to check your PATH variable. Without the '.' your shell will look in your PATH variable (which you can see by running echo $PATH to see if the command you typed lives in any of the folders on your PATH. If it doesn't (as is the case with manage.py) it says it can't find the file. It is considered bad practice to include the current directory on your PATH, which is explained reasonably well here: http://www.faqs.org/faqs/unix-faq/faq/part2/section-13.html
On *nix, unlike Windows, the current directory is usually not in your $PATH variable. So the current directory is not searched when executing commands. You don't need ./ for running applications because these applications are in your $PATH; most likely they are in /bin or /usr/bin.
This question already has some awesome answers, but I wanted to add that, if your executable is on the PATH, and you get very different outputs when you run
./executable
to the ones you get if you run
executable
(let's say you run into error messages with the one and not the other), then the problem could be that you have two different versions of the executable on your machine: one on the path, and the other not.
Check this by running
which executable
and
whereis executable
It fixed my issues...I had three versions of the executable, only one of which was compiled correctly for the environment.
Rationale for the / POSIX PATH rule
The rule was mentioned at: Why do you need ./ (dot-slash) before executable or script name to run it in bash? but I would like to explain why I think that is a good design in more detail.
First, an explicit full version of the rule is:
if the path contains / (e.g. ./someprog, /bin/someprog, ./bin/someprog): CWD is used and PATH isn't
if the path does not contain / (e.g. someprog): PATH is used and CWD isn't
Now, suppose that running:
someprog
would search:
relative to CWD first
relative to PATH after
Then, if you wanted to run /bin/someprog from your distro, and you did:
someprog
it would sometimes work, but others it would fail, because you might be in a directory that contains another unrelated someprog program.
Therefore, you would soon learn that this is not reliable, and you would end up always using absolute paths when you want to use PATH, therefore defeating the purpose of PATH.
This is also why having relative paths in your PATH is a really bad idea. I'm looking at you, node_modules/bin.
Conversely, suppose that running:
./someprog
Would search:
relative to PATH first
relative to CWD after
Then, if you just downloaded a script someprog from a git repository and wanted to run it from CWD, you would never be sure that this is the actual program that would run, because maybe your distro has a:
/bin/someprog
which is in you PATH from some package you installed after drinking too much after Christmas last year.
Therefore, once again, you would be forced to always run local scripts relative to CWD with full paths to know what you are running:
"$(pwd)/someprog"
which would be extremely annoying as well.
Another rule that you might be tempted to come up with would be:
relative paths use only PATH, absolute paths only CWD
but once again this forces users to always use absolute paths for non-PATH scripts with "$(pwd)/someprog".
The / path search rule offers a simple to remember solution to the about problem:
slash: don't use PATH
no slash: only use PATH
which makes it super easy to always know what you are running, by relying on the fact that files in the current directory can be expressed either as ./somefile or somefile, and so it gives special meaning to one of them.
Sometimes, is slightly annoying that you cannot search for some/prog relative to PATH, but I don't see a saner solution to this.
When the script is not in the Path its required to do so. For more info read http://www.tldp.org/LDP/Bash-Beginners-Guide/html/sect_02_01.html
All has great answer on the question, and yes this is only applicable when running it on the current directory not unless you include the absolute path. See my samples below.
Also, the (dot-slash) made sense to me when I've the command on the child folder tmp2 (/tmp/tmp2) and it uses (double dot-slash).
SAMPLE:
[fifiip-172-31-17-12 tmp]$ ./StackO.sh
Hello Stack Overflow
[fifi#ip-172-31-17-12 tmp]$ /tmp/StackO.sh
Hello Stack Overflow
[fifi#ip-172-31-17-12 tmp]$ mkdir tmp2
[fifi#ip-172-31-17-12 tmp]$ cd tmp2/
[fifi#ip-172-31-17-12 tmp2]$ ../StackO.sh
Hello Stack Overflow
This is driving me crazy, I must admit. After finally being able to successfully compile two functions I need to process voice files, from C/C++ code that I downloaded from a trustworthy online repository (code that had been thoroughly tested in Linux), I am now struggling to launch those files from Matlab...
When I type the following command in cmd (dos)
Analysis b2.wav config_default
it works, no problem (see here Works).
Then, I build the exact same command into a string and feed it to the "system" Matlab function. Then the code crashes... (see here Fails) I've tried with full paths (c:\b2.wav, etc) but still does not work...
Any ideas as to why this might be happening?
Your image shows that the program Analysis stopped unexpectedly.
It might be a lot of reasons why, so let's go step by step:
1) Try executing Analysis from Terminal and passing wrong parameters (a file that doesn't exist, only one param (missing the config_defalut), no parameters at all, three parameters, etc...)
Can you make the program crash from terminal by passing wrong params?
2) Try creating the command first, checking that it's correct (\b is actually \b instead of a string modifier)
command_to_be_run = 'C:\Analysis C:\b2.wav C:\config_default'
disp(command_to_be_run) % is it showing exacly what you want?
system(command_to_be_run); % if so, run it.
3) Try creating a dummy executable dummy.exe in C that accepts two parameters and prints the received parameters (keep it super simple, just printing). Call it from Terminal. Does it work? Call it from Matlba. Does it Work?
With this 3 tests you can considerably narrow down where your error comes from.
By the way, is "config_default" a file or just a string that tells analysis how to behave? In some examples you treat it as a file, in others as a parameter without path.
Based on what's been tried so far and the outputs, here's my theory:
Premise: Analysis.exe came from code that's well tested in Linux. It works in Windows command line when run from the same directory where both it and the target file reside. But it stops working from Matlab console.
Assertion 1: Matlab console does not operate within the context of the directory where the binary is but rather within the Matlab directory. As such, Analysis.exe will try to find the target from the Matlab directory.
Validation for Assertion 1: Try putting the binary and the target wav in the Matlab directory. Then run system with the binary and target specified just by name (no path).
Assertion 2: If the file's full path is specified to address this issue, it still doesn't work. This may be because the code assumed a Linux file system where the delimiter is "/" rather than "\".
Validation for Assertion 2: Run with paths specified from the command line while in a diferent directory to see if it fails or not.
Possible Solution 1: Add the directory where both Analysis.exe and the target are into the Matlab path: (1) On the Home tab, in the Environment section, click Set Path. Add the path there. (2) addpath (folderName1,...,folderNameN) adds the specified folders to the top of the search path for the current MATLAB session. -> Then run the system command without the full paths.
Possible Solution 2: Add the directory where both Analysis.exe and the target are into the Windows environment path. Then run the system command without the full paths.
EDIT: Possible hackish solution - Create a batch file where: (1) you would cd to the directory where Analysis.exe and the target wav are; and (2) do a Matlab system call to the batch file.
EDIT 2: Possible experiment to validate assertion 2.
Suppose that I add a program to path that is dependent on a file name "test.in". I programmed this in C++ so I used ifstream fin("test.in") without specifying the directory. Now if I were to run this program from a different directory, would the program be able to access the file "test.in"?
Firstly, this has nothing to do with the file extension, which is merely a convention given as part of the filename.
Secondly, you were always using a relative path. Even when you were running your program "from the same directory" as test.in, you were reliant on the "working directory" of your shell context being the same as the directory in which the executable and the file reside.
This is not always the case.
For example:
~/myProject:# ls
test.in
program
~/myProject:# ./program
This is okay, because your shell is at ~/myProject, and so is test.in.
However, if you'd written:
~/myProject:# cd ..
~:# ./myProject/program
…then your test.in file wouldn't be found, as it does not exist in ~. It exists in ~/myProject. It doesn't matter that the executable itself is also found in ~/myProject.
This is actually desirable behaviour, as it allows flexibility from the shell. Ideally you would allow support for piping/redirecting the file to the process instead (program < test.in — now there are no assumptions baked into your code at all!), but we can save that for another day.
For now, you seem to be concerned about what happens if you move the executable away. Don't worry: just use this feature!
~:# mv myProject/program .
~:# cd myProject
~/myProject:# ../myProject
Your working directory is the directory in which test.in resides, so it will be found via the relative path given in your program code.
I'm trying to use Mac Instruments Time Profiler to optimize my code for building a MandelBox. I found how to make my executable my target process, but when the program runs, it gives me an error in the Console window saying it cannot find the .txt file associated with the program.
Do I need to tell the profiler where to look to find the file? The text file is already in the same directory as the executable. Any thoughts? Thanks.
This problem is not unique to Instruments. The same thing would presumably happen if your current working directory was something other than the location of your program. For example, if you were to do cd / ; /path/to/yourprogram.
You either need to make your program find its own location and then find its text file as a sibling in the containing directory or take the path of the text file as an argument. Or, you will always have to set the working directory to your program's location before invoking it.
That last approach is an immediate workaround for the problem with Instruments. On the panel where you choose the target executable, you can also configure various parameters, such as arguments, environment variables, and the working directory. Set the working directory to the directory that contains the text file and it should work.
This is simple to do in languages like Python, but I'm not sure how to do it in C++. I want to move to a specific folder, say "C:\tests" and run some command line call from that folder. Thanks
You can start a process in a specific directory using the CreateProcess() call. In particular, look at the lpCurrentDirectory argument:
lpCurrentDirectory [in, optional]
The full path to the current directory for the process. The string can also specify
a UNC path. If this parameter is NULL, the new process will have the same current drive
and directory as the calling process. (This feature is provided primarily for shells that
need to start an application and specify its initial drive and working directory.)
This function is used internally by Python's subprocess.Popen's constructor.
You want SetCurrentDirectory for changing directories and system for executing a command asynchronously. system is the simple way to do it. You can use CreateProcess if you need flexibility.
Create a bat file and put cd command there to set required path and then write your command to execute. Ex in your bat file write
line1 "cd c:/tests/"
line2 "your command to be executed"
After that you could use system("*.bat") to call your bat file. See more info related to that here http://faq.cprogramming.com/cgi-bin/smartfaq.cgi?answer=1044654269&id=1043284392 Hope this helps