Command Line Utility Output

[marchbold]

Feature

Recently we have been discussing the development of an AIR package manager to simplify handling dependencies on AIR applications.

To aid this development it would be helpful to be able to develop command line utilities in AS3. These utilities would not have any window or ui, simply be commands run on the command line.

Required Changes

1. Removing the UI window requirements

We can currently hide the window but removing it altogether would be preferable.

2. Access to stdin/stdout functionality

Currently input is limited to the invoke event to get arguments and output to trace statements. We would need to be able to:

• capture keyboard input from the terminal
• write / update output to the terminal

3. Package into a command line utility (could be an alternative of adl?)

Example

This is a simple example of what is currently possible.

In this example, we simply use trace to output the command line arguments.

package
{
    import flash.desktop.NativeApplication;
    import flash.display.Sprite;
    import flash.events.InvokeEvent;

    public class Main extends Sprite
    {
        public function Main()
        {
            trace( "start..." );
            NativeApplication.nativeApplication.addEventListener( InvokeEvent.INVOKE, invokeHandler );
        }

        private function invokeHandler( event:InvokeEvent ):void
        {
            trace( event.arguments );
            NativeApplication.nativeApplication.exit( 0 );
        }

    }
}

To invoke this on the command line we would compile the swf and then use a simple app xml:

<?xml version="1.0" encoding="utf-8" ?>
<application xmlns="http://ns.adobe.com/air/application/33.1">
    <id>Main</id>
    <filename>Main</filename>
    <name>Main</name>
    <versionNumber>0.0.0</versionNumber>
    <initialWindow>
        <content>Main.swf</content>
        <visible>false</visible>
    </initialWindow>
</application>

We can create a small script to invoke this using adl and passing arguments, eg if we have the following in a Main.sh script (with Main.swf and Main-app.xml in an out directory):

#!/bin/bash
adl -profile extendedDesktop out/Main-app.xml out -- $@

Then we can call it using

./Main.sh -s some_parameter 

This would result in the following output:

start...
-s some_parameter

[rewb0rn]

I am wondering, is there a reason you need to develop the command line tools in AS3? Or is it just a preference to keep everything in the AS3 eco-system?

Personally I was always thinking it would be great to have a centralized market-place where developers can acquire ANEs, libraries or even assets from other developers like Distriqt. Similar to the Unity Asset store. Money always fuels an eco-system and open-source providers could still offer their packages for free. The central market-place would make the most sense if it is provided by Harman, but if you already plan to work in a similar direction, maybe it could be a combined effort?

[marchbold]

The apm tool idea is more around adding packages (ANEs/SWCs) to an application (downloading them from a central repository and their dependencies) and then creating the application descriptor (manifest additions / info additions etc) from these.

The concept of a central marketplace is a separate concept and completely complimentary. This is more akin to the "import package" functionality in unity once you have purchased from the asset store.

The reason for developing this in AIR is just the classic concept of developing the tools for an ecosystem in the same tech stack. Advantages I see are that the users of the tool are already familiar with AS3 and hence would easily be able to contribute or modify the tool. Also that users could develop AIR based UI clients and simply import the functionality of apm as it would be written in as3 and could be imported as a lib.

[marchbold]

@ajwfrost Any comment here? We would like to know a direction for this tool before we start development.

[ajwfrost]

Hi

This is done, at least an initial version for Windows. For now it's just available via ADL where you can add a command-line option which switches it into this mode. I think it's also done for Linux, in case that helps...

Looking to merge this in and release it in our next release (which was going to be in about a month, but we maybe need to accelerate that plan given the other issues re. that missing symbol and some signing issues..)

thanks

Andrew

[marchbold]

Okay more just needed to know that it will be possible and that it is in the works, this will at least give us the confidence to start down this path.

Would prefer a complete release when it is ready rather than a partial one.

[ajwfrost]

Hi @marchbold - this isn't really a "complete release when it's ready" I'm afraid, but we have some initial support for this in our release that's pending deployment now (should be up today hopefully or tomorrow latest). But we'd appreciate feedback from everyone on whether this mechanism works, or whether there should be some changes. The "stdin" support I think may need to change slightly.. Looking back to your original message above: this is currently only available via ADL with a command-line option. Would that be a problem? I'd wondered if we could package this up into a single application i.e. extend ADT so that we could generate a new application that's just a command-line app.. but this would be quite a bit more effort.

From the release notes:

Experimental command-line support: this is initially available on Windows and we plan to roll this out also to MacOS and Linux platforms. If a SWF file doesn’t require access to the Stage or other window-related components, it can be run via ADL with a -cmd flag, for example: [sdkfolder]\bin\adl.exe -cmd application.xml Access to the stage property or functions relying on this will throw run-time errors which are still displayed as pop-up windows, unless the -nodebug command-line option is also used. The “System” class has been updated to include the below functions:

    public static native function output(outString:String):void;
    public static native function input(format:String):String;

The ‘output’ method simply writes the string to the console (via stdout). The ‘input’ method accepts up to 256 characters of input from stdin and returns a new string containing these characters; the ‘format’ parameter is currently ignored.

[marchbold]

Looking good @ajwfrost ! I'll hopefully get some time over the christmas break to have a play with this.

As a side note, I think you should really start beta builds, rather than pushing things like this into the release builds. Something as incomplete as this should never be in the release build.

The issue with just using adl is around distribution and ease of use, eg providing an app to a developer to use which is just an executable is much more common than providing a package of files and relying on access to an AIR SDK. I have no problem with using this approach initially but the end goal should be a complete captive runtime equivalent for a command line app.

[mrchnk]

I am finding that feature very useful in CI for running tests or other related jobs since the latest MacOS and Windows have strict restrictions on how windowed desktop applications should be executed. Looking forward to putting my hands into the Unix version of adl to run tests in a headless container environment.

[marchbold]

Any updates as to when we can expect a macOS version? Really keen to get this moving along for the air package manager.

[mrchnk]

I tried that feature for the Linux version of SDK (33.1.1.575).

package {

import flash.display.Sprite;
import flash.desktop.NativeApplication;

public class App extends Sprite {
    public function App() {
        trace("Hello, Linux!");
        NativeApplication.nativeApplication.exit(0);
    }
}

}

During execution, I got additional unexpected output to both stderr and stdout

root# adl -cmd App.xml

stdout

loadRuntime: /air-sdk/adl/bin/../runtimes/air/linux/Adobe AIR/Versions/1.0/libCore.so
Hello, Linux! 

stderr

(process:4386): Gtk-CRITICAL **: IA__gtk_clipboard_get_for_display: assertion 'display != NULL' failed

(process:4386): Gtk-CRITICAL **: IA__gtk_clipboard_clear: assertion 'clipboard != NULL' failed

(process:4386): Gtk-CRITICAL **: IA__gtk_clipboard_get_for_display: assertion 'display != NULL' failed

(process:4386): Gtk-CRITICAL **: IA__gtk_clipboard_clear: assertion 'clipboard != NULL' failed  

That output should be disabled by default as unexpected behavior. And having an extra flag -verbose to adl executable would be the better option for that.

[ajwfrost]

Hi Thanks for that; the first one is some debug output left in accidentally by the looks of it! The GTK output is happening due to default code (gtk_clipboard_get) where it's using the default display and we don't have one in command-line mode, so we can just prevent those calls where there's no default display... thanks

[marchbold]

@mrchnk Thanks for checking this on linux!

[mrchnk]

You can use g_log_set_default_handler to turn off gtk logs by passing noop logger function.

[itlancer]

@ajwfrost Is it possible to package AIR application (Linux x86_64 and Windows interested right now) to work in console mode? As I see right now it possible to launch it using adl. But I need to run it without AIR SDK and without display. I tried to run packaged AIR app using: MyApp.exe -cmd via cmd/Powershell. But it immediately return output (cause it not console app) and something wrong with codepage (charset) of symbols printed by System.output().

[ajwfrost]

Hi

We don't have this capability at the moment: the executable that gets used when you package up an application is a normal Windows executable, as you've seen.. so to handle this we'd need to have an alternative option in the packaging process, and a separate template executable for command-line apps. The simplest mechanism currently would be to use adl (with the "-nodebug" option alongside "-cmd").

We can look at a new platform/packaging option here perhaps, if there's interest in this?

thanks

[itlancer]

@ajwfrost, yes it interesting for us. We would be able to create command-line AIR applications which could be used as services or in automation processes. Especially as Linux-based console apps (for CI/CD, Raspprery Pi-like devices and so on). May be in future it also could be usefull to create even web services for some developers.

[2jfw]

@ajwfrost: Would it be possible to look into options to run an AIR app as a Windows Service, too? So if it was defined to run as a service it would auto start automatically (unless turned off by the user) and also be headless?

EDIT: Something like this can already be achieved with NativeApplication.startAtLogin

[marchbold]

Super interested here too :)

Using AIR to create command line utilities would be massive for us, particularly if there was linux support as well.

[myflashlab]

This will be super awesome. Looking forward to it 🤩