Datatel finally came back with SETENV. It works from a VOC entry so now I'm just fighting with the Envision screen and the code for that.
The screen in Colleague that caused us to notice this does not send through the standard print routine. It was identified as using the UNIX Environment variable so the choice is fairly simple. User can't access colon prompt or UNIX prompt. We have to create an Envision screen to set the UNIX environment variable or tell 600 users (of which maybe 2 dozen need this feature) to learn a new, more hassling way to do their job. The best solution remains an Envision screen calling the colon prompt to set a UNIX variable. And all this should be able to be done in about 1-4 lines of code. lol Ron Sharcott (3635) -----Original Message----- From: Ken Wallis [mailto:[EMAIL PROTECTED] Sent: Thursday, March 30, 2006 2:59 PM To: 'U2Users' Subject: RE: [U2] Shell Escape Ron Sharcott wrote: >> -----Original Message----- >> From: Stewart Leicester [mailto:[EMAIL PROTECTED] >> I don't know the particulars of these scripts, but 2 things: >> >> 1) When you "shell out" of an application you're creating a separate >> shell process below the current one which inherits the environment of >> the creator. Any changes you make to the environment in the sub-shell >> are not propagated back to the parent shell. > To answer point #1 > This is true except if the script is 'sourced' in csh the command is > 'source' in Bourne (sh) and Korn (ksh) it sources using a dot > (.) and runs > the script as if it was part of the existing shell. Yes, but when you are inside UniData, you aren't running a bourne, korn or 'C' shell. You create a new ($SHELL) shell when you EXECUTE a bang "!" command. If the command you EXECUTE like this 'dots in' something then it is still only sourcing it into a shell which is about to terminate ... >> 2) Most applications, when first invoked, copy the state of >> environment variables to some internal structure. So even if you >> could change the environment variables in your own process, it >> wouldn't change the copy your application (UniData in this case) is >> using. > To add to point #2 > It is quite possible that UniData is scanning the UNIX environment and > then storing the variables. The real question is, are they stored > in a UDT file > somewhere that they can be edited and thereby altering the > UDT environment? Yes, they are stored in the environment of the running udt process. You can get at them in BASIC with GETENV(). They aren't scanned, they are inherited - this is standard UNIX process invocation stuff - process A (your logion shell) fork()s, the OS creates a new process B with a copy of everything A had, then process B exec()s the new code (udt) and process A wait()s for B to complete. You can't manipulate the environment of a parent process from a child. Full stop. A process can only manipulate its own environment. >> I suspect you're being tripped up by one or both of the above. >> >> Now, if you're executing your scripts *before* starting the UniData >> process, I don't know what's wrong. > The original entry into UDT ran something like this: > 1) log into UNIX > 2) .profile runs (not sourced) the menu /etc/profile and .profile *are* sourced by the login shell or you'd get no benefit from them. It's just that the mechanism is transparent to you - by the time you get access to the shell, it has already sourced it's startup scripts - .cshrc, .login for csh, .profile, $ENV for korn shell. > 3) menu can source the printer set up > 4) select database (path to voc) > > The new setup causing this trouble: > 1) log into UNIX > 2) .profile detects Terminal or Other application > if Other application stop at UNIX prompt and let Other application > initiate VOC > if Terminal then send to menu system, allow printer setting, then > on to VOC When you execute a UniData built-in verb like SETPTR, there is no new process created, udt deals with this internally, so it *can* change internal settings. The interesting thing to me about this is that your application appears to rely on an environment variable entirely for deciding where to print things. This is unusual in a U2 application. Are you sure that this environment variable isn't just a hint to Datatel/Envision - a way to adjust the default printer from the outside before you get into the app? I'd expect there to be other ways to adjust the printer settings once you are inside UniData, and SETPTR would be my top tip, but if you *HAVE* to adjust an environment variable to do it, you can write a small CALLC routine to hook into putenv() and you can call that from inside a BASIC program that you can EXECUTE and which will consequently not create new process. Just be aware of the normal points to be careful about when using putenv() - never putenv() a constant value or an automatic or static variable - always make a copy of what you are going to putenv() in some space you have malloc()ed, then putenv() that new memory address. Best Regards, Ken PS. I wouldn't be trying to teach someone with Stewart's experience to suck eggs if I were you. > -----Original Message----- > From: Ron Sharcott <[EMAIL PROTECTED]> > Date: Thu, 30 Mar 2006 08:09:59 -0800 > > I can't believe this. The results I'm getting are showing UniData only > allowing a shell for the environment variable and won't allow it to be > sourced. ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
