Programatic file associations in OS X - macos

Is it possible to use an Apple Script or a Unix executable to associate a file type with an app?
My problem is I'm using File Vault and it forgets previous associations (it's a well known bug so it seems). For instance, I like to use Flying Meat's Acorn for my graphics files rather than Preview. I can Cmd-I, change all, and while it sticks for one file the next time I reboot it's forgotten the association for everything else.
This has been driving me nuts for literally years. Any ideas?

I use Magic Launch and would highly recommend it. Not only can you associate programs with certain file types, but you can establish complex rules for when to use what app.
Or, to better answer your original question, you could try this:
defaults write com.apple.LaunchServices LSHandlers -array-add \
"<dict><key>LSHandlerContentType</key><string>public.png</string><key>LSHandlerRoleAll</key><string>com.flyingmeat.acorn</string></dict>"

Related

Change process name on MacOS of arbitrary binaries

I want to be able to set the process name (as it appears in the Activity Monitor) of arbitrary binaries in MacOS. Preferably, this wouldn't require any manual reverse engineering.
To clarify, I'm not asking to change it at runtime. Rather, to set up a script which will change the code of another executable.
(similar to how you can change argv[0] in C code)
You may achieve it for some apps, but with relevant consiquences.
First of all, let's think of what is going to be the name in Activity monitor. It is a name of a executable file for shell scripts, and it is a Bundle or displayed Bundle name for bundles.
So, to change the name you will basically need to change the name of file or the record inside Info.plist.
Both is not doable for Apple provided apps, until you disable SIP (if this could be the way for you - all is doable).
Speaking about non-Apple apps, you could change their names or Info.plist records, but it would result in non-valid code signature for them. You will need to manually allow such apps to run on your mac and get over all Apple popups about that.
There is no API you can use to achieve this goal. You are either going to use hacky ways, or need to change what you want to have.

Dyalog APL: how to write standalone files that can be executed?

I now know how to use the APL interpreter, but I'm quite confused about how to write APL into a file and then run the said file. I currently write Dyalog APL using the ride IDE. What I now want to do is to:
Use the ride IDE to develop programs (how else do I access the keybindings?).
Save my program to a file.
Run the program from the command line, with command line arguments (how do I take command-line arguments?)
Distribute my program so others can use them.
Most of the documentation online refers to an "APL session", which makes me think that perhaps there's some Smalltalk like thing going one, where one can only distribute the "live image" or some such. If that is the case, I have a different set of questions:
How do I save and load these image files?
How do I distribute image files?
Can I execute such code from the command line, to take command-line arguments?
In general, I'm quite confused about how to write software in APL!
EDIT: I'm on Ubuntu, and I'd like to target Linux in general. Windows/macOS support would be a plus, but I'm currently interested in Linux support.
For now, the ability to create a stand-alone executable (a single .exe file) only exists on Windows, but Dyalog is working on making this possible cross platform. However, you can get pretty close. Before we get to that, let me answer your initial questions:
Use the ride IDE to develop programs (how else do I access the keybindings?).
There are several convenient ways to enter the glyphs outside RIDE, both through editor extensions and separate system-wide methods for prefix and/or shifting key input. For details, have a look at APL Wiki's article on typing glyphs.
Run the program from the command line, with command line arguments (how do I take command line arguments?)
⊢2⎕NQ#'GetCommandLineArgs' returns the command and the arguments to the command that was used to start the current application. This works cross-platform. Try it online under Linux!
The "live image" you talk about would be what APLers call a workspace. Once your application is working as you want, enter set the ⎕LX (Latent eXpression) variable to a statement that starts your application and then closes APL when done, e.g. ⎕LX←'myApp.Run ⋄ ⎕OFF'.
Next, save your application as a workspace with )save /tmp/myapp.
You should now be able to run your application with dyalog -hello=world /tmp/myapp etc. You can of course put this in a shell script for ease of use.
What you'll distribute to your customers would at a minimum be the workspace and the runtime interpreter, but you probably want to package some companion files/dependencies too. However, before making money off your application, look at Dyalog's prices and Licences.
This is how I do it (not an official Dyalog recommendation):
Use the ride IDE to develop programs (how else do I access the keybindings?).
RIDE is cool (I'm biased), especially in the beginning when you want to explore the language interactively.
But in practice I prefer to edit plain text files with Vim with this plugin.
It provides keybindings with a configurable prefix key.
I think there's also a way to configure Vim or Emacs as an external editor for RIDE - that way you could have both the shiny session interface and the brutally efficient editor familiar to your fingers.
Alternatively, for the keybindings you could do:
setxkbmap -layout us,apl -option grp:win_switch
Pressing the "Windows key" and another key together inserts an APL char in any X11 app - convenient for email, chat, etc.
Save my program to a file. Run the program from the command line,
I put this on top:
#!/bin/bash
(echo ∇M;tail -n+3 $0;echo -e '∇\nM\n⎕off')|dyalog -script;exit $?
⎕io←0⋄⎕ct←0⋄⎕pw←32767 ⍝ opinionated :)
and do
chmod +x file.dyalog
./file.dyalog
with command line arguments (how do I take command line arguments?)
That's a bit of a problem. There's 2⎕NQ#'GetCommandLineArgs' for Windows but no working solution I'm aware of for Linux.
See the comments below and Adám's answer.
Distribute my program so others can use them.
Any way you like - github, gitlab, bitbucket, your own site, pigeons, etc
"APL session"
That's just the traditional APL term for "REPL".

How can I use scripting automation to record asciinema recordings?

Instead of recording my own keystrokes to create an asciinema tutorial I do want to script them, so I can easily improve my tutorial over time without being being stressed about redoing it each time I want to make a change, or spending a lot of time trying to correct typos in the recording.
Mainly I want to be able to do somethign like:
type: "df"
wait: 2s
type: "echo foo"
This would enable me to easily rebuild the recording from scratch when I change the script.
How can I do this?
I've searched for a lot of solutions for my own projects, and this is the solution that I've come up with:
My solution:
What I'm planning on doing for a project I'm in is to use both asciinema as well as demo-magic.sh.
Specifically, I'll be using asciinema for the recording with the -c flag (see here), and demo-magic.sh for the automated typing, since it supports waiting for commands to finish executing (or not) and custom wait times on top of that. The command would look something like asciinema rec -c "./mydemoscript.sh" myrecording. See the projects for proper usage.
Other things I've come across:
doitlive -- I'm not using this because it's more of a fake-typing automated thing where you actually have to "type like a madman", which could be useful if you're doing a talk in front of an audience but you don't want to mess up your keystrokes, or if you don't want to forget to do certain commands.
asciiscript -- it's written in Go and it works, but you need to compile it yourself, and it also doesn't support waiting for the previous command to finish.
spielbash -- a Ruby project designed specifically to automate asciinema recordings using tmux. I'm not using this, though, because it's not as portable since you need an existing Ruby installation, and more importantly, it keeps corrupting the active console I'm in, and there's also unpredictable corruption in the recordings. Also, the project hasn't been committed to since 2019.
termscript -- it just doesn't work for me, and it freezes my console. It runs on python 2.
UPDATE: I have recently come across terminalizer. It seems to provide support for an window-like border around the actual terminal, and it has a built-in GIF renderer, but I have not tried it.
There is a project svg-term which allows to record a screencast from a command, and I've seen a script that simulates commands being typed letter after letter.
For the moment I ended up using AppleScript to automate iTerm but this approach is buggy and locks you to MacOS and iTerm... and if you happen do to something during recording, you are doomed.
I am still looking for a better approach.
TL;DR: asciinema-automation should do what OP wants. Its dependencies are asciinema and pexpect.
(disclaimer: I developed it for my own usage)
Some time ago, I was also looking for a way to automate asciinema recordings and I saw the very nice answer of a-la-linuques. I chose asciiscript because it used asciinema, but it is not maintained anymore. I tried to keep on using it via a fork adding new small features, but being not very familiar with go, I finally decided to rewrite everything in python in this repo.
It reads bash files, where comments can give special instruction like adding time between command or key stroke, or wait for an expected output (see examples). Of course, this is very much in the spirit of asciiscript.

VSCode open file to be locked?

All
is it possible to have file locked when opened by VSCode ?
any extensions?
so if I check file by handle64 from sysinternals, it will tell me something like
> handle64.exe -a c:\XXX.txt
code.exe pid: 123 type: File c:\XXX.txt
Windows solution would be fine, cross-platform would be the best
The Windows-specific file API (CreateFile) has a number of access and sharing options, so yes, technically it would be possible. But that doesn't mean it would be desirable. There are a number of use-cases where it is quite desirable to allow another process to read, change or delete a file while it is "open" (really visible) in vscode.
I put "open" in quotes because to achieve the behavior it currently has, vscode probably closes the file as soon as it's done reading it, intentionally avoiding the sort of behavior you seem to be asking for. Since your question deals with a specific solution, rather than the problem motivating you, it's hard to provide more detail.

Is a launchd daemon the best route to go for reading/writing to privileged files in Cocoa?

I have an application which needs to be able to write to Any User/Current host preference files (which requires admin privileges per Preferences Utilities Reference) and also to enable/disable a launchd agent via its plist (writable only by root).
I'm using SFAuthorizationView to require users to authenticate as an admin before altering these values.
I'm trying to decide on the best way to do the actual altering of these values.
The cheap hackish option seems to be to use AuthorizationExecuteWithPrivileges() and mv or defaults, either via BLAuthentication or creating something similar myself. The downside to this is not getting the return value of whatever command line app I'm executing, plus some odd esoteric bugs I've encountered (such as getting a -60008 error in certain situations). This is strongly recommended against by Apple, obviously, but people do seem to do it and have some success with it.
The second most hackish option would seem to be the whole create a helper app with the suid bit set and the --self-repair option as discussed in various places. This seems possible, but like it's probably not much less trouble than the third option.
The third option is to create a fully fledged launchd daemon which will run as root and communicate with my application via a socket. This seems like a bit of overkill to read and write some plist files, but it's also possible I may find other uses for it down the road, and it wont be the only daemon for my application, so it doesn't seem unreasonable to just add another.
I'm thinking about modifying this sample code for my purposes.
My two questions are:
Does the launchd daemon option seem like the best route to go for this, or is there a much easier route I'm missing?
Has anybody else successfully used that code as a basis for something similar, and does anybody see any glaring issues with it I'm missing? I've used it successfully in a test app, but I'd be curious to hear you guys' opinion on it.
launchd is definitely the best and safest way to go: you’ll need an installer package to get your helper into place. Do be sure that your helper does and can do absolutely nothing except edit the files you wish to target.
No experience w/the code, but it’s based off of BetterAuthorizationSample, so that’s a nice start.
There's also the openauth API, which allows you to open files that require root privileges.

Resources