I'm trying to run a command-line MPI program from within Xcode, which requires I run my program as so:
/usr/bin/mpiexec -np 4 {my binary}
I'm trying to edit the scheme, using the Xcode 4 docs and xcodebuild -showBuildSettings from the command line as my guide to locate the proper variables. I have a scheme that runs mpiexec and passes the following arguments:
-np 4 $CONFIGURATION_BUILD_DIR/$TARGET_NAME
Which, if I go by their values in xcodebuild, should give me this:
/Users/<excluding full path>/MyProject/build/Debug/MyTarget
However, when running inside Xcode, I get this:
build/Debug/MyTarget
Prefixing this as so:
-np 2 ${PROJECT_DIR}/${TARGET_BUILD_DIR}/${TARGET_NAME}
results in the full path up to the first space in the path name and then nothing more, which tells me there may be some issue with space escaping.
which is not enough to allow mpiexec to locate my binary. What is the proper way to identify the absolute path of my built executable using Xcode schemes and arguments?
It works fine if I do this:
-np 2 "${PROJECT_DIR}/${TARGET_BUILD_DIR}/${TARGET_NAME}"
Perhaps it just needed the double-quotes to avoid the space in the path?
I'm leaving this unaccepted for a while in case someone posts a proper answer, this feels like a hack to me
Related
I am trying to build FreeBSD from source to see how it works. I googled how to do it, and most of the websites explaining how to build the world tell me to run this command inside the directory of the source code:
sudo make -j1 buildworld KERNCONF=MODEDKERNEL -DNO_CLEAN
For some reason, I keep getting this error...
make: invalid option -- 'D'
make: invalid option -- 'N'
Anyone know how to fix this? The Makefile can be found here
We don't need to see the makefile, because this error is being printed by make due to an invalid command line argument which means it's never even opening the makefile before it fails.
The reason is that -D, etc. are not valid command line options to GNU make. If you run man make (or look online for the GNU make manual) you'll see that -D is not listed as a valid option.
My suspicion is that when the websites you are reading are suggesting that you run make, they mean you should run FreeBSD make, which does support a -D option: https://www.freebsd.org/cgi/man.cgi?make(1)
You are trying to run this using GNU make, which does not have that option.
while trying to find the file in mainframe server which create last 10 minutes it shows error like
"FSUM6372 Unknown option "-cmin"
Usage: find directory ... expression"
it not accept the -mmin , -cmin , -amin this command
but i want to find the file which create last -10 minutes changed file
how to find it and anyone please help me on this case
find /input \( -name [0-9][0-9][0-9][0-9][0-9]_[A-Z][A-Z].dat \) -cmin -10
FSUM6372 Unknown option "-cmin"
Usage: find directory ... expression
You seem to not know what operating system you're running on, or anything about said operating system, which is concerning. You're running the command on z/OS V2R3, based on the output of uname. z/OS is POSIX compliant, and the options you're specifying on the find command aren't supported, as shown in the documentation.
I can think of two options: first, obtain a version of find that does support said options, or, second, use the tools present on the platform.
For the first option, you can obtain findutils, which includes find, from Rocket Software. Note that this requires an account with them, and may violate your site's security rules. It's also possible that this version is already installed; you should talk to your system programmer.
For the second option, find does have the –newer option, which looks for files created more recently than the specified file. You can use this in conjunction with the touch command's -t option, which will allow you to set a last modified date and time for a given file. So instead of -cmin -10, you would specify -t filename.
I tried to run a Python script from R with:
system('python script.py arg1 arg2')
And got an error:
ImportError: No module named pandas
This was a bit of a surprise since the script was working from the terminal as expected. Having encountered this type of issue before (with knitr, whence the engine.path chunk option), I know to check:
Sys.which('python')
# python
# "/usr/bin/python"
And compare it to the command line:
$ which python
# /Users/michael.chirico/anaconda2/bin/python
(i.e., the error arises because I have pandas installed for the anaconda distribution, though TBH I don't know why I have a different distribution)
Hence I can fix my issue by running:
system('/Users/michael.chirico/anaconda2/bin/python script.py arg1 arg2')
My question is two-fold:
How does R's system/Sys.which find a different python than my terminal?
How can I fix this besides writing out the full binary path each time?
I read ?Sys.which for some hints, but to no avail. In particular, ?Sys.which suggests Sys.which is using which:
This is an interface to the system command which
This is clearly (?) untrue; to be sure, I checked Sys.which('which') and which which to confirm both are pointing to /usr/bin/which (goaded on by this tidbit):
On a Unix-alike the full path to which (usually /usr/bin/which) is found when R is installed.
To the latter, on a whim I tried Sys.setenv(python = '/Users/michael.chirico/anaconda2/bin/python') to no avail.
As some of the comments hint, this is a problem that arises because the PATH environment variable is different for programs launched by Finder (or the Dock) than it is in the Terminal. There are ways to set the PATH for Dock-launched applications, but they aren't pretty. Here's a place to start looking if you want to go that route:
https://apple.stackexchange.com/questions/51677/how-to-set-path-for-finder-launched-applications
The other thing you can do, which is probably more straightforward, is tell R to set the PATH variable when it starts up, using Sys.setenv to add the path to your desired Python instance. You can do that for just one project, for your whole user account, or for the whole system, by placing the command in a .Rprofile file in the corresponding location. More information on how to do this here:
https://stat.ethz.ch/R-manual/R-devel/library/base/html/Startup.html
Whenever I try to run any Arduino CLI commands, I am always getting a popup saying "MainClassNameRequired". What is going on and what do I need to do to be able to run arduino CLI commands?
I found the following JA.SO question and answer: https://ja.stackoverflow.com/q/20667.
My Japanese is terrible, and Google Translate didn't help too much, but the paths in the answer were correct and I was able to get the gist & get it working.
It turns out that, for whatever reason, the Arduino symbolic link created in /usr/local/bin, even though it is linked to the correct executable, doesn't actually pass the parameters through.
The Japanese answer suggested two solutions, both of which work. Firstly, remove the existing symlink from /usr/local/bin, then you can either:
Create a shell script wrapper to call the Arduino executable that will pass parameters through and then link create a symlink to that (or just make it executable and place it in /usr/local/bin):
#!/bin/bash
exec /Applications/Arduino.app/Contents/MacOS/Arduino "$#"
ln -s /usr/local/bin/arduino arduino.sh
Create an alias
alias arduino='/Applications/Arduino.app/Contents/MacOS/Arduino
Now when you execute arduino from your command prompt, your parameters are correctly passed to the program.
I just started using Zsh lately for some of the integrated support in the shell prompt for my Git status etc.
When I type in:
ruby -v
to confirm the version of ruby I'm running, Zsh asks if I want to change the command to _ruby. Well after saying no at the prompt and the command completing as expected I continue to get the question at the prompt after confirming my command is correct.
I'm assuming there is a completion file or something of the sort.
Thanks
Update:
The shell is no longer trying to complete _ruby, it stopped responding after closing the shell a few times some how.
I tried to clean the file up several times but there is a "opts" variable that is 50 or more lines long and the lines are all ran together, some lines more than 150 characters. Maybe I could email an attachment to you if you still want to see it.
I sincerely apologize for the messy post.
This is command autocorrection, activated by the correct option. It has nothing to do with completion. You're seeing _ruby because zsh thinks there is no ruby command and it offers _ruby as the nearest existing match.
If you've just installed ruby, it's possible that zsh has memorized the list of available command earlier, and it won't always try to see if the command has appeared in between. In that case, run hash -rf. Future zsh sessions won't have this problem since the ruby command already existed when they started.
Sometimes, when you change your PATH, zsh forgets some hashed commands. The option hash_listall helps against this. As above, if you can force zsh to refresh its command cache with hash -rf.
You could make an alias:
alias ruby='nocorrect ruby'
It's what I did when zsh kept asking me if I meant .meteor when I typed meteor because auto-correct is still useful from time to time.
I find the autocorrect feature can get annoying at times. So I do in my ~/.zshrc,
DISABLE_CORRECTION="true"
I had the same problem even when the command is not installed.
I can solve it using the CORRECT_IGNORE variable in my .zshrc
# OPTs to enable
setopt HASH_LIST_ALL
setopt CORRECT
# Zsh variable to determine what to ignore,
# in this case everything starting with _ or .
CORRECT_IGNORE="[_|.]*"
I hope it helps to you or anyone with this issue
Sometime ago after an update, I got command auto-correction enabled which I don't want. If the same happened to you and you want to revert it, in the ~/.zshrc file you'll have make it:
# Uncomment the following line to enable command auto-correction.
ENABLE_CORRECTION="false"
or comment it as per bellow:
# Uncomment the following line to enable command auto-correction.
# ENABLE_CORRECTION="true"
Just a note, on my zsh (version 5.7.1 on macOS), the DISABLE_CORRECTION didn't work.
I saw in my .zshrc file the following two lines, which I then commented out
setopt CORRECT
setopt CORRECT_ALL
That did it for me.