Issuing Remote Server Commands

When using Robo-FTP on the local PC and connecting to the Robo-FTP Server on the server-side, this unique software combination permits a powerful client-server interoperability you won’t find anywhere else.

Important

Remote server commands are only permitted using Robo-FTP in concert with its companion Robo-FTP Server product both products of Serengeti Systems Incorporated.

When properly configured (i.e., a given user has the proper server access privileges), Robo-FTP can submit script commands to be run on the server. Such command(s) normally run in parallel with local PC scripts (i.e., each command is non-blocking), or they may be run synchronously (i.e., the command is blocking) where the script running on Robo-FTP waits for the server-side operation to complete.

The script commands submitted to the server are identical to those that are run locally. This is possible because Robo-FTP Server has the same script processing capability as Robo-FTP. This powerful combination permits Robo-FTP to have end-to-end control over file transfers far more completely than that possible with other FTP servers.

For example, Robo-FTP can issue commands that facilitates the following:

Anything that a Robo-FTP script can do locally can also be done remotely - namely, Robo-FTP Server has exactly the same script processing capability as Robo-FTP, and Robo-FTP has the ability to run scripts (or individual script commands) on the server as desired.

Important

There are obviously security issues related to this feature set. Remote server commands are not enabled by Robo-FTP Server by default. Only trusted users should be given the ability to run remote server commands. Furthermore the server-side administrator determines precisely which script commands any given user may be allowed to submit.

For example, if a user is not permitted to run complete server-side scripts then they would be denied use of the CALL or CHAIN script commands. Other even more potentially dangerous commands DOSCMD and EXEC are normally denied to all users. See the Robo-FTP Server documentation for more on this.

Remote server commands are issued and controlled via the RSCMD script command which sends a command string to the server. When RSCMD is non-blocking (the default), the RSCMDSTATUS script command may be used to check for completion of the command and the RSCMDCANCEL command may be used to cancel a server process that is in progress.

The following example shows how a script file may be uploaded to the server and then run under control of Robo-FTP.

SENDFILE "findnewest.s"

RSCMD "CALL 'findnewest.s'"

IFERROR $ERROR_RSCMD_INITIATED GOTO server_busy

It is presumed that running the script on the server in the example above may take some time to complete so the local script may continue with other processing. This is referred to as non-blocking mode. To test for completion of the server-side script, the local Robo-FTP script would do something like the following.

RSCMDSTATUS

IFERROR $ERROR_SUCCESS GOTO server_done

In some cases the server-side script will fail resulting in a result code that you may wish to test in the local script. When Robo-FTP Server reports an abnormal script completion to Robo-FTP, it includes the non-zero script result code. In such cases, Robo-FTP saves the server side result code (see Using Script File Result Codes) in the %rscmderror script variable.

If server-side script completion is expected to be prompt then the local script may just wait for it before continuing with the addition of the /wait option as shown below. This is referred to as blocking mode.

SENDFILE "findfirst.s"

RSCMD "CALL 'findfirst.s'" /wait

IFERROR $ERROR_SUCCESS GOTO server_done

If the server-side command launches a script (as in the non-blocking example above) and it does not complete in a manner expected by Robo-FTP then you can cancel the server-side script as shown below. The RSCMDCANCEL command initiates a cancellation process and returns immediately. Your script should call RSCMDSTATUS thereafter until a completion status is reported. Intervening RSCMD or RSCMDCANCEL commands are not permitted until the cancel operation completes.

RSCMDCANCEL

IFERROR!= $ERROR_SUCCESS GOTO cancel_failed

:cancel_loop

PAUSE /for=1

RSCMDSTATUS

IFERROR!= $ERROR_SUCCESS GOTO cancel_loop

Be aware on some occasions the server-side script cannot be immediately canceled (e.g., the script is in the middle of a non-cancellable operation like zipping, unzipping, encrypting, or decrypting a file) so your script needs to accommodate a waiting period as in shown the example above.

Individual commands submitted to the server (e.g., PGPENCRYPT, ZIP) cannot be canceled.

For more information see the descriptions of the various script commands.