hitchen@csuvax1.csu.murdoch.edu.au (Greg Hitchen) (02/13/91)
I am using a 386sx AT (msdos) and kermit to logon to a microvax III (4.3bsd). From the vax I am connecting via FTP to wuarchive.wustl.edu (128.252.135.4) and retrieving the file pk361.exe (self unpacking archive) onto the vax. From there I am using kermit to transfer pk361.exe to the PC. When I then type "pk361" ........... nothing happens! (and I then have to reboot the PC). Now my question is - should what I have done work? If not why? Is the problem in the FTP retrieve to the vax or the kermit transfer to the PC? Any thoughts and/or suggestions would be greatfully recieved. Greg -- Greg Hitchen, School of MPS | Internet: hitchen@csuvax1.murdoch.edu.au Murdoch University | Phone: +61 9 332 2102 (W) Murdoch WA 6150 | +61 9 354 1191 (H) Australia. | Fax: +61 9 310 1711
suhonen@kunto.jyu.fi (Timo Suhonen) (02/13/91)
hitchen@csuvax1.csu.murdoch.edu.au (Greg Hitchen) writes:
Now my question is - should what I have done work? If not why? Is the
problem in the FTP retrieve to the vax or the kermit transfer to the PC?
Any thoughts and/or suggestions would be greatfully recieved.
While FTPing be sure you are using binary mode... and also while kermit
transfering...
--
Timo Suhonen I am logged in, therefore I am suhonen@nic.funet.fi
suhonen@kunto.jyu.fi
Opinions(?) are mine (if not stolen), NOT those of Univ. of Jyvaskyla.P.C.Steele@newcastle.ac.uk (P.C. Steele) (02/13/91)
hitchen@csuvax1.csu.murdoch.edu.au (Greg Hitchen) writes: >I am using a 386sx AT (msdos) and kermit to logon to a microvax III (4.3bsd). >From the vax I am connecting via FTP to wuarchive.wustl.edu (128.252.135.4) >and retrieving the file pk361.exe (self unpacking archive) onto the vax. >From there I am using kermit to transfer pk361.exe to the PC. >When I then type "pk361" ........... nothing happens! (and I then have to >reboot the PC). >Now my question is - should what I have done work? If not why? Is the problem >in the FTP retrieve to the vax or the kermit transfer to the PC? >Any thoughts and/or suggestions would be greatfully recieved. It's only a little thing but when you connect to wuarchive.wustl.edu you are remembering to type 'tenex' or 'type binary' this forces a binary transfer otherwise all tansfers will be made as though the files were text files. Phillip Steele 2nd Year Micros Newcastle Uni.
dhf@linus.mitre.org (David H. Friedman) (02/13/91)
I was doing essentially the same thing, ftp'ing files from wustl and kermit'ing to a PC for copy to a diskette. In my case, .ZIP files wouldn't unZIP properly on the PC. I finally compared hex dumps on the PC and on my UNIX box, and found that the Kermit-to-Kermit transfer was introducing extra characters - it looked like every 0Ah was being changed to 0Dh 0Ah, i.e., every CR was being changed to LF-CR even though the transfer mode was supposedly BINARY! I couldn't find which Kermit parameter, if any, enabled or disabled this translation. (I was using MS-Kermit 2.31 on the PC.) The fix I had to use is to UUENCODE the files on the UNIX box, Kermit them to the PC, and UUDECODE them back to binary. If you need UUDECODE for the PC, it's in the starter kit that's periodically posted to comp.binaries.ibm.pc. dhf@linus.mitre.org
sjo@cci632.UUCP (Steve Owens) (02/14/91)
In article <1991Feb13.152910.16132@linus.mitre.org>, dhf@linus.mitre.org (David H. Friedman) writes: > > I was doing essentially the same thing, ftp'ing files from wustl and > kermit'ing to a PC for copy to a diskette. In my case, .ZIP files wouldn't > unZIP properly on the PC. I finally compared hex dumps on the PC and on my > UNIX box, and found that the Kermit-to-Kermit transfer was introducing extra > characters - it looked like every 0Ah was being changed to 0Dh 0Ah, i.e., > every CR was being changed to LF-CR even though the transfer mode was > supposedly BINARY! I couldn't find which Kermit parameter, if any, enabled > or disabled this translation. (I was using MS-Kermit 2.31 on the PC.) The On the Unix box where I work, there is a parameter called "file mode," or something like that, that is set for either "converted" or "literal". I thought this was the CR-LF to CR conversion parameter, but I've never tried it. > fix I had to use is to UUENCODE the files on the UNIX box, Kermit them to > the PC, and UUDECODE them back to binary. If you need UUDECODE for the PC, > it's in the starter kit that's periodically posted to comp.binaries.ibm.pc. This, to me, would be the preferred way of doing it, because you don't have to worry about conversions or file types (except for transfering the uudecode bootstrap program, but even that's typically not a problem.) If you don't have the uudecode from the starter kit, get it. It will save you a lot of hassles in the long run. > dhf@linus.mitre.org sjo@op632.cci.com
dfs@doe.carleton.ca (David F. Skoll) (02/14/91)
In <1991Feb13.152910.16132@linus.mitre.org> dhf@linus.mitre.org (David H. Friedman) writes: >I finally compared hex dumps on the PC and on my >UNIX box, and found that the Kermit-to-Kermit transfer was introducing extra >characters - it looked like every 0Ah was being changed to 0Dh 0Ah, i.e., >every CR was being changed to LF-CR even though the transfer mode was >supposedly BINARY! You probably did this but... You have to 'set file type binary' on the Un*x kermit (the sender.) Changing this parameter on the PC version (receiver) has no effect. -- David F. Skoll
gottlieb@umbc5.umbc.edu (Mr. Robert Gottlieb; CMSC (UGRAD)) (02/15/91)
Another possibility could be when you do the download with kermit. You need to use the -i option for binary, so to send pk361 to your PC, you would need to type: kermit -i -s pk361.exe This along with ftping using binary as well should do the trick. Hope this helps. /* Robert Allen Gottlieb Internet: gottlieb@umbc5.umbc.edu */ /* Bitnet: gottlieb@umbc2.umbc.edu */ /* "It is better to be pissed off than pissed on." */ /* These opinions herein are not that of UMBC, but that of Jr, my cat, */ /* and me. */
nowhere@bsu-cs.bsu.edu (Chael Hall) (02/15/91)
Once you've gotten the files, either you must force an 8-bit transfer
from VAX to MS-DOS or you have to UUENCODE or otherwise convert your 8-bit
files to 7-bit files so that you can tne UUDECODE them back to 8-bit. This
should work correctly, otherwise, you get problems such as you have
experienced already.
I have the same problems with our UNIX 7-bit kermit and VMS 7-bit kermit.
I just use UUENCODE on both.
<hael
--
Chael Hall, Pascal programmer, SYSOP | Call NoWhere BBS
bsu-cs!bsu!edu!nowhere | (317) 285-7346
bsu-cs!nowhere | 12:00am - 4:00 pm
iuvax!bsu-ucs!bsu-cs!00cchall | "I hate it when that happens!"dtb@adpplz.UUCP (Tom Beach) (02/15/91)
In article <1991Feb13.152910.16132@linus.mitre.org>, dhf@linus.mitre.org (David H. Friedman) writes: > > I was doing essentially the same thing, ftp'ing files from wustl and > kermit'ing to a PC for copy to a diskette. In my case, .ZIP files wouldn't > unZIP properly on the PC. I finally compared hex dumps on the PC and on my > UNIX box, and found that the Kermit-to-Kermit transfer was introducing extra > characters - it looked like every 0Ah was being changed to 0Dh 0Ah, i.e., > every CR was being changed to LF-CR even though the transfer mode was > supposedly BINARY! I couldn't find which Kermit parameter, if any, enabled ... stuff deleted My PC is connected to our local UNIX server over PC/NFS ethernet link. This setup allows me to access files on the UNIX system either by doing a remote login to the workstation or accessing directly through NFS from the PC. I have found that when I UUDECODE the files with the PC they will not unzoo because of extraneous LFs evidently either appended by my UUDECODE or DOS itself. If I run UUDECODE from UNIX, switch back to the PC to run looz212 it works as expected. The point is it may not be kermit that's introducing the extraneous linefeeds. Tom: dtb@adpplz.uucp
mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) (02/15/91)
The requirement to SET FILE TYPE BINARY on the Unix server is correct; however the assertion that it is unnecessary to SET FILE TYPE BINARY on your MS-DOS system is dependent upon the version of MS-Kermit you're running. Merton
steveh@athertn.Atherton.COM (Steve Harding) (02/16/91)
In article <460@adphdw20.UUCP> dtb@adpplz.UUCP (Tom Beach) writes: >In article <1991Feb13.152910.16132@linus.mitre.org>, dhf@linus.mitre.org (David H. Friedman) writes: >> >> I was doing essentially the same thing, ftp'ing files from wustl and >> kermit'ing to a PC for copy to a diskette. In my case, .ZIP files wouldn't >> unZIP properly on the PC. I finally compared hex dumps on the PC and on my >> UNIX box, and found that the Kermit-to-Kermit transfer was introducing extra >> characters - it looked like every 0Ah was being changed to 0Dh 0Ah, i.e., >> every CR was being changed to LF-CR even though the transfer mode was >> supposedly BINARY! I couldn't find which Kermit parameter, if any, enabled >... stuff deleted > >My PC is connected to our local UNIX server over PC/NFS ethernet link. >This setup allows me to access files on the UNIX system either by doing >a remote login to the workstation or accessing directly through NFS >from the PC. I have found that when I UUDECODE the files with the PC >they will not unzoo because of extraneous LFs evidently either appended >by my UUDECODE or DOS itself. If I run UUDECODE from UNIX, switch back >to the PC to run looz212 it works as expected. The point is it may >not be kermit that's introducing the extraneous linefeeds. > >Tom: dtb@adpplz.uucp As I recall (not having used PC/NFS for sometime) there is a couple of utilities included ... UNIX2DOS and DOS2UNIX that converts the CR/LFs from one system to the other. Unfortunately, these are not standalone. The PC/NFS server must be running. Based on the above, it would appear that there IS a difference twixt UNIX and DOS files and how the CRs are handled. As a test, upload a text file from your DOS box to UNIX, then view the file on the UNIX side; you will see a ^M appended to the end of each line. SRH