Open Emasoft opened 1 year ago
That one is going to take time. Because all commands are happening inside the same process space, there is currently no way to force-kill a command and restore the app to a useful state. At the very least, you will be unable to relaunch the same command and to quit the app with exit. If things have gotten to this point, the best course of action is to force-kill the window on the iPad (with the 3 dots at the top of the screen) or the entire app on an iPhone.
This is an important issue, so take your time. Meanwhile, can you add a button that send a CTRL-C command in one go? Having to use first the toolbar button for CTRL and then the C key from the ios keyboard often fails to send the command.
You can now configure the toolbar (type config -t
and edit the file it creates), so you can add a button to send Ctrl-C in one go if you want (you can also add Ctrl-D, which is more definitive). But I'm almost certain that the problem is not the emission, it's the reception: the command is too busy doing what it does to realize it has received an interrupt signal.
The toolbar customization works very well, I've finally added a lot of functions to it (like pickFolder for example).👍🤠 What I'm still missing:
Any suggestion?
Hi, these questions are challenging. We're getting closer to the limit of what can be done.
open shareddocuments:///path/to/directory
with the path to the current directory, and it will work. But there's a catch: it won't work with .
(so you need the actual path, the result of pwd). It works with open shared documents://$PWD
if there are no spaces in the directory name (so it will work with sub-directories of "On my iPad", but not with sub-directories on "iCloud folder"). If there are spaces, you need to replace them with "%20", because it's a URL. All in all, it seems like something that a smal Python script could do. ln .bashrc bashrc.txt
will create a bashrc.txt
that is visible from the other apps. And any change you make to the bashrc.txt
file is reflected in the .bashrc
file (because hard links are basically creating two entries for the same content). There are limitations, but it's very convenient.
https://discord.com/channels/935519150305050644/944259147245977642/1044207691234541648jsc
(I'm not entirely sure, though). I've added it to the TODO list: https://github.com/holzschu/a-shell/projects/1Good answers, thanks! The only perplexity: what about getting the externalUUID for a location? I successfully opened a file in Textastic from a-Shell with an externalUUID provided by Textastic, but is there a way to get the externalUUID from a-Shell for a given folder?
I'm not sure I get the question. Are you asking about the result of pwd -P
? If not, what is the "externalUUID"?
The externalUUID is a parameter used in iOS url schemes. Take a look at this documentation for Textastic: https://www.textasticapp.com/v9/manual/integration_other_apps/x-callback-url.html
For example this command worked from a-Shell:
open textastic://x-callback-url/open?location=external&externalUUID=551DAB7A-2E47-44F9-B0FE-F145B1E42624&name=toolbarDefinition&path=.)
The shareddocument version worked too, but it is way slower since it is not a direct link to the app but you must manually share the file selecting the app:
open shareddocuments:///private/var/mobile/Containers/Data/Application/54D91A19-D998-4
5C0-9A6F-1F3017711752/Documents/toolbarDefinition
Hmmm... you could have a look at pwd -P
inside a-Shell main directory.
It should look like /private/var/mobile/Containers/Data/Application/<UUID>/Documents
and I strongly suspect <UUID>
in that case will be 551DAB7A-2E47-44F9-B0FE-F145B1E42624
.
Also, you can probably try: open textastic:///private/var/mobile/Containers/Data/Application/54D91A19-D998-45C0-9A6F-1F3017711752/Documents/toolbarDefinition
@holzschu No, that is the point. This doesn't work:
open textastic:///private/var/mobile/Containers/Data/Application/54D91A19-D998-45C0-9A6F-1F3017711752/Documents/.toolbarDefinition
Only this one works:
open textastic://x-callback-url/open?location=external&externalUUID=551DAB7A-2E47-44F9-B0FE-F145B1E42624&name=.toolbarDefinition&path=.)
It seems that the externalUUID is different from the UUID.
Currently the CTRL-C command (SIGINT) is often uneffective in a-Shell, because the keyboard input is often useless when a process is unresponsive. A 'Kill Process' button on the toolbar, equivalent to a 'kill -9' (SIGKILL), would be a great solution.