I wrote an "emacsinit" file like
/usr/local/Cellar/emacs/24.1/Emacs.app/Contents/MacOS/Emacs --daemon
and drag the file "emacsinit" into the "Login Items".
But it doesn't seem to work. The server doesn't start after system start.
How can I deal with it?
The Login Items scheme likely expects that the launched apps are full app bundles, not just individual shell scripts.
A tool called Platypus can be used to wrap your shell script up as a full application.
Another option is to create an OS X per-user launchd item for Emacs, which is easy if you use an app called Lingon. (Older Lingon versions were free, and will also do the trick.)
For what it's worth, I get all the same advantages with less work by starting the regular Emacs app and then activating the server with the following code:
(require 'server)
(unless (server-running-p)
(server-start))
After that, I can create new text and graphical frames freely using emacsclient.
Related
Given the name of a shortcut in Apple's Shortcuts app, or some other way of identifying a shortcut, how can a native macOS app run it?
This would be the equivalent of executing the following shell command:
shortcuts run "Shortcut name here"
Granted executing a shell command is a possible way of doing this, but I'm hoping that using an API function will be better since they generally allow for better control and error handling. For example, the shell command doesn't provide any easily obtained error code for the calling process when something goes wrong, but rather displays a system notification with the error code.
edit: So far searching online and Apple's docs, as well as looking at the external symbols in Apple's shortcuts command line utility, suggests there is currently no public API for this. If so then then executing a shell command is probably the only way to do this. I'll leave this question open in case this is incorrect or it eventually changes.
I am working on an application where we are using xtermjs and node-pty inside of an electron application. We are adding a terminal to our application and would like to add some custom commands that are used in the terminal that are related to our application.
What are some options for adding these commands?
We want them installed with the application.
They don't have to be useable inside an 'external' terminal, but it is ok if they are. By external, i mean your normal terminal. Not our xterm & node-pty implementation.
And we want them to behave the same as other normal unix commands. Where you can pipe with other commands && them together and stuff.
I have played around with intercepting commands between xterm and node-pty and that was a disaster. I am now considering, just writing bash scripts for the commands and having the installer manage putting them where they need to be so they can be used.
Just wondering what my options are, thanks.
You can simply put all your executables in a directory that you add to your PATH when you invoke the shell in your terminal emulator.
The commands will be available to the user like any others in any construct that accepts commands, regardless of the user's shell or shell version (i.e. it'll work equally well in bash, zsh and fish).
If you need the commands to coordinate with your terminal emulator (e.g. if you want to process the command in JS in your Node.js process), you can arrange that via a second environment variable containing e.g. a host/port to connect to.
I've hooked the system call to typedef int (*orig_open_f_type)(const char *__file, int __oflag, ...); and thus, whenever a file gets opened, my code gets the event before it is passed on to the system. I created a dynamic library that overrides the open call and inject this library using DYLD_INSERT_LIBRARIES - working on a Mac machine and using XCode. It is a standard step that enables me to hook calls.
Now, I have bash script in which I have some files that I want to open. I have tried xdg-open , cat, exec - but they are not triggering the system call to open the file.
How should I invoke this open call in my bash script?
Please note that I have tested my open call hook, by opening files in C code.
I believe you're running foul of Apple's SIP (System Integrity Protection) which is designed to stop people doing things like that with system-provided executables. SIP was added to Mac OS X El Capitan (10.11) and continues in macOS Sierra (10.12).
To demonstrate whether this is the problem, consider copying /bin/cat to /usr/local/bin/cat and then try hooking (running) the local copy. You might get away with it there. This 'workaround' is purely for demonstration purposes. Basically, if I'm right, SIP is Apple's way of saying "don't go messing with our software".
You can follow links from Can Mac OS X El Capitan run software compiled for Yosemite that expects libraries in /usr/gnu/lib? to find out more about SIP. Following links via What is the "rootless" feature in El Capitan, really? on Ask Different to a blog article on System Integrity Protection, it says explicitly:
Runtime protection
SIP’s protections are not limited to protecting the system from filesystem changes. There are also system calls which are now restricted in their functionality.
task_for_pid() / processor_set_tasks() fail with EPERM
Mach special ports are reset on exec(2)
dyld environment variables are ignored
DTrace probes unavailable
However, SIP does not block inspection by the developer of their own applications while they’re being developed. Xcode’s tools will continue to allow apps to be inspected and debugged during the development process.
For more details on this, I recommend taking a look at Apple’s developer documentation for SIP.
Emphasis added
Basically, this means that you won't be able to hook calls to the open() system call for Apple-supplied software installed in the system directories. You will need to rethink what you are trying to do.
Running any normal command -- like cat -- that processes a file will cause the file to be opened. You can also open a file (and immediately close it) using the shell syntax:
: < /path/to/file
If your system call hook isn't getting called, something must be wrong with your hook -- there's no way these commands are working without opening the file. Alas, you haven't explained how you implemented your hook, so we have no way of debugging that.
The file command opens the file to look at its contents.
$ file /path/to/file
I have suggested this because it eventually leads to having the system call open which can be confirmed using strace.
$ strace file /path/to/file 2>&1 | grep open
I thought one of the good things about using file is that it opens the file in read only mode. In comparison to other ideas, unlike cat, it will not have to run through the entire file, just part of it, so the time complexity using file may be constant. Unlike vim, which someone has suggested, file will return when finished and not block like a text editor would.
I've been learning shell script on my Mac recently. Take an application like Atlassian's SourceTree as an example. My understanding is that it's just a GUI for git commands, which can be executed through command line. Pressing a button just triggers a corresponding git command, which is effectively run through the command line behind the scenes. If that is the case, do all applications that have a GUI function this way? Are all applications essentially just running their commands through the machine's shell script? And if so, are the underlying commands that are being used publicly available, offering an API of sorts for any application?
This is more complex than that.
Many applications only have a GUI (e.g., Safari), many others only have a CLI (e.g., find).
When a GUI app and a CLI app perform the same function, they may communicate with each other or they may not:
As you point out a GUI application can run a CLI command behind the scene (with system() or popen() for instance)
An alternative is that both applications use the same underlying library
Or no code is shared at all (think of ls vs. Finder on Mac)
Finally on Mac some GUI apps can be controlled with Applescript language, which is available through osascript command. In other words, you can control iTunes with a bash script.
Definitely, not all applications behave that way. In fact, from my experience, I'd say that there are few applications that follow that. Most applications perform their own operations relying directly on the OS platform and functionalities, instead of executing shell commands which, in addition, are hard (and most of the time impossible) to port between OSs.
I am developing an ncurses program. So running this in Xcode fails because the Console is just for stdout/stderr, but it is not a full terminal emulation (and hence can’t run ncurses programs).
To easily use the debugger, I would like to tweak the Scheme that the “Run” feature starts the application in Terminal.app or iTerm.app instead.
Does anyone know how to achieve this? My first attempts to change the Executable in the “Run” section of the scheme editor to use Terminal.app and use arguments were not successful (but then again, I am not familiar with possible arguments for Terminal.app).
Update: Thanks for pointing to How to run command-line application from the terminal? - this is indeed almost what I am after. The problem is that at least on OS X 10.11, SIP (System Integrity Protection) requires to turn off the "Debug Executable" option (besides, I don't want to debug Terminal.app, but rather my application).
So the remaining question is if it is possible to let the "Run" also start the debugger the debug the built executable (i.e. without manually attaching the debugger after the executable was started).