frechett@boulder.Colorado.EDU (-=Runaway Daemon=-) (12/23/90)
I posted this question once and I have had no replies whatsoever. Since our news server was just moved and has been really screwed up lately, I decided to post again in case it never made it out the first time. ------------------------------------------------------------------ This should be simple one way or the other. I recently saw the FAQ list and pondered it until I saw a mention of expect. Here was one I had never heard of. I promptly compiled tcl and expect, and put them in a personal account. My problem is that I am having problems with what I believe is the magic number. ie. #!<expect_path> in expect scripts. The first time that I compiled it all, it lived as /tmp/.../expect and all the .exp scripts that I had could easily be executed directly as long as the first line was #!/tmp/.../expect -f I then recompiled everything and it is now. #!/users/en-eecs/huangc/.../expect -f I am absolutely positive that this is the correct path for it but it simply doesn't work now. It appears that it is trying to execute it as a csh script as though it had ignored #! totally. At this point, I can of course just use "expect -f <expect_script>" but this creates problems when a given script tries to read specific arguments. ie: foobar.exp one two != expect -f foobar.exp one two If the script tries to read args 1 and 2 then it will see "one" and "two" in the first case and "-f" and "foobar.exp" in the second. The inconsistancy drives me nuts. I am on a DEC 5000 running Ultrix 4.0 Rev 179. I would like some idea of why #! doesn't work now, and if possible I would like to talk to some other people who are expect enthusiasts. I am a screen enthusiast and I can see some interesting interactive possibilites between expect and screen. Mail is welcome. ian frechett@snoopy.coloraod.edu -- -=Runaway Daemon=-
cpcahil@virtech.uucp (Conor P. Cahill) (12/24/90)
In article <1990Dec23.083329.22021@csn.org> frechett@snoopy.Colorado.EDU (-=Runaway Daemon=-) writes: >long as the first line was >#!/tmp/.../expect -f > >I then recompiled everything and it is now. >#!/users/en-eecs/huangc/.../expect -f >I am absolutely positive that this is the correct path for it but it simply >doesn't work now. It appears that it is trying to execute it as a csh The problem is that the kernel is interpreting the #! and it (the kernel) has a fixed limit on the number of bytes (I have seen it as low as 32 bytes). The solution is to put expect in a public place with a shorter path, or use symbolic links to make the path shorter. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
merlyn@iwarp.intel.com (Randal L. Schwartz) (12/24/90)
In article <1990Dec23.232842.4354@virtech.uucp>, cpcahil@virtech (Conor P. Cahill) writes: | The problem is that the kernel is interpreting the #! and it (the kernel) | has a fixed limit on the number of bytes (I have seen it as low as 32 bytes). | | The solution is to put expect in a public place with a shorter | path, or use symbolic links to make the path shorter. Amazingly enough, symbolic links *won't* help on anything as early as Ultrix 4.0 (it may be fixed in Ultrix 4.1). Apparently, the *expanded* name (what the symlink is linked to) has to also fit within the 32(!) character limit. Blech. SunOS is not so braindamaged... the 32-char limit applies only to the original text after the #! line. And why the number has to be so small (like 32 chars) is beyond me. Just another Unix hacker, -- /=Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 ==========\ | on contract to Intel's iWarp project, Beaverton, Oregon, USA, Sol III | | merlyn@iwarp.intel.com ...!any-MX-mailer-like-uunet!iwarp.intel.com!merlyn | \=Cute Quote: "Intel: putting the 'backward' in 'backward compatible'..."====/