[Gambas-user] Can Gambas write directly from a String variable to a remote file via FTP?

[T Lee Davidson]

On 02/14/2018 01:18 PM, Phan Damily via User wrote:
> I've been teaching myself FTPCLIENT.
> 
> What I'm trying to do is to modify a file on a remote server "on the fly", as quickly as possible, using FTP. I'm able to read
> the remote file into a String variable in Gambas using FTP.Then, I modify the String variable in whatever way needed using
> Gambas string functions. Once that's done, what I'm trying to do is write the data from that String variable to the remote file
> via FTP, overwriting all its contents with the modified data from the String variable.
> 
> From the code examples I'm finding in searches (most are 10 years old, or older), the only way it seems possible to do this is
> to first write the data from the String variable to a local file first. And then send that local file to the remote server via
> FTP, overwriting the original file, using FTPCLIENT's Put method.
> 
> I can do that. But it seems like unnecessary overhead and unnecessary extra steps, if the modification can be done directly from
> the String variable.
> 
> Is there a newer method in Gambas 3.10.0 that wasn't available 10 years ago that allows this to be done? Or is it a limitation
> of the FTP protocol? Is there a way to trick Gambas into thinking a String variable is a file? Is there some other protocol
> Gambas supports that would be more suited to directly modifying remote files without the overhead of using temp files?
> 
> Thanks for reading.

The FtpClient methods are listed at: http://gambaswiki.org/wiki/comp/gb.net.curl/ftpclient

There is no method to store a string as a file. There is, however, the Exec method which would allow you to execute the FTP
'STOR' command. See: https://en.wikipedia.org/wiki/List_of_FTP_commands

Doing that sounds like extra steps as well.

I think the quickest way to implement a solution is to simply use temp files. Unless you have huge files and/or hundreds of
them, the overhead should not be significant.


-- 
Lee