Scripting support

[ian-mcdowell]

Since this app is taking the route of writing its own shell (instead of trying to recompile bash/zsh/fish/etc), it'd be great if that shell would support scripting. I have a few proposals:

File-based scripting

For example. I would like to write a script to create a new directory and cd to it:

echo "mkdir $1 && cd $1" > mkcd
chmod +x mkcd
./mkcd foo

In order for the above to work, a few features are required:

• Execute script files (in $PATH and relative paths)
• Pass and interpret arguments to scripts when executing

GUI-based scripting

While file-based scripting is closest to what other shells do, since this app is geared towards touch screen users on iOS, it might be a better experience to create a GUI, similar to the existing History panel, that contains user-defined scripts.

• Runnable commands, like those from ios_system.
• Defined using a visual editor
• Sync with iCloud
• If stored in files, stored outside of the root directory (i.e. not editable text files).

[holzschu]

I can do the first (I have done it in the past, and removed it). Ios_system is already scanning the $PATH for script files. Arguments might be tricky but seem feasible.
I'm unsure about the potential impact on AppStore rules.

[palmin]

Is is written in stone that ios_system couldn't embed a regular shell @holzschu?

Not saying you should do this work, but do you see some roadblocks that make it extra hard compared to python and latex that you managed to port?

This would add support for

• bundling commands in script files
• control structures
• variables, $PATH just being a special case
• globbing

Both fish and bash are GPL but zsh and tcsh looks to be compatible with the app store from a licensing standpoint.

[holzschu]

There are no strong objections to embedding a regular shell, beyond a) it was hard to compile every time I tried and b) it would work better with interactive connections with the terminal. Except for running script files, of course. I didn't think of that.
I'll give another try to zsh at some point.

By the way, there are variables in iOS_system (access with setenv / unsetenv).

[palmin]

There are definitely things that could work better, by building out shell functionality to match the UI setting instead of plugging in a legacy shell, but it just seems like such a gigantic task.

[louisdh]

Some thoughts on scripting in OpenTerm:
• I'd like the scripts to be file-based. That way users can easily share and copy scripts.
• The full potential of scripts is only unleashed when a feature rich programming language is in place. This includes: loops, variables, functions, control statements, etc.
• The App Store rules require any programming languages to be interpreted.
• It might be interesting to include some sample scripts by default, to show users the potential.
• Creating/editing scripts should not be tied to OpenTerm. That way users can have a text editor app open in split view, with OpenTerm next to it.

This may sound crazy, but I'm currently considering writing a scripting programming language for this purpose. It would be similar to The Lioness Programming Language. The implementation of Lioness uses bytecode, but for the purpose of this scripting language, compiling to an AST and "walking" it would suffice.

What do you think?

[palmin]

I agree that file-based scripts sounds the most useful.

No matter how the scripting language is, there will be some users that would really want their existing scripts to work with no modifications. They will push for 100% compatibility with bash which would be hard to achieve even if this was a goal. For this reason alone, I think it is a good idea to make the scripting language quite different from the Korn and C shell variants that everyone knows and have certain expectations about.

[ian-mcdowell]

Awesome feedback guys, happy to see that my scripting support PR was merged. Some thoughts here:

• I agree with scripts being file-based. I also think that building some UI around it will help users manage scripts in a structured way. That's why my PR introduced a scripts folder with file-based scripts. That way users can edit them with whatever editor they would like, but GUI/autocomplete will surface available scripts/arguments as long as they're in the folder.
• Currently, scripts are just a set of commands to perform. There is nothing implemented (yet) for variables, loops, etc. However, I did implement a "context" that can store state such as variables.
• Sample scripts sounds like a great idea. Just need to make sure they don't get in the way (perhaps put them in the app bundle instead of the documents folder?)

The scripting & command running architecture in that change is designed to be extended (it's just a protocol to conform to). If anyone wants to add support for a different scripting language, it should plug in nicely.

[holzschu]

Both Lua and Python would fit the scripting goals (loops, variables, control statements, interpreted...) and are already ported. Lua is more standalone, Python requires a bunch of packages to be installed. Both can call shell commands (using system()).

[louisdh]

I'm gonna go ahead and create a new language specifically for scripting in OpenTerm. In theory we could support multiple languages, so Lua and Python are still future options.

[louisdh]

So now that Cub and SavannaKit are out I would like to have an open discussion about how script are supposed to work in OpenTerm.

Creating and editing scripts
I believe we've already achieved consensus that scripts should be accessible as files to users. This leaves the question wether the "Scripts" view (by @IMcD23) should still be part of OpenTerm. If so, should it list the Cub scripts in the current directory? Or the scripts in a .scripts folder?

Running scripts
In the current script implementation (in master) by @IMcD23, each script essentially becomes a command. In my demo I opted for a cub command, which takes the script name as a parameter. I'm not sure which I like more.

Also: I currently haven't required Cub script files to be executable (so no need for chmod +x). Is this acceptable?

[louisdh]

Fyi: I've pushed a working scripting prototype to the cub-scripting branch.

[ian-mcdowell]

Awesome stuff, @louisdh!

Creating and editing scripts

Unless we think that users would need scripts in a directory hierarchy, then letting them place the scripts anywhere might be better. I personally think keeping them all in a single directory is fine, that way we don't have to implement a search path & recursively search for scripts in the container. Keeping them in the .scripts folder lets us easily enumerate, and assume that all files in the folder are scripts.

Running scripts

Assuming that we are only planning on a single scripting language, then I don't think we need a cub command, and can instead make scripts run like any other command.

Here's the options:

• cub path/to/script.cub(scripts anywhere)
• cub scriptname (scripts in .scripts folder)
• scriptname (use cub for all scripts, scripts in .scripts folder)

I prefer the last option.

[ian-mcdowell]

Additionally, I have some comments to your changes in the branch. Perhaps open a PR, so I can review?

[louisdh]

PR: #75