I have a program that I built in Xcode however I need to supply input to the program in the following way as would be done from the Terminal:
./program < fileInput
I followed the steps suggested here Running C scripts with terminal instead of Xcode but no luck.
Below is the screenshot of my attempt. The file I'm providing exists in the Build directory. I also tried supplying the input file as absolute path without any luck either. My xcode version is 8.1.
The screenshot:
Related
So I am looking for a way to set Mac specific extended attributes (specifically kMDItemWhereFroms) for a file (Image File, Jpg) using AppleScript or AppleScript-Objc.
There is a command line tool that will do this xattr -w kMDItemWhereFroms . The problem is that on the several machines that I have access to (10.12, 10.13, and 10.14) when you run this command as a do shell script from within an AppleScript it does not work, the metadata is not added to the file. If I set Script Debugger to debug mode, and go through the script step by step it will actually set the metadata, but since that is not the way I am running the script, it is more of an interesting fluke than anything else. I have tried running the command with both "com.apple.metadata:" included and not included with the shell script and that makes no difference.
I have tried running my script through SD, Script Editor and osascript, and they all fail to update the metadata. So I am thinking that this tool might be broken when called from an AppleScript.
I found setxattr but that looks like it only applies to C.
So my questions are
1. Is there a way to set the extended attributes of a file on MacOS using Aobjc? if not then
2. Is there a way to get setxattr to work with either version of AppleScript? Probably not so
3. Any ideas how I might be able to get the command line tool xattr -w kMDItemWhereFroms to work when using scripting?
This is more of an annoyance for me, I am just being stubborn with wanting the source of the file to show up in the "Where From" data in the Get Info window from the Finder. I already am setting some metadata for the file using exiftool. So it is more of an interesting problem for me, than a critical problem that I must try and solve now. Thanks!
I want to use Sublime Text as my default editor for Octave, but cant get it to work.
The location of my Sublime Text app is in the /Applications/ folder as usually.
For example putting EDITOR (“/Applications/SublimeText.app”) results in the following error:
parse error near line 1 of file /Users/czapla/.octaverc
syntax error
>>> EDITOR (“/Applications/SublimeText.app”)
^
error: source: error sourcing file '/Users/czapla/.octaverc'`
FYI: Yes SublimeText, this is name of the application, no spaces in between, I changed it to avoid having to escape spaces - I wasnt sure how that would be handled by Octave.
Any ideas?
Thanks!
You don't mention what different things you tried to place in your .octaverc file. The following should work EDITOR ("path_to_your_sublime_aplication"). It doesn't need to be the full path, whatever works to call it from the command line should suffice. For example, EDITOR ("gedit") works fine on my system.
Also, it is important to set this before calling any function that makes use of it. The variable is persistent during an Octave session after being accessed the first time (and defaults to emacs).
I am using Sublime Text 3 on OS X
Octave programs are running perfectly. So you can try the below mentioned steps
Open Sublime
Goto Tools --> Build System --> New Build System...
Paste this code
{
"cmd": ["/usr/local/octave/3.8.0/bin/octave-3.8.0", "$file"],
"selector": "source.m"
}
Save it as Octave.sublime-build
Now use Octave as your build system
Use ⌘ + B to run your code.
Enjoy!
I'm trying to use Mono to make a portable application that works on Windows, Mac, and Linux, but I want to have a standard DMG file that allows users to simply click and drag my application to their Applications folder on their Mac. In the best answer to this post I found that by creating an executable script beginning with #! in the MyAppName.app/Contents/MacOSX/ folder, it could run whatever I liked.
How do I get a script to actually run?
I made a blank "Hello World" Cocoa App in XCode, and copied the .app file to the Applications directory, and everything worked great. But when I replaced the executable in the MacOSX folder with a script starting with #! it didn't run the script.
I tried chmod 755 myscript, I tried deleting the old executable file and renaming my script to be the old filename, but all that served to do was stop the app from running at all. The permissions of the script, and the filename, are both correct.
So then I assumed that maybe scripts wouldn't work, and XCoded a command line utility, again that would simply spout "Hello World!", but still it didn't run.
The ".app" extension is formally called an Application Bundle, and they have some pretty good documentation, but none of it seems to tell me why my approach isn't working.
Here is the .app bundle that I'm working on. Inside the MasOSX directory you'll find hello (the Hello Word command line utility) and script (a one line script with a #! as the first line) and XCodeTest (a Hello World cocoa app).
Scripts in Unix
Well, first of all, the correct syntax for the first line of a script is
#! <path-to-script-interpreter> [<optional-args>]
For instance
#! /usr/bin/perl -wT
... perl code here
Using the open command
However, this won't help you because the open command does not support shell scripts as launchers. You need to write some C / Objective-C code and compile it into a native executable. Simply using system() or execv() inside that tool won't work either, you'd have to dlopen() the Mono runtime.
Look at monodevelop/mainbuild/MacOSX/monostub.m for an example. This is what MonoDevelop uses to launch MonoMac application.
When you write a Cocoa app with XCode, it will compile your app into native code and put the resulting binary as launcher in the Contents/MacOS directory.
The easy solution
Why don't you simply create a MonoMac application with MonoDevelop? This would automatically create the .app package for you - no need to fiddle around with scripts or custom launchers.
I've got a problem with using Dia from the command line on OSX 10.7.4. I downloaded and installed the OSX dmg from http://dia-installer.de/download/macosx.html I've been using it to create graphics for a paper and absolutely love it.
I'm using a makefile to call pdflatex, bibtex, and R so that that it will build everything from scratch if need be, but can't get Dia's command line to work.
I want to use the command line with -e and -t to export the graphics to a specific directory so that pdflatex can put them in the pdf. (http://dia-installer.de/doc/en/re01.html)
The problem that I'm running into is that anytime I call it from the terminal, it brings up the GUI. Even if I give move to /Applications/Dia.app/Content/Resources/bin/ and use the command "./dia -v". It gives me a bunch of errors about "Input method" and then shows the GUI.
I looked on the Dia FAQ and it has a lot of information for the Windows command line, but nothing for OSX.
I'm hoping that someone here has run into this before and knows how to get it to work.
Thanks in advance.
I'm having a weird problem with running cl.exe that has me stumped. In a large VS2008 solution consisting of C/C++ projects, I have one project that runs some scripts to do some extra processing. The project consists of a pre-build event, which calls a Perl script (ActiveState Perl is on the machine). This Perl script then calls cl.exe with /E to generate preprocessed output which gets redirected to a file. The line in Perl looks like this:
my $foo = `"\path\to\cl.exe" #args.rsp >out.txt 2>err.txt`;
args.rsp is a plain text file that contains a bunch of command line args for cl.exe, including /E to get pre-processor output on stdout.
This exact command line works as expected when run from the VS2008 command prompt. Building the project also works fine on my Windows XP machine. However, on my new Windows 7 box, when I build the project, out.txt ends up blank. I should also add that on some of my coworker's Windows 7 boxes, it works fine, and on some others it doesn't.
Clearly there's some kind of configuration difference going on, but I'm at a loss as to what it may be. We've checked matching versions of VS2008 SP1 and ActiveState Perl. I've tried myriad workarounds within the perl script - using system() instead of backticks, using cl.exe /P to output to a file and then moving the file (the file is blank), unsetting the VS_UNICODE_OUTPUT environment variable (no effect). Nothing has changed the behavior - output is generated when the command line is run manually, but not when it's run inside the pre-build event for this project.
Any ideas on what kind of configuration problem may be causing this? I'm pretty much out of avenues to pursue.
Sounds like an ACL issue to me. You can change windows to log access issues and then check the event log to see what user is getting access denied errors.
I believe the setting is in Local Policy | Audit Policy | Audit Object Access
Wow, the solution to this ended up being a lot stranger than I expected. The machine I'm working on (and the other co-workers who are also experiencing the problem) is a Mac Pro with bootcamp and Windows 7 installed. That causes C: to have the windows drive and E: to have the mac drive. This causes a problem because the pre-build event has a couple lines that test each drive letter to see if there's a drive there, and if there is, adds X:\Perl\bin to the path. Even though E:\Perl\bin doesn't exist, it gets added to the path. Later, the perl script runs and then calls cl.exe, and for some reason, having a directory in the mac drive causes cl.exe to fail. Why? I have no idea. Anyway, removing the mac drive directory from the path fixes the problem!
Thanks for your eyes everyone.
Check out the exit code of your program. You may want to build your executable name in a portable way using something like File::Spec. Also, check that #args is not interpolating. You may want to print your command line before executing to check if that's what you want. What is left your err.txt file?