NON-INTERACTIVE ftp client please !!!!

Hello everyone,

I’m actively looking for a Non-Interactive FTP
client : a ftp client that can read commands from a file instead of using
the command prompt. I don’t want to develop one!!!

I know Micro$oft provides such a client with WinNT, is it available with
QNX. Sure I’m not the first person to think about it!!!

Pleas help!!

P.S. I’m ready to pay $$$ for it!

Stef

In article 39ecceb3$1@news, “bozo” says…

Hello everyone,

I’m actively looking for a Non-Interactive FTP
client : a ftp client that can read commands from a file instead of using
the command prompt. I don’t want to develop one!!!

I know Micro$oft provides such a client with WinNT, is it available with
QNX. Sure I’m not the first person to think about it!!!

Sure … ftp.qnx.com/usr/free/qnx4/tcpip/ftp/libftp-qnx.tgz > :slight_smile:
If not requested for qnx4 … port it to QNX RTP. (You have to ask the
unknown author for a commercial license … )

or you could just use REBOLs get and put FTP comands (many more advanced things you can do with it to) it runs on MANY OSs right now
and its free and VERY small, join the REBOL ML to find out far more
advanced things many people are doing with it right now, carl`s
the CEO of REBOL and the guy behind the original AmigaOS.

http://www.rebol.com

Stef


heres a rather nice post from the REBOL ML that might give you an

idea were its going in the future, QNX4 and RTP /CORE versions exist.


From carl@sassenrath.com Wed, 19 Jul 2000 9:39:28 -0700
From: carl@sassenrath.com
To: list@rebol.com
Subject: [REBOL] where are all the components? Re:
Date: 19 Jul 2000 11:39:28 GMT

Jake, you got it. You said it.

Here’s the way I summarize it:

It all comes down to communications. The object-oriented approaches (CORBA, etc.) are trying to do it with their arms tied behind their backs.

Good communications requires language, not just static language, but living, mutating language. Language = expression = function = action.

Now, how do we get others to understand that? The concept of language is so fundamental to humans. It’s not obvious because it is so obvious.

-Carl
REBOL’s Dad



At 7/17/00 01:52 PM -0700, you wrote:

Hi all,

Here’s a longish rant I originally sent to some friends this weekend
about where I see REBOL having a lot of promise in “the big picture.”
I’m sure I’m not saying anything that RT isn’t already thinking of, but
considering how long it’s taken me to really GET what REBOL may mean for
the industry, I hope this might be useful for some readers of this list
who are still new to REBOL… and of course, if I’m way off base in my
logic, I’d like to hear about it. > :slight_smile:

I remember reading some very optimistic books by a team of authors
(Orfali,
Harkey, etc.) extolling the virtues of CORBA, The Distributed Objects
Survival Guide being the most typical. In these books, they painted
this
very compelling image of a wonderful world in the near future where all
software would be made out of a bunch of components, and companies and
end-users would be free to either write their own or buy (or in the case
of open source, download) ready-made and tested components that others
had
written. They saw CORBA as the horse most likely to win the race of
being
first to market with a workable component architecture that could bring
about the “component revolution.”

So, where are all the components? Why is it that, outside of things
like
VBX controls and JavaBeans that have been very successful within very
limited domains, we still haven’t progressed beyond, essentially, shared
libraries?! I take that back: MS has done a good job of implementing
new
Windows technologies in terms of COM components, but, even on Windows,
it
doesn’t seem like ISV’s are embracing COM within their own
applications.
And, on UNIX and Mac and BeOS, neither COM nor CORBA seems to have taken
off, and even though GNOME apps are linking with an ORB now, I really
don’t see GNOME doing anything with CORBA that it couldn’t just as
easily
have done without it.

Long story short, I think one of the answers might just lie with a
concept
REBOL is pushing, dialects. Think about some of the most highly
successful Internet protocols we use today: SMTP, HTTP, FTP, NNTP.
While
not an “Internet” protocol, let’s add SQL to the list. What do they
have
in common? Instead of using CORBA or COM or some binary packet format,
all client/server communication is in the form of domain-specific ASCII
text commands! Why can’t we take that architecture and apply it to
creating components that communicate within a single machine? In some
sense, we’re already doing it in a very static and primitive way with
things like /etc files and command-line arguments.

Another piece of the puzzle is the notion of minimizing the number of
incompatible namespaces on the system. Plan9 took this to an
extreme: everything’s a file in Plan9, even more so than UNIX, and so
it’s easy for shell scripts to do things like act as TCP/IP clients just
by manipulating the right magic files. More on this below.

So, why dialects? First, I think they’re much easier to design and
document than object interfaces. They’ve traditionally been much harder
to IMPLEMENT, which is why people don’t go that route unless they

absolutely have to, but that’s where REBOL comes in (as I’ll expand on
in
a bit)… They’re also MUCH easier to debug, as you can just open a port
and start typing in commands and see what’s going on! Think about how
many mail problems have been diagnosed by sysadmins telnetting to port
25.
Why shouldn’t you be able to, say, telnet to a port and type a command
to
open a window, another one to draw a circle in it, etc., and see all the
mouse, keyboard, and other events come back to you as text messages
too?
In fact, like any good RAD environment, I can picture a very clean
design/implement/debug cycle where you add a new command, document it,
and
debug it, all with quick turn-around time compared to designing a class,
implementing all the get/set accessor methods, realizing it still sucks,
etc.

Dialects are much easier to script, as any random scripting language
that
has the ability to open the port (which, in Plan9 was done in the same
way
as opening any other file) can spew stuff to it with print statements,
and
get responses back with read statements. Of course a language like
REBOL
makes these two tasks particularly easy, so it helps on both sides of
the
fence. Finally, dialects are TRIVIAL to extend: unlike binary
protocols
where it’s easy to screw up and not leave yourself room to elegantly add
new capabilities, with a dialect, you simply add a new command word!
You
don’t even have to worry about proprietary extensions screwing up
clients,
because there’s natural namespace protection built into a dialect, you
simply do something like:

X-MyCompany-WeirdCommand: foo

and if the server doesn’t understand, it gives you an error in a
well-established (by the particular dialect) way.

Efficiency seems to be the big reason more stuff hasn’t gone this way,
and
to be fair, I’m certainly not proposing that we throw away shared
libraries! Things like printf() will always be best handled through
that sort of mechanism. However, what exactly would be the impact if
the
computer industry were to embrace dialects and take them to their
logical
conclusion? What if, sitting at your PC, you could connect to any of
100
different ports, each one of which would supply you (as well as the
applications which depend on it) with a set of well-defined services
available through a simple, domain-specific language?

I can think of a few obvious implications. First, security! While it’s
useful to think in terms of “telnetting to a port”, it’s clear that, if
this is the primary way to add functionality to a system that was
previously available through shared libraries, the DEFAULT security
should
be localhost-only, with some secure way of establishing the identity of
the user. Something like UNIX domain sockets would make sense, at least
on UNIX (in fact, 4.4BSD has a rather nice feature in that one app can
send unforgeable credentials to another over a UNIX domain socket).
Clearly it would be trivial to write a telnet-style debugger tool to
connect and log in to one of these sockets, and the fact that they sit
in

the filesystem namespace means that they’d be much easier to find and
avoid collisions than a numeric TCP port. The other nice thing is that
the needed infrastructure is already in the UNIX kernel and is
well-tested, efficient, and reliable.

Of course UNIX domain sockets eliminates the possibility of remote
access
when you do desire that sort of thing, so it’d be nice if this solution
supported TCP as well. The funny thing is that, by communicating in
terms
of ASCII commands, there’s no need for anything like IIOP, and it’s
probably just as efficient, if not potentially even better!

You might argue that this will create a “Tower of Babel” with each
language being completely different from all the others, but I think
that,
by planning for the future and creating a sensible set of “Language
Design
Guidelines” (much like the famous Mac UI Guidelines), you can eliminate
99% of this. Ideally, each language would service no more than 10-20
commands, and all the boilerplate stuff (like returning error codes for
commands not recognized, etc.) would be handled in an identical way for
all of them.

The real issue that’s kept this from happening so far, and this is where
I
think REBOL can come in, is in the difficulty (up until now) of writing
reliable parsers for these domain-specific languages. What if we assume
a
single multithreaded REBOL server to wait on all of these UNIX domain
sockets and TCP ports, parse each of the hundreds of domain specific
languages, and then call down to a mixture of native and REBOL code to
implement the functionality? This presumes a lot of REBOL, and clearly
current versions of REBOL are probably not up to the task, but I think
future versions could easily be, and I’m pretty sure the clever people
at
REBOL are already looking forward to such a day. It’s just that you
have
to read between the lines and really THINK about the nature of software
“components” to make the connection that maybe REBOL has a real
alternative worth pursuing, because clearly CORBA has had its chance,
and
so far has not ushered us into “component heaven”, so what do we have to
lose?

-Jake

END of rebol ml post


\

Paul May, Manchester, UK
Team Phoenix Core

In article 39ecceb3$1@news, “bozo” says…

Hello everyone,

I’m actively looking for a Non-Interactive FTP
client : a ftp client that can read commands from a file instead of using
the command prompt. I don’t want to develop one!!!

I know Micro$oft provides such a client with WinNT, is it available with
QNX. Sure I’m not the first person to think about it!!!

Sure … ftp.qnx.com/usr/free/qnx4/tcpip/ftp/libftp-qnx.tgz :slight_smile:
If not requested for qnx4 … port it to QNX RTP. (You have to ask the unknown
author for a commercial license … )

Armin


Pleas help!!

P.S. I’m ready to pay $$$ for it!

Stef

Sure, we do this all the time with the standard QNX ftp. Check out the
docs by the section about the “.netrc” file. This allows you to
autologin to a remote host. Then you can do things like:

echo “bin\ncd \nput \nquit\n” | ftp

or

echo “bin\ncd \nput \nquit\n” > ftpcommands
ftp < ftpcommands

both of which would be as if you did:

ftp
FTP>bin
FTP>cd
FTP>put
FTP>quit

Of course if you do this in a shell script, you can substitute ,
and by shell command line parameters ($1 $2, etc). You
can even make this more elegant in the shell script by using the “HERE
document” feature. You get the picture…

Good luck,

rick

bozo wrote:

Hello everyone,

I’m actively looking for a Non-Interactive FTP
client : a ftp client that can read commands from a file instead of using
the command prompt. I don’t want to develop one!!!

I know Micro$oft provides such a client with WinNT, is it available with
QNX. Sure I’m not the first person to think about it!!!

Pleas help!!

P.S. I’m ready to pay $$$ for it!

Stef

Try ncftp - that has a bunch of ways to doing batched transfers.

Rick Lake <rwlake@spam.redirected.to.dev.null> wrote:

Sure, we do this all the time with the standard QNX ftp. Check out the
docs by the section about the “.netrc” file. This allows you to
autologin to a remote host. Then you can do things like:

echo “bin\ncd \nput \nquit\n” | ftp <host

or

echo “bin\ncd \nput \nquit\n” > ftpcommands
ftp < ftpcommands

both of which would be as if you did:

ftp bin
FTP>cd put quit

Of course if you do this in a shell script, you can substitute ,
subdir> and by shell command line parameters ($1 $2, etc). You
can even make this more elegant in the shell script by using the “HERE
document” feature. You get the picture…

Good luck,

rick

bozo wrote:

Hello everyone,

I’m actively looking for a Non-Interactive FTP
client : a ftp client that can read commands from a file instead of using
the command prompt. I don’t want to develop one!!!

I know Micro$oft provides such a client with WinNT, is it available with
QNX. Sure I’m not the first person to think about it!!!

Pleas help!!

P.S. I’m ready to pay $$$ for it!

Stef


cburgess@qnx.com

Thanks Rick.

I had a ‘feeling’ about using the .netrc file, but wasn’t sure how to. This
is a NICE alternative to a compiled program. Thanks for the tip. I reminds
of what I did with a snmp shell a few years ago.

The only thing that bothers me is the fact that I have to interact with the
shell and… for our application, that’s no good. But hey, at least, you
gave me a REAL good hint!

Thanks!

Stef



“Rick Lake” <rwlake@SPAM.REDIRECTED.TO.DEV.NULL> wrote in message
news:39ECD1CC.4E9649AF@SPAM.REDIRECTED.TO.DEV.NULL

Sure, we do this all the time with the standard QNX ftp. Check out the
docs by the section about the “.netrc” file. This allows you to
autologin to a remote host. Then you can do things like:

echo “bin\ncd \nput \nquit\n” | ftp <host

or

echo “bin\ncd \nput \nquit\n” > ftpcommands
ftp < ftpcommands

both of which would be as if you did:

ftp bin
FTP>cd put quit

Of course if you do this in a shell script, you can substitute ,
subdir> and by shell command line parameters ($1 $2, etc). You
can even make this more elegant in the shell script by using the “HERE
document” feature. You get the picture…

Good luck,

rick

bozo wrote:

Hello everyone,

I’m actively looking for a Non-Interactive FTP
client : a ftp client that can read commands from a file instead of
using
the command prompt. I don’t want to develop one!!!

I know Micro$oft provides such a client with WinNT, is it available with
QNX. Sure I’m not the first person to think about it!!!

Pleas help!!

P.S. I’m ready to pay $$$ for it!

Stef

Thanks Armin.

I don’t know if you ever looked at this lib before but I can assure you that
it has NEVER been complied! Plenty of un-casted pointers, pointers
returned to automatic variables … stuff like that. Unusable in this state.
Do you have a ‘working’ version that I could use …?

Thanks once again Armin.


Stef


“Armin Steinhoff” <a-steinhoff@web_de> wrote in message
news:8sih2d025ko@drn.newsguy.com

In article 39ecceb3$1@news, “bozo” says…

Hello everyone,

I’m actively looking for a Non-Interactive FTP
client : a ftp client that can read commands from a file instead of using
the command prompt. I don’t want to develop one!!!

I know Micro$oft provides such a client with WinNT, is it available with
QNX. Sure I’m not the first person to think about it!!!

Sure … ftp.qnx.com/usr/free/qnx4/tcpip/ftp/libftp-qnx.tgz > :slight_smile:
If not requested for qnx4 … port it to QNX RTP. (You have to ask the
unknown
author for a commercial license … )

Armin



Pleas help!!

P.S. I’m ready to pay $$$ for it!

Stef

One other possibility is “expect”. On the plus side there are books
about it and it’s more flexible than a shell when dealing with uncommon
(error) situations. Cons are - it’s a different language to learn and
you may have to compile tcl.

I wouldn’t consider using a shell to automate file transfers, whether
by ftp or modem, any more.

Richard

bozo wrote:

Thanks Rick.

I had a ‘feeling’ about using the .netrc file, but wasn’t sure how to. This
is a NICE alternative to a compiled program. Thanks for the tip. I reminds
of what I did with a snmp shell a few years ago.

The only thing that bothers me is the fact that I have to interact with the
shell and… for our application, that’s no good. But hey, at least, you
gave me a REAL good hint!

Thanks!

Stef

“Rick Lake” <> rwlake@SPAM.REDIRECTED.TO.DEV.NULL> > wrote in message
news:> 39ECD1CC.4E9649AF@SPAM.REDIRECTED.TO.DEV.NULL> …
Sure, we do this all the time with the standard QNX ftp. Check out the
docs by the section about the “.netrc” file. This allows you to
autologin to a remote host. Then you can do things like:

echo “bin\ncd \nput \nquit\n” | ftp <host

or

echo “bin\ncd \nput \nquit\n” > ftpcommands
ftp < ftpcommands

both of which would be as if you did:

ftp bin
FTP>cd put quit

Of course if you do this in a shell script, you can substitute ,
subdir> and by shell command line parameters ($1 $2, etc). You
can even make this more elegant in the shell script by using the “HERE
document” feature. You get the picture…

Good luck,

rick

bozo wrote:

Hello everyone,

I’m actively looking for a Non-Interactive FTP
client : a ftp client that can read commands from a file instead of
using
the command prompt. I don’t want to develop one!!!

I know Micro$oft provides such a client with WinNT, is it available with
QNX. Sure I’m not the first person to think about it!!!

Pleas help!!

P.S. I’m ready to pay $$$ for it!

Stef

In article 39edbd5a@news, “bozo” says…

Thanks Armin.

I don’t know if you ever looked at this lib before but I can assure you that
it has NEVER been complied! Plenty of un-casted pointers, pointers
returned to automatic variables … stuff like that. Unusable in this state.

Oh big surprice … I never used it.

Do you have a ‘working’ version that I could use …?

No … but a working alternative could be Python + the script ftplib.py … a
ftp client. You can find it in the Lib directory of the standard
distribution.
( also available at ftp.qnx.com )
Here’s a sample session using the ftplib module:

from ftplib import FTP
ftp = FTP(‘ftp.cwi.nl’) # connect to host, default port
ftp.login() # user anonymous, passwd user@hostname
ftp.retrlines(‘LIST’) # list directory contents
total 24418
drwxrwsr-x 5 ftp-usr pdmaint 1536 Mar 20 09:48 .
dr-xr-srwt 105 ftp-usr pdmaint 1536 Mar 21 14:32 …
-rw-r–r-- 1 ftp-usr pdmaint 5305 Mar 20 09:48 INDEX

ftp.retrbinary(‘RETR README’, open(‘README’, ‘wb’).write)
‘226 Transfer complete.’
ftp.quit()

.Armin

and heres the REBOL version taken from the
http://www.rebol.com/library/script-ftp.html page

REBOL [
Title: “Download List of Files”
File: %ftpdown.r
Date: 26-May-1999
Purpose: {Download a list of binary files using FTP.}
Category: [ftp net file 1]
]

site: ftp://user:pass@ftp.site.com/www/images

files: [icon.gif logo.gif photo.jpg]

foreach file files [
write/binary file read/binary site/:file
]


Paul May, Manchester, UK
Team Phoenix Core

In article 39edbd5a@news, “bozo” says…

Thanks Armin.

I don’t know if you ever looked at this lib before but I can assure you that
it has NEVER been complied! Plenty of un-casted pointers, pointers
returned to automatic variables … stuff like that. Unusable in this state.

Oh big surprice … I never used it.

Do you have a ‘working’ version that I could use …?

No … but a working alternative could be Python + the script ftplib.py … a
ftp client. You can find it in the Lib directory of the standard distribution.
( also available at ftp.qnx.com )
Here’s a sample session using the ftplib module:

from ftplib import FTP
ftp = FTP(‘ftp.cwi.nl’) # connect to host, default port
ftp.login() # user anonymous, passwd user@hostname
ftp.retrlines(‘LIST’) # list directory contents
total 24418

drwxrwsr-x 5 ftp-usr pdmaint 1536 Mar 20 09:48 .
dr-xr-srwt 105 ftp-usr pdmaint 1536 Mar 21 14:32 …
-rw-r–r-- 1 ftp-usr pdmaint 5305 Mar 20 09:48 INDEX

ftp.retrbinary(‘RETR README’, open(‘README’, ‘wb’).write)
‘226 Transfer complete.’
ftp.quit()

.Armin

Here’s the help on ncFTPGet

NcFTPGet 3.0.1

Usages:
ncftpget [flags] remote-host local-dir remote-path-names… (mode 1)
ncftpget -f login.cfg [flags] local-dir remote-path-names… (mode 2)
ncftpget [flags] ftp://url.style.host/path/name (mode 3)

Flags:
-u XX Use username XX instead of anonymous.
-p XX Use password XX with the username.
-P XX Use port number XX instead of the default FTP service port (21).
-d XX Use the file XX for debug logging.
-a Use ASCII transfer type instead of binary.
-t XX Timeout after XX seconds.
-v/-V Do (do not) use progress meters.
-f XX Read the file XX for host, user, and password information.
-A Append to local files, instead of overwriting them.
-z/-Z Do (do not) not try to resume downloads (default: -z).
-E Use regular (PORT) data connections.
-F Use passive (PASV) data connections (default).
-DD Delete remote file after successfully downloading it.
-b Run in background (submit job to “ncftpbatch”).
-B XX Try setting the SO_RCVBUF size to XX.
-r XX Redial XX times until connected.
-R Recursive mode; copy whole directory trees.
-T Do not try to use TAR mode with Recursive mode.

Examples:
ncftpget ftp.wustl.edu . /pub/README /pub/README.too
ncftpget ftp.wustl.edu . ‘/pub/README*’
ncftpget -R ftp.probe.net /tmp /pub/ncftpd (ncftpd is a directory)
ncftpget ftp://ftp.wustl.edu/pub/README
ncftpget -u gleason -p my.password Bozo.probe.net . ‘/home/mjg/.*rc’
ncftpget -u gleason Bozo.probe.net . /home/mjg/foo.txt (prompt for password)
ncftpget -f Bozo.cfg ‘/home/mjg/.rc’
ncftpget -a -d /tmp/debug.log -t 60 ftp.wustl.edu . '/pub/README

Library version: LibNcFTP 3.0.1 (March 27, 2000).

This is a freeware program by Mike Gleason (mgleason@ncftp.com).
This was built using LibNcFTP (http://www.ncftp.com/libncftp).

bozo <bozo@home.net> wrote:

Thanks Rick.

I had a ‘feeling’ about using the .netrc file, but wasn’t sure how to. This
is a NICE alternative to a compiled program. Thanks for the tip. I reminds
of what I did with a snmp shell a few years ago.

The only thing that bothers me is the fact that I have to interact with the
shell and… for our application, that’s no good. But hey, at least, you
gave me a REAL good hint!

Thanks!

Stef



“Rick Lake” <> rwlake@SPAM.REDIRECTED.TO.DEV.NULL> > wrote in message
news:> 39ECD1CC.4E9649AF@SPAM.REDIRECTED.TO.DEV.NULL> …
Sure, we do this all the time with the standard QNX ftp. Check out the
docs by the section about the “.netrc” file. This allows you to
autologin to a remote host. Then you can do things like:

echo “bin\ncd \nput \nquit\n” | ftp <host

or

echo “bin\ncd \nput \nquit\n” > ftpcommands
ftp < ftpcommands

both of which would be as if you did:

ftp bin
FTP>cd put quit

Of course if you do this in a shell script, you can substitute ,
subdir> and by shell command line parameters ($1 $2, etc). You
can even make this more elegant in the shell script by using the “HERE
document” feature. You get the picture…

Good luck,

rick

bozo wrote:

Hello everyone,

I’m actively looking for a Non-Interactive FTP
client : a ftp client that can read commands from a file instead of
using
the command prompt. I don’t want to develop one!!!

I know Micro$oft provides such a client with WinNT, is it available with
QNX. Sure I’m not the first person to think about it!!!

Pleas help!!

P.S. I’m ready to pay $$$ for it!

Stef


cburgess@qnx.com