george@wciu.wciu.edu (George Peavy) (03/05/91)
I'm just learning UUCP, and am trying to get working on my system. I'm running Sys V r 3.0 on an Unisys 6000/51 platform. Here's the problem: I have things working enough that I can call out manually using cu, but when I attach to a remote system, the expect/send set up in my Systems file are being ignored (I have checked this using cu -d). Thus, my attempts to get uucico to work so far have been in vain. Is there something I'm missing? Some reference I've missed? RTFM? Email and/or posting would be appreciated. Thanks in advance. -- George Peavy (george@wciu.edu)
les@chinet.chi.il.us (Leslie Mikesell) (03/06/91)
In article <1991Mar4.213742.17329@wciu.EDU> george@wciu.wciu.edu (George Peavy) writes: >Here's the problem: I have things working enough that I can call out manually >using cu, but when I attach to a remote system, the expect/send set up in my >Systems file are being ignored (I have checked this using cu -d). Thus, my >attempts to get uucico to work so far have been in vain. Cu doesn't attempt to execute the login script in the Systems file. If you want to debug this script, try using: /usr/lib/uucp/Uutry -r remote_name which is a shell script that runs uucico with debugging on and the output redirected to a file. You are then put into a "tail -f" of the file so you can watch what happens. Note that (a) you need read permission on the Systems file or you won't see the real strings, (b) you have to interrupt out of the tail -f, and (c) when you interrupt out, the uucico is still running, so you either have to wait until it fails to try the same system again or use ps to find its process id and kill it. Les Mikesell les@chinet.chi.il.us
terry@jgaltstl.UUCP (terry linhardt) (03/06/91)
In article <1991Mar4.213742.17329@wciu.EDU>, george@wciu.wciu.edu (George Peavy) writes: > Here's the problem: I have things working enough that I can call out manually > using cu, but when I attach to a remote system, the expect/send set up in my > Systems file are being ignored (I have checked this using cu -d). Thus, my > attempts to get uucico to work so far have been in vain. 'cu' doesn't use the Systems file! The only file you must configure to get cu to work is Devices. (I am assuming that Dialers is okay). So, when you use 'cu' with the debug option, it is displaying the expect/send sequence from Dialers, NOT Systems. If you want to test a uucico link, you want to run it with the 'x' option, e.g. uucico -r1 -x9 -sRemote_system where the number with the x sets the debug level (amount of detail reported). The most detail is reported with the x9 option. You are on the right track in trying to use a debug option to get uucico to work. I don't think I would try to get a link working without using the debut option. It's just that you need the debug mode of uucico (the -x#), rather that the debug mode of cu. Remember, when using the debugging option, is that the failure occurs where you have a problem. Fix the problem, and do it again, until you finally get it to work. Also, remember that a option such as -x9 displays a *lot* of information which you may not understand. But that's okay. You are basically looking to see where the various expect/send sequences fail, and you should be able to figure that out from the output. Good luck. -- |---------------------------------------------------------------------| | Terry Linhardt The Lafayette Group uunet!jgaltstl!terry | |---------------------------------------------------------------------|
jpr@jpradley.jpr.com (Jean-Pierre Radley) (03/08/91)
In article <1991Mar05.173537.14831@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >In article <1991Mar4.213742.17329@wciu.EDU> george@wciu.wciu.edu (George Peavy) writes: > >>Here's the problem: I have things working enough that I can call out manually >>using cu, but when I attach to a remote system, the expect/send set up in my >>Systems file are being ignored (I have checked this using cu -d). Thus, my >>attempts to get uucico to work so far have been in vain. > >Cu doesn't attempt to execute the login script in the Systems file. Les, not necessarily. In quite a few HDB implementations, "cu systemname" is quite valid, and there's even a mechanism for having individual sets of Systems Dialers, and Devices files: a set for uucp to use, another for cu, and yet another for ct. Jean-Pierre Radley NYC Public Unix jpr@jpradley.jpr.com CIS: 72160,1341
les@chinet.chi.il.us (Leslie Mikesell) (03/10/91)
In article <1991Mar08.054130.12990@jpradley.jpr.com> jpr@jpradley.jpr.com (Jean-Pierre Radley) writes: >>Cu doesn't attempt to execute the login script in the Systems file. >Les, not necessarily. In quite a few HDB implementations, "cu systemname" is >quite valid, and there's even a mechanism for having individual sets of Systems >Dialers, and Devices files: a set for uucp to use, another for cu, and yet >another for ct. True enough, but cu still doesn't attempt to execute the login script found in the Systems file. Otherwise you would end up logged in as "nuucp" or something equally useless for interactive work. Cu just uses the device and phone number fields to set up the connection. The original question regarded debugging the uucico login script which is ignored by cu. Les Mikesell les@chinet.chi.il.us
jpr@jpradley.jpr.com (Jean-Pierre Radley) (03/11/91)
In article <1991Mar09.213352.3942@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >In article <1991Mar08.054130.12990@jpradley.jpr.com> jpr@jpradley.jpr.com (Jean-Pierre Radley) writes: > >>>Cu doesn't attempt to execute the login script in the Systems file. > >>Les, not necessarily. In quite a few HDB implementations, "cu systemname" is >>quite valid, and there's even a mechanism for having individual sets of Systems >>Dialers, and Devices files: a set for uucp to use, another for cu, and yet >>another for ct. > >True enough, but cu still doesn't attempt to execute the login script >found in the Systems file. Otherwise you would end up logged in as >"nuucp" or something equally useless for interactive work. Cu just >uses the device and phone number fields to set up the connection. The >original question regarded debugging the uucico login script which is >ignored by cu. Reread what I wrote. One can set up two entirely Systems files, e.g. Systems.cico and Systems.uucp. Thus, a chat script be run by uucico would differ from a chat script to be run by cu. Do you have a Sysfiles.eg in your /usr/lib/uucp? Jean-Pierre Radley NYC Public Unix jpr@jpradley.jpr.com CIS: 72160,1341
les@chinet.chi.il.us (Leslie Mikesell) (03/12/91)
In article <1991Mar10.193008.3732@jpradley.jpr.com> jpr@jpradley.jpr.com (Jean-Pierre Radley) writes: [re: cu chatting] >Reread what I wrote. One can set up two entirely Systems files, e.g. >Systems.cico and Systems.uucp. Thus, a chat script be run by uucico would >differ from a chat script to be run by cu. >Do you have a Sysfiles.eg in your /usr/lib/uucp? Yes, I have Sysfiles, and I have run cu and uucico both with the same and different Systems files in different circumstances. In no case has cu ever executed the login script found in its Systems file even if Sysfiles specified that it was for cu's use only. I'm running AT&T SysVr3 (and previous releases did the same). Perhaps other versions are different. I would like to have that functionality and have occasionally faked it with the "modem-class" specification in the Systems file selecting a Device entry which selects a Dialer script which performs the login chat as well. This works but it is somewhat contorted in that you have to repeat the Device entry for every device capable of making the connection and this becomes difficult if these devices might need different scripts for the dialing portion. I would prefer for it to work as you say, even though you would be forced to use different Systems files for cu and uucico to make cu systemname useful. Les Mikesell les@chinet.chi.il.us