At some of our customer sites, I have a host-based script which is invoked by our host application. It sends some control codes to the Procomm Plus (Windows) client that instructs Procomm to receive a file and then send that file to the default printer on the user's PC.
Strangely enough, my script file worked without a flaw for one of our technicians who was using AbsoluteTelnet!
Below are the pertinent (bash) lines from the script file. The "echo" statements send Procomm the commands to (1) receive the file, and (2) "type" the file to the default printer. The "sz" command is the ZModem Send utility.
-----------------------------
echo -e "\\004GETFILE ZMODEM\\012\\004\\c"
sz $MYNAME
echo -e "\\004DOS \\"TYPE \\\\\\\\$MYNAME>PRN\\"\\012\\004\\c"
-----------------------------
How did this script work with AbsoluteTelnet? Does AT support Procomm Plus "Aspect" scripting?
[size=1][ May 16, 2007, 02:42 PM: Message edited by: Brian T. Pence ][/size]
Steve,
AbsoluteTelnet does not support this scripting, but from what you describe below, I would expect the file to transfer, but not print. AbsoluteTelnet will recognize the beginning of the file transfer, even without the GETFILE ZMODEM command.
You can do something similar in Absolute, which requires only the zmodem sz command. Really, any terminal that fully supports zmodem should be able to do it this way. However, depending on the terminal, YMMV.
sz $MYNAME
sz -i "acrord32 /p /h $MYNAME"
The first sz sends the file.
The second sz executes the acrord32 command on the PC side to print the file. A similar command can be used to just view the file:
sz -i "acrord32 $MYNAME"
Brian:
Thanks again for the response.
I never realized "sz" had options like "-i" and "-c". I know the version on our old SCO boxes does not (it rejects both arguments). However the version on our Linux boxes accepts them.
Can you give me some guidance on it's use in conjunction with AbsoluteTelnet? I have tried several attempts but nothing is executed. I tried several different commands, which are find-able via my XP PATH variable (e.g., "calc.exe", "notepad.exe", etc).
I even tried an "internal" Windows command like this (from Linux):
# sz -i "dir"
No error appeared on the Linux side (although the command prompt wouldn't re-appear until I pressed ENTER). But the only thing I saw happen in AT was a dialog box titled "ZModem Receive"; and after a few seconds it disappears.
It might not be in the version you have. Try this:
<old link removed. Go to downloads for the latest version>
Brian,
What is the earliest version of A/T in which remote command execution via zmodem was available. I'd like to implement some windows integration features with my charmode linux app using remote commanding, but my clients use a wide variety of A/T versions (going all the way back to 2.85 I think). I'd like to know how many of them I'll be leaving in the dust if I do the new coding. Just found this capability while reviewing the sz man page, and I'm really jazzed about the possibilities, and glad to know that A/T supports it. To do this type of integration in the past I had to have the clients use much more expensive comm packages on their desktop (FacetWin, etc.)
Thanks,
Doug Campbell
I believe that would be 5.44. It's a fairly recent addition.
With the rapid development of the product over the past few years, and since Absolute Telnet now has host integration features, I'd like to propose a feature to address these (to be added to the large wishlist, I'm sure):
It would be very helpful to be able to query the version of A/T from the host; not only would this assist with the discernment of specific features available, but also with configuration management. Should an organization wish to implement some emulator-dependent features in the host program, knowing that 30% of their clients are running a version of A/T that is more than 2 years old may prompt a batch upgrade. Windows-centric shops may use server-based products such as SMS for workstation configuration management, but for us DEC/Sun/Linux shops with windows clients (in which A/T plays a large role), software inventory of the connecting windows clients can only be determined by the individual HTTP, SMB, telnet/SSH connection requests.
I'd like to use the Z-Modem remote execution for tighter windows integration with the host apps, but I think only about 10% of my clients have A/T of version 5.44 or higher. A terminal version identification string would help me to help them locate the workstations that won't be able to use my new features.
TIA for your consideration,
Doug Campbell
WRT to the previous post, I just looked up the VT Device Attributes (DA) reports that might be used to determine the remote terminal version. I assume that the A/T version could be considered "firmware", so the secondary DA request might be used.
When sending the secondary DA request,
CSI > 0 c
from the host to A/T, the client gives a response of
CSI > 1 ; 10 ; 0 c
which indicates VT220, firmware version 1.0, no options.
Perhaps that firmware version could be reported as 535 (the workstation I was using had A/T v5.35) so that the host could know what special features it could utilize on the connected terminal.
I'm sure you can think of a dozen other VT CSI codes that might be more appropriate for this purpose.
Doug Campbell
BTW, my VT codes research came from [url= http://vt100.net ]VT100.net[/url]
The problem with changing the implementation of those standard codes is that Absolute is supposed to report those values from the terminal being emulated, not values related to Absolute itself.
The right way to do this is probably through setting a shell environment variable with the current version number. The problem with this is that it would only work in the version where I implement it and only on servers that support the option (OpenSSH 3.9 and up I believe). This helps for all new users, but doesn't help you determine the version from your installed user base.
Regardless of how it is implemented, it would be new code for you, and a response/value that would not be present in all previous versions. I think the ability to query the remote version of A/T would be a big benefit, even if "old" versions simply have empty replies. Gotta draw a line in the sand somewhere.
