The professional tool to automate FTP, SFTP, FTPS

and schedule FTP batch jobs

Post a message here if you find anything wrong in ScriptFTP.
Hi all,

I'm trying to design a script whose purpose is to check for any TIF-files in the working folder, if exists transfer them to the FTP-server, and delete them once uploaded. For added safety and stupid-enduser-support-call-prevention I wanted the script to do an additional check for TIF-files at the end, and if they exist re-run the script one more time. I thought this would be a breeze, but I stumbled upon some problems, here's the script
Code: Select all############### SCRIPT START ################# ##################### # Variables $user="username" $password="password" $ftpserver="ftpserver" ##################### SILENT(ON) $scriptruns=0 :start LOCALCHDIR("C:\workingfolder") $result=GETLIST($list,LOCAL_FILES,"*.tif*") IF($result!="OK")  PRINT("")  PRINT("ERROR: CANNOT FIND ANY TIF FILES TO SEND")  PRINT("")  STOP END IF $attempts=0 :connect $resultvalue=OPENHOST($ftpserver,$user,$password) IF($resultvalue=="OK")  FOREACH $item IN $list $result=PUTFILE($item) IF($result=="OK")  EXEC("del ".$item) END IF  END FOREACH ELSE  IF($attempts==2) PRINT("") PRINT("ERROR: CANNOT CONNECT TO FTP SERVER") PRINT("") STOP  ELSE PRINT("Connection failed, trying to reconnect...") SLEEP(5) $attempts=$attempts+1 GOTO :connect  END IF END IF CLOSEHOST $result2=GETLIST($list2,LOCAL_FILES,"*.tif*") IF($result2!="OK")  GOTO :end END IF IF($scriptruns==1)  PRINT("")  PRINT("ERROR: FAILED TO TRANSFER ALL FILES")  PRINT("")  STOP ELSE  PRINT("")  PRINT("ERROR: TIF files still exists in folder, trying to run script again...")  PRINT("")  $scriptruns=$scriptruns+1  GOTO :start END IF :end EXIT ############### SCRIPT END #################
What I dont understand is that the variable '$result2' gets the value "OK", even if no files exists. If I run the script with no TIF-files present, it stops saying no files to send - as expected - which means '$result' returned nothing. But the last check, which should behave exactly the same way (right?), returns "OK" even though no files are present...

Any help is greatly appreciated!

If I run the script with no TIF-files present, it stops saying no files to send - as expected - which means '$result' returned nothing.
If no files are found $result shoud be "OK" but the list should be empty. Could you put this line after each GETLIST?
Code: Select allPRINT("Result was: ".$result) PRINT("Elements in list: ".COUNTELEMENTS($list))
(change $result to $result2 and $list to $list2 in the second call)

If you find a syntax error install ScriptFTP using this file:

Post the output here please.

No need to post output, I already tested this (to print the variables after each stage of the script), and here's what I got:

- if I run the script with no files present, it stops the script and prints the error-message ("cannot find any tif..."). The variable $result at this stage is blank/empty.

- if I run the script with some TIF-files present, it processes the files as supposed to (uploads and deletes), and then when it reaches my extra file-check at the end, it jumps back to :start. The variable "$result2" has the value "OK", which matches what you say it should be. But if it were to behave like the first file-check, it should be empty and then goto :end which is what I want it to do.

However if what you say is true (disregarding the bug/problem I have stumbled upon), then the result of the GETLIST should be "OK" regardless of files existing or not? If so my script is flawed obviously... but looking at your suggestion I'm thinking I might be able to use the "COUNTELEMENTS" instead to see if the number of files are greater than zero?

It might be overkill to use the GETLIST command, since you are expecting that all the TIF files are gone by then. Basically if one exists than something went wrong.

Maybe you could try this code snippet instead:

Code: Select all$TEST_EXIST=EXEC("dir C:\folder\*.tif") # If no file matches the dir statement the returned value # will be 1, otherwise 0 IF ($TEST_EXIST="1") GOTO :end END IF  
Hey forest,

Yeah, there are probably better ways to solve this, I'm just getting to know ScriptFTP so I didn't think of any better way atm. Your suggestion sounds good as well. I'll give it a try when I get the chance, thx!

I still would like to pursue this matter though, in case its a bug so we can get rid of it :)

Hello Sussidal,

You are right. It is a ScriptFTP bug. I've just fixed it and now GETLIST should return "OK" instead of nothing when no file is found (Not finding any files is not an error condition). Download and install ScriptFTP from here:

Please, post here again if you find anything else.

This topic has been moved to the Bug reports forum.
Hi there,

The problem with you "fixing" the script is of course that I have to re-design it as it was more or less based on that bug ;)

Anyways, that comes later tonight. I have discovered something else: when filenames have comma in them, the script (still the same as above) gets in trouble. And before I'm shot dead: yes I know its stupid to have comma in filenames, but it just happens that one of our customers did. And after the script had run, 1 of 2 files (both with moronic filenames, but only 1 of them with a comma) was left in the folder when it was finished. A quick debug shows that even though the script uploads both files, the delete-routine sees the comma as a separator... you can figure the rest out yourselves :)

Now I just wanna make it clear that this isn't a big deal for me, I'm perfectly happy with telling customers that comma in filenames is baaaaad. But I found it peculiar that ScriptFTP is able to upload the file, but not delete it - seems like it doesn't interpret the names equally during the two routines... so I'd thought I mention it here in case its something you want to investigate further ;)


[edit] this happens when there's a space in the filename as well... should I format the code differently? Or encapsulate the variables differently perhaps?
Hi there,
yes I know its stupid to have comma in filenames, but it just happens that one of our customers did.
It is a bit rare but no so stupid. I know a guy that plugged an USB drive in a 9 pin serial port and asked me why it wasn't working... he bended all the pins. :D

Try replacing this chunk in the script
Code: Select all IF($result=="OK")  EXEC("del ".$item) END IF  
with the following:
Code: Select all IF($result=="OK")  EXEC('del "'.$item.'"') END IF  
As you can see, SciptFTP also accepts single quotes to delimit text strings. Then you can use the double quote as a character within the text string, just as any other character, which is what you needed to avoid that error. This way the windows cmd.exe (the thing that runs the commands that go inside EXEC) can know that it's only one file, not files separated by spaces or commas.

Please, let me know if it finally worked or not.
I figured single quotes might just be the trick here... thanks for clarifying, I'll test it later today and respond.

I have rewritten the script a bit to better suit the bug not being there anymore :) I now check for file presence with the EXEC first, and if successful proceed with GETLIST etc., then do a new check with EXEC at the end to verify all files are successfully processed (if not: run once more, then stop if still fails). Thanks to Forest for the suggestion btw.

Short question: are there any commands for quitting ScriptFTP? scenario-description: our customers get a shortcut to the script on their desktop (to the .ftp file), when they execute it, it remains "open" as an application even if everything went ok. I haven't decided yet, but I think perhaps I'd like the script to close the ScriptFTP application as well if it finishes with no errors, but I couldn't find a way/command. Does it exist? No biggie if it doesn't...

That's what I thought, but nothing happened... maybe I messed up somewhere, I'll go over my config and test again!
Ok, feedback time: your suggestion with single quotes worked, both files with commas and spaces was uploaded and deleted without a hitch, thanks!

And as far as my test of EXIT goes... I had a STOP before the EXIT in that section... in other words: a big noobish code 60 there :oops:

Thanks for all your help!