You can also write the client fairly quickly if you know Perl using Net::FTP. Here’s an (incomplete) snippet from a Perl subroutine I wrote to handle ftp upload. man Net::FTP gives you all the other supported commands.
Well it doesn’t make sense to write a ftp client that has a single command for every possible permutation of commands someone like you might want to do. You would end up with thousands of commands like downloadanddelete, uploadandchangepermission, getburgerandpotatochips and so on. So a scriptable client is the logical solution. And really it isn’t too difficult to write a script for ncftp. It’s just the sequence of commands you would do manually.
Yes, you are right it would be nuts to write hundreds of commands, however, I’m really only needing 5 of those big command lines. If I can get the syntax for the one mentionned above I’m sure I can figure out the rest (I hope).
For my purposes, it would be more efficient to run the command as it is directly in the terminal window. However, if the basic FTP can not handle this, then I’ll have no choice to take this detour.
As there is a rather direct relation between the commands one types (or simulates the typing by a script or a “here document”) and the conversation on the FTP connection, combining those commands into one line is not very sensible.
I have done this using a ksh script (but bash will run this also). A snippet:
As you see I write the FTP commands needed to a (temporary) file and then call ftp with input redirection. Of course interactive action to what comes back is a bit difficult, but the script I use provides for doing first an FTP session with a* dir* command to get the contents of a directory (the one you see above), using the output for creating a new FTP session to get the files I want.
The same script can also use SFTP (via SSH), but then it is different again. I even remember that I had to check for the SSH version at the other side to get the conversation correct. After all these protocols are designed for interactive usage.
> Thanks for the information… So then basic FTP can not achieve this in
> a single large command line? I have to use scriptable FTP clients?
“basic FTP” is an interactive experience…
that is, with
you contact the FTP daemon (ftpd) at somesite and it answers with a
password prompt…but, you can make that automatic
ftp somesite.com yourID:yourPassword
and it will answer with a prompt…but, from there it is pretty much
you send it answers, over and over…that is where the script ken_yap
you might take a look at wget which is kinda a step between ftp and
ncftp…i’ve not looked to see, but maybe most of the things you
seek can be done with a single wget command…
see: man wget
HEY, if the distant machine is rsync capable maybe that is what you
are REALLY looking for, which i’m pretty sure can do all you want with
The best matching solution so far seems to be the use of wget (thank you palladium). Although I still have lots to read on it… It does have the option to delete all files after deleting them, which is one process I needed.
Scripting is a good idea, however for my purposes it’s the more complex option (I think). As I need to take into account configurable options of users, like the host, username and password…
Unless I can make a script that could call external parameters from the command line… But then isn’t that like re-creating the wheel?
Run_FTP_Script_1 -user username -pass password -host abc.com
As ken_yap says, the scripting using parameters is exactly where scripting is made for (and programming in general). To do the same thing with different values. Those values come either from the fields in the command or from e.g. a configuration file. My example above has them from a confifuration file because the scripts does the ftp from more then a hundred systems and thus loops having each time a different value in REMSYS.
About the deleting of what you transferred (if I understand you correct). This script of mine does it a bit different. It changes the name of the file from e.g. file-to-be-transferred to file-to-be-transferred.transferred. Then even if you have a problem losing the file on the accepting system after the transfer, it is still there on the sending system. After second transfer of a new file with the same name the name changing will overwrite the old transferred one, thus I have always two versions of the file for backup reasons. Even if the file is different evrey time, a way of having a backup for some time must be possible. Imagination is all you need.