Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am trying to determine the reason for some FTP servers requiring a blank line in the script as follows:

open server.com
username

ftp_commands
bye

Refer to blank line required after username credentials.

Example from: FTP from batch file

another reference to the same: http://newsgroups.derkeiler.com/Archive/Comp/comp.sys.ibm.as400.misc/2008-05/msg00227.html

Also discussed here:

archive.midrange.com/midrange-l/200601/msg00048.html "The behavior I'm observing is the same as if I didn't specify the password to login." with an answer referring to our same fix... archive.midrange.com/midrange-l/200601/msg00053.html and archive.midrange.com/midrange-l/200601/msg00065.html

Note: It is my experience that FTP questions attract uncouth responses. Admittedly FTP is outdated, but many clients still have legacy systems, which they cannot upgrade or replace. The reason thereof should not be discussed here. The intention of this question is to invite a positive response. Please do not respond if you disagree with the above. If you have never encountered this same issue, please do not respond.

I suspect this may be limited to FTP scripts executed from Windows machines, but have been told that this happens often and with many different servers.

My specific interest is to understand what may cause this as I have a real world example of a production system suddenly requiring this as a workaround fix, after running for many years without issue. The server belongs to a third party who claims no change on their end. Server details unknown and cannot be determined.

Any help or encouragement from someone who has come across the same, would be appreciated.

ps. Sorry for the many words and references to painful responses, but I have asked similar questions on serverfault and elsewhere and unfortunately got back kneejerk responses to FTP and respondents debating the validity of the question. I would truly not ask, or re-post this question online if I had a better understanding of the issue. I know of people who have seen this issue, but don't know what causes it.

I am wary that this question would again turn into another irrelevant discussion. Please, I ask very nicely: Please do not respond if you have not encountered a similar issue.

FURTHER EDIT: Please do not suggest changing the product. The problem is not the blank line requirement. We know this fixes the issue. The problem is not being able to explain the reason for the blank line in the first place. Slight difference, but a critical point to note wrt the answering of this question.

share|improve this question
2  
You really need to get connected to the server, confirm that nothing has changed, get logs of the session working and not and work out from there. –  Iain Oct 1 '11 at 14:17
    
Thank you Iain. The purpose of this question is really to elicit responses from those whom have encountered a similar issue. But thank you for adding your response. It would really be cinch to solve if I had access to this 3rd party server, but alas, I had to put the question "out there", since I am not in a position to troubleshoot this to discover the reason for myself. –  Ones and Zeroes Oct 3 '11 at 7:26
    
I was able to get a sample log from a server with the same affliction. USER ***: Login successful. "FEAT" - - "PWD" 257 - "TYPE A" 200 - "PASV" 227 - "LIST" 226 770 "NOOP" 200 - "NOOP" 200 - "QUIT" 221 - Unfortunately it does not tell me much. Hope it helps someone - perhaps if the log looks the same, but I don't have previous logs to compare with. –  Ones and Zeroes Oct 5 '11 at 15:05
add comment

5 Answers

This comes out of the dim recesses of my memory, as I haven't had to script command line FTP in this way since, oh, the 90's...

In an FTP protocol session, after sending the username to the FTP server, the server may then ask for a password, even if the username indicates that anonymous FTP should be used (i.e. the username sent is ftp or anonymous). In this case, the server requests the password but ignores it. So in a script that drives the command line FTP client, a blank line would be used to send an empty password. If the server doesn't ask for a password, the blank line does nothing and is harmless.

share|improve this answer
add comment

Do you have to use the out-of-the-box-os ftp client?

If not, you may want to look at the NcFTP Client product(s). I just recently automated an ftp download process and the thought of having to automate the generic ftp client was not pleasing.

NcFTP Client has a tool called ncftpbatch that allows for the automation of ftp processes without having to do all the manual work that automating the generic ftp would.

http://www.ncftp.com/ncftp/doc/ncftpbatch.html

Edit: Missed the part about suggesting a different product. Nevermind my post.

share|improve this answer
add comment

I also faced the similar issue. I felt that few of my ftp commands in a FTP script are being skipped. But after some time I found that my script was running with "interactive mode" as "On".. I turned it Off in the scritp after connecting to an FTP server and it appear to did the magic... If you are still experiencing this issue, try it.

PS: by turning off the interactive mode, i didnt need to give blank lines too

share|improve this answer
add comment

Adding a blank line in a script appears to be an acceptable solution to line-skipping in FTP scripts. Unfortunately there aren't many references on forums and the like, to this problem being resolved. Neither is it likely that the cause will be identified without the assistance of FTP protocol experts who can actively debug an offending session. I would have preferred that this question be answered with real world references to similar occurrences and identification of the cause, but have to accept that this would likely not happen. Also considering the typical responses to asking such a question on open forums, I'd go as far as to say that committed participation in finding an answer to this issue will not occur without a considerable commercial effort.

This question is therefore being answered as follows: Cause to FTP script line-skipping cannot be identified, however it can easily be solved by adding in a blank line to a script where line-skipping is found.

share|improve this answer
add comment

What line endings does your script use? Try using the alternate form (if they are Windows, use Unix, Unix if they are Windows).

What FTP client are you using? Consider using NCFTP instead: http://www.ncftp.com/ncftp/ . It has much better scripting support then most clients built into operating systems.

share|improve this answer
1  
@ones - this could be very useful, as CR and LF behave differently and could explain your issue very simply. –  Rory Alsop Oct 5 '11 at 15:52
    
This particular issue deals with a connection to 3rd party server where neither the source nor the destination changed. Considering line endings, in such a case could be irrelevant, as it generally only plays a role during discovery of nuances that present themselves when initiating new connections. I may however be wrong, if proof exists that the network may affect CR and LF. For instance, one might suspect a firewall software upgrade as being the cause of the issue - but applying CR and LF issues to such a postulation - how would it fit? –  Ones and Zeroes Oct 7 '11 at 21:19
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.