jlh@loral.UUCP (Physically Pffft) (11/08/88)
Now that we've all de-wormed ourselves can we get back to work? I've got 2 questions on Sun Unix, the first a real weirdy and the second a simple make question. First the weird one. I'm porting an application from a Vax (4.3bsd) to a Sun (4.2bsd v3.5). Part of it is a menu manager that uses vt100 escape sequences to control the screen io. We can send commands to the terminal just fine. Usually. There's an escape sequence to request the current x,y coordinates, the terminal responds with an escape sequence of it's own back to the program. On the Vax this works fine. On the Sun the terminal's responce is echo'd back to the terminal (we run CBREAK mode, no echo). Using dbx it looked like my program never got the response. I put in some debugging code, it still looked like my program never saw the response. I hooked up an RS232 analyzer to my terminal, the escape sequence was going out and then got echo'd right back. So who the hay is echoing the responce back to my terminal? I can type in the escape sequence from the keyboard at the appropriate time and the characters go to the program with no echo. So why doesn't the terminal's response go to my program?? I can login to a Sun, rlog to a Vax, and run the Vax version just fine. But if I ever try to run the Sun version I get this problem. I rlogged into about 4 different machines sequentialy so the terminal response went through everyone and their mother from the terminal to the program running on the Vax, it worked fine. Any ideas? I should mention we have file servers, nfs mounts, and lots of other stuff I don't understand in the system. I've also discovered that any command that causes the terminal to output a response does the same thing. Now the make question. Sun's make has a great little 'include' feature. Well, we changed directory structures and I had to edit the 'include' line in 12 different Makefiles. I've been trying to set an environment variable to our include file but when I invoke make I get Make: Cannot read or access $SYS300MAKE. Stop. I've tried all kinds of things (include $$SYS300MAKE, include $SYS300MAKE, include ($SYS300MAKE) among others) to no avail. Anyone got any ideas? Jim -- Jim Harkins jlh@loral.cts.com Loral Instrumentation, San Diego
guy@auspex.UUCP (Guy Harris) (11/10/88)
>First the weird one. I'm porting an application from a Vax (4.3bsd) to >a Sun (4.2bsd v3.5). ... On the Vax this works fine. On the Sun the >terminal's responce is echo'd back to the terminal If the terminal is not connected directly to the Sun, I'd suspect whatever is in between the terminal and the Sun; otherwise, the only likely cause would be some hardware weirdness, because the tty driver in SunOS 3.5 is, with minor changes unrelated to echoing, the tty driver in 4.3BSD. >Now the make question. Sun's make has a great little 'include' feature. The SunOS "make"s are derived from the S5R2 one (although the SunPro "make" that's optional with later 3.x versions and standard with 4.0 is, as stated in the comments in the SCCS lines, only "remotely from" the S5 one...); that's where the "include" feature, as well as the "import 'make' variables from the environment" feature, come. >Well, we changed directory structures and I had to edit the 'include' line >in 12 different Makefiles. I've been trying to set an environment >variable to our include file but when I invoke make I get > >Make: Cannot read or access $SYS300MAKE. Stop. > >I've tried all kinds of things (include $$SYS300MAKE, include $SYS300MAKE, >include ($SYS300MAKE) among others) to no avail. Anyone got any ideas? Try include $(SYS300MAKE) The correct syntax for references to multi-character "make" variables is not "$FOO", nor "$$FOO", nor "($FOO)", but "$(FOO)" (or alternatively, at least in most cases, "${FOO}"). Now, if you're using the SunPro "make", the SunOS 3.5 version may not have expanded "make" variables in "include" lines; the SunOS 4.0 version definitely expands them (I just tried it). The S5R3 "make" also expands them, although the S5R2 version might not have done it and thus the non-SunPro SunOS "make" may not expand them either. (This is unlikely, though.)