Tony Gravagno wrote:


Tony, while I'm not arguing your points, I'm a little weary of being your
platform for pontificating this issue. I'm looking for the way to automate
a file transfer issue, nothing more. I may be able to do it thru ssh, once
I finish learning and testing it. But if not, I'll teach the users gftp.
There's no reason, in this situation, that this thread needs to spin off in
your favorite direction. I do appreciate you running the issue by the
konsole developer, but it's more theorical interest than practical at this
point. From my point of view, there's nothing wrong with asking what tools
are already available, and looking for a clue to getting started in a
particular direction.

Art

Bill H wrote:


Now your are putting words in my mouth. Go back and read what I wrote. I
switched specifically of productivity and reliability issues! Morality is
your phrase, not mine!

Art

Art Martz wrote:
Art, yes, I've beat the point into the ground, and while I do often
enjoy the rhetoric, in this case I really don't want to offend you or
anyone else in the process. I'm just pointing out that you told us
what tools you want to use and I confirmed that those tools are all
that are necessary to do what you want. It doesn't get much simpler.

I'm guessing the key problem is that Konsole is written in C++. If it
were written in Pick BASIC then there'd probably be no question about
getting the source and tweeking it. What we need in this market is
some kid who will do C coding for pizza.

Have a nice one bud, just ignore me...
T

Art:

"Art Martz" <artmartz (AT) triad (DOT) rr.com> wrote


[snipped]

We've set up several automated communications from a single machine to
others using both FTP and SFTP (FTP with SSH). The SFTP was a little tricky
but works fine. If that's all you're looking for here's a brief overview of
what we do:

1) Create a "cron" style BASIC program to run as a phantom (reads service
items).
2) Create a simple BASIC program to do something (like build a CSV file for
someone else).
3) Build a configuration file with the Linux commands to:
a) build a Linux script (or DOS batch file) to ftp
b) execute the script (or batch file)

A configuration file might look like:

systbl 'SFTP.CONF' size = 1246
01 /netdrive/tac
02 unix:
03 /
04 .txt
05
06 sftp -b ##FTPSESSION## -oPort=2222 ##FTPHOST##
07 chmod 755 /netdrive/tac/##FTPSCRIPT##
08
09
10 ** ----------------------Documentation ----------------------------**
11 **
12 ** This is the record that controls all SFTP activity within the
13 ** current mvDb account. The directory where Ftp activity occurs
14 ** from is defined along with whether this is a Unix or Dos host.
15 **
16 ** 001 - The network path to the ftp directory. This value should
17 ** be the same as the 'Q' pointer EFTFILE, prepended with the
18 ** host item in field# 2.
19 ** 002 - The D3 Hosts driver to the remote file system
20 ** 003 - The path separator ('\' for Windows and '/' for Unix)
21 ** 004 - The file extension for the ftp script file. For DOS this
22 ** is usually '.bat', which is an executable, and for unix it
23 ** is usually '.ftp' which does not have such a meaning. In
24 ** unix the file has to be executable.
25 ** 005 - not used.
26 ** 006 - The actual Ftp command to execute
27 ** 007 - The pre-execution O/S commands. These are used for things
28 ** like changing the permissions prior to execution.
29 ** 008 - The post-execution O/S commands. These are used for things
30 ** like removing the file after execution.

And some code might look like:

*
** copy spooler entry to Ftp O/S directory
DATA "(FTPFILE " : ReportId
EXECUTE \COPY PEQS '\ : SpoolerId : \' (D\ CAPTURING Output
*
** Substitute data into Ftp session text file
IF OkToFtp THEN
Subs = '##FTPLOCALPATH##' : VM : FtpPath : PathSeparator : ReportId
Subs<-1> = '##FTPREMOTEPATH##' : VM : ReportId
CALL mwSUBSTITUTE (FtpSession, Subs)
*
** update the session commands to the Ftp directory
WRITE FtpSession ON FTPFILE.FV, FtpSessionId
*
** call ftp process
CALL FTP.SCRIPT (RemoteHost, FtpSessionId, NewFtpConf, FtpError)
IF FtpError NE NULL$ THEN
CRT "NOTE: Please check Application Logs."
END
END ELSE
HLDMSG = "Ftp not configured to use. File creation successful."
CALL LOGMSG ('', 'ALL', HLDMSG, '')
GOTO CLEAN.UP
END

and the script program might look like:

dtabp 'ftp.script' size = 6328
01 SUBROUTINE FTP.SCRIPT (RemoteHost, FtpSessionId, FtpConfId, FtpError)
..
..
09 ** Notes:
10 **
11 ** This program is designed to manage FTP files. Simply call this
12 ** subroutine if the Ftp process is required.
13 **
14 ** Input-:
15 ** RemoteHost--: The IP address, or domain, of the remote host.
16 ** This is the machine that acts as an ftp server.
17 ** FtpSessionId: The ftp session commands O/S path Id
18 ** FtpConfId---: A custom FTP configuration file to use for
19 ** this call. Same format as regular Ftp conf
20 ** item but used for different ftps (like sftp).
21 **
22 ** Output:
23 ** FtpError----: The error message for any errors. A null value
24 ** indicates there were no errors.
25 **

The tricky part of the ssh was using the "Pick" user (if that's what you
have in the "/usr/lib/pick/pick0" file) and creating an SSH public key in
"/home/pick/.ssh/id_rsa.pub". That file had to be sent to the recepient to
make sure when you tried to sftp to their site their machine wouldn't prompt
you for a password, which makes automated ftp impossible. :-)

If you need more information let me know. Hope this helps.

Bill

Tony Gravagno wrote:

No offense taken. One point to consider is that using a standard tool or
function means that future release compatiblity should not be an issue.
With a custom modified tool, now you have a branch in the versions, and
that has to be reconciled with new releases each time a new OS or tool
version is released from the distributor. So in other words, if I hire you
once to customize konsole, I get to pay you again each time there is a new
version of konsole.


True, my AccuTerm background is showing. An you basically said it doesn't
exist on the shelf. Dang. But there have been numerous suggestions as to
alternative ways to accomplish the same thing, once I elaborated a bit what
I was trying to accomplish.

Art

Bill H wrote:

I'm not sure if what you describe fits my situation. Important points to
consider: 1) the main host d3/aix site is the only place pick code is
running, 2) the main host 3/aix site is the only site with a static IP
address, 3) the remote linux workstation is a generic linux install, *not*
running D3, and does not have a static IP address. It using dhcp and nat to
access the internet.

If I understand the other ssh solution proposed here, the linux workstation
initiates an ssh tunnel to the aix host, then the d3/aix host uses that ssh
tunnel establish by the linux workstation to initiate file transfers from
the linux workstation to the d3/aix host.

That should mean I can setup the connection definition on the linux host in
config files (or desktop icons), and then once the connnection is
established, the d3/aix host can take over. Which means the user doesn't
really have to understand what's going on.

Art

Art Martz <artmartz (AT) triad (DOT) rr.com> wrote:
I wasn't proposing a fork to Konsole. I have an inquiry out to the
primary Konsole developer which I'll pursue regardless of this
conversation. I've asked him if he would accept payment for adding
AccuTerm-like features to the base code. From there anyone who wants
to fix bugs or enhance the code can do so. This is the OSS model, and
with some OSS licenses, returning the code to the author is a legal
obligation. Again, Art this isn't even related anymore to your
inquiry, we could be talking about any OSS project. I just don't
think people understand how this open source thing works.

The cheap people in the crowd will say "hey, I'll just wait for
someone else to fund development and then I'll get the equivalent of
AccuTerm over Linux for FREE - whoopee!" The problem is that no one
will fund the project so the project will never happen - and every
couple of months someone new will ask for some feature on Linux that
we could have but no one wants to kick it off. This very "let someone
else do it" problem ripples through the MV world in terms of
documentation, marketing, education, and MV OSS projects. This is why
we are where we are.


(Mom! He's preaching again!!)

Art Martz wrote:

Art,

I got this to work using an emulator called TeemTalk. TeemTalk can't
execute shell commands on the Linux workstation but it does include a
scripting language. The TeemTalk scripting language, in turn, can
execute shell commands on the workstation and a TeemTalk script can be
triggered by an escape sequence from the (Pick) host.

Hope this helps.

Steve Lancour