This might help with the shell, parts apply to all of JNode

I understand the current system of org.jnode.shell.CommandLine and org.jnode.shell.help.* are already in place. However I think they are seriously flawed by design. Rather than placing the burdon on the App to return completion information and process the commands, wouldn't it work better to let the shell handle all that?

The CpCommand should be able to run in MS Win JVM, or Linux JVM, as well as in JNode. This applies to all commands, Cat, Grep, Diff, with the exception of a few, like fdisk, which depend on the OS API.

I propose the answer is a new list and a new command. The shell keeps a list of commands and args, this should be in a generic form (xml?) and specify the command, version, and it's optional args. That way a non-JNode app can still support command completion. System Admins could use it to help keep users from accidently using dangerous commands, and you could customize it to the options you use most.

The List

This list is maintained by the shell and contains the name, version and params for a command, this will allow a user to edit them if they want different command line completions. This list should import/export as simple generic style, maybe xml. It is internal to the shell so it doesn't matter how the shell wants to handle it internally.

The file format can be, maybe a string like,
    "CpCommand\t1.6\t[none[],help[-h],help; verbose[-help],copy[verbosity[-s,-v,-V] [url,file]* [file,dir]]]"
or xml like,
    <command alias="CpCommand" class="org.jnode.shell.command.CpCommand" version="1.6">
        <paramlist desc="none"/>
        <paramlist desc="help">
            <param value="-h"/>
        </paramlist>
        <paramlist desc="help; verbose">
            <param value="-help"/>
        </paramlist>
        <paramlist desc="copy">
            <optionlist desc="verbosity">
                <option value="-s" desc="silent"/>
                <option value="-v" desc="normal"/>
                <option value="-V" desc="verbose"/>
            </optionlist>
            <param type="url,file" desc="source file" multiple="true"/>
            <param type="file,dir" desc="destination"/>
        </paramlist>
    </command>

These can also be wrapped with a language code to assist with internationalization, as they can also be joined as strings "cat commandcomplete.txt mycommands.txt > newcommands.txt" with little ill effects.

The Command

The command will allow you to scan a class, jar, directory, or sub-directories for updates to the list. This command is looking for a method call XYZ, maybe getJnodeShellInfo() and will return a String. This string will contain at least the command and version. If a listing for the command and version are not in the list one is added. if a conflicting duplicate is found the user is shown the diff and prompted by the user which to use. This command can also be used to remove deleted commands from the list

The Shell

I propose that the shell internally keeps TWO list of commands and args. The first is a cache of the commands and the default params, the second is the user modified list. These two list should be exportable and importable in a generic form, xml, and specify the command, and it's optional params. When a command is entered it can be checked from cache, if not found the class, jar, etc can be scanned for the getJnodeShellInfo() method and if found update the cache.

The Unsupported Commands

If an app or command wasn't written for JNode, as many are not, then a developer/user supplied command completion file can be supplied. I personally recommend all should be made like this, that way these commands can be used outside of JNode.

RANT =====-----

This API needs to be defined better than it is. I'm finding many high level applications using JNode dependant packages. Develop your code outside of JNode when at all possible, and remember where you are operating. If I understand correctly there are 4 areas which are, Kernel, plugins and devices, the JNode OS and shell, and then applications. If your code lives in one place it should NOT work in another. Use the API, not internal structures.

Most commands should be able to run in MS Win JVM, or Linux JVM, as well as in JNode. This applies to all commands, Cat, Grep, Diff; with the exception of a few like fdisk, which depend on the OS API.

I will use EchoCommand as an example. It does not depend on JNode and should not be written as it is in JNode. It should be as follows:

public class EchoCommand {
    public static void main(String[] args) {
        if (args.length > 0) {
            System.out.print(args[0]);
            for (int i = 1; i < args.length; i++) {
                System.out.print(" " + args[i]);
            }
        }
        System.out.println();
    }
}