Command

Tue May 19 21:43:56 EDT 2009

This connector executes a command and communicates the I/O.

Note that the command will be executed as the same O/S user account as the application. The executed command will not inherit any shell environment, so if that is necessary, you should wrap your target command in a shell script. Call that shell script from this plug-in.

In other words, shell environmental variables (e.g. ${HOME}), and built-in commands (e.g. 'ls') are not directly available. Instead, they may need to be wrapped in a shell script that is executed within a shell. For example, ls -al will not work, but /bin/sh -c 'ls -al' will launch a Bourne shell to execute the ls -al command and produce a long-form file listing. Notice the extra level of quoting around the ls -al which needs to be considered a single argument to the -c flag. The spaces embedded in this sub-command are later interpreted by the shell.

For Unix-type systems, "/bin/sh -c" is the recommended shell execution. For Windows 95, use "command.exe /C", and for Windows NT, XP, or newer, use "cmd.exe /C"

The present working directory (PWD) of the command is set to the application's home directory.

If a command terminates (normally or because of an error), the "source.retry" property is used to determine how often to re-run the command. This can be used to repeatedly schedule a command that polls for some device status and terminates.

STDERR

If you enable debug mode, the "standard error" stream is logged. Otherwise it is drained and ignored. If you need the data from the standard error stream, you must explicitly map the standard error stream to standard output stream, via the "2>&1" command line switch. This syntax works on both Unix-based and Windows systems.