none
environment to a child process RRS feed

  • Question

  • I'm trying to solve another problem related to login scripts in DC, using a .vbs program but i'm stuch in another problem that is:

    Code:

    Set objShell = wscript.createobject("wscript.shell")

    objShell.Run("here it call another .vbs that set some VOLATILE variables and needs to be VOLATILE")

    objShell.Run("here I call my exe that needs the variables that was set by the previous command")

    problem: when I call me exe it didn't "see" the variables, but if I run the .vbs by the second time it works because now it sees the variables. Already put a stop between objShell.Run to check if the problem was the time and wait 1 minute and didn't works.

    Monday, December 9, 2013 9:58 AM

Answers

All replies

  • Here's my response from the original thread:

    I don't think you can do this, as written.  When you use objShell.Run, you're creating a new child process, and any environment variables you set there do not get applied to the parent process.

    One thing you could do is load up the contents of that other VBScript file into a String variable, and then pass that variable to the Execute or ExecuteGlobal function.  That way the code is running in your current process, rather than a child process, and you should have all the proper environment variables at that point.

    Monday, December 9, 2013 12:48 PM
  • it's a too big script (263 lines), I also tried to it at in just one script but also failed.

    I did like this:

    set variables

    objShell.exec("program.exe") 'Failed

    objShell.run("program.exe") 'also failed

    Monday, December 9, 2013 3:26 PM
  • The reason this doesn't work is that when you use Exec or Run, you are spawning a child process. Environment variables set in a child process do not propagate to the parent process.

    You will have to use a different approach, such as writing the data to a temporary file and then read the data from the calling script.

    Bill

    Monday, December 9, 2013 3:52 PM
    Moderator
  • Let me explain better why it's not possible

    I need set some variables to be used for Oracle Forms/Reports 6, dynamically according to the site where the user is, for example

    FORMS60_PATH=\\serveroflocal\share\ where the serveroflocal changes according to the site where the user is.

    at the end of the script that have a lot of lines (this is just a example of one environment variable), I need run the form runtime, that is "IFRUN60 mymainmodule.fmx", and in this case the IFRUN60 will take the information is it should according to user site at that moment (the user uses notebook and travel across several sites).

    Monday, December 9, 2013 4:04 PM
  • Let me explain better why it's not possible

    Why what's not possible?

    The technical constraint you are running into - you cannot propagate environment variables to a parent process - cannot be circumvented. Just because you want to do this, does not mean that you will be able to.

    You can, however, write environment variables to the current user's environment block. In this case, the updated environment will be visible to new processes. It sounds to me like this would be your preferred approach.

    Something like this:


    Dim WshShell
    Set WshShell = CreateObject("Wscript.Shell")
    WshShell.Environment("USER").Item("FORMS60_PATH") = "\\servername\share\path"
    

    If you run this from a logon script, the FORMS60_PATH environment variable will get set for the current user.

    Bill

    Monday, December 9, 2013 4:17 PM
    Moderator
  • Didn't works for the same reason ... when the user runs for the first time the variable is not available for the children process, so when users move from site A to site B, at the first time the script run the value for the users is site A (yet) and in the case the first time when the users is on site B it try to use information from site A.

    Monday, December 9, 2013 4:54 PM
  • Set the variables in the logon script or in the GP for the user.

    You should take this issue to Oracle.  They can show you how to use this correctly.

    The documentation for Oracle user setups is vague and confusing and always has been.  The user forum on Oracle will walk you through setting up a user for any Oracle subsystem.

    As noted above - it is no possible to set variables and have them visible in another already running process.  Whe a process is launched it gets a copy of the current variables.  Those variables are no shared and cannot be changed permanetntly directly.  YOu can change the main variables but the change will not be visible in the current script or any that it runs.  Changed made to local variables will be inherited by processes spawned by the current process.

    That is Windows and it cannot be change or made to work any other way.  It has been designed like that for a reason.

    User variables that are global are set in the users profile.  THis can be done via Group Policy (preferred method) or in a logon script.


    ¯\_(ツ)_/¯

    Monday, December 9, 2013 5:03 PM
  • My example, if run in a logon script, will set the variable when the user logs on.

    If you launch the application after logging on, it will use the correct variable. The variable will remain set in the current user's profile until they log on again.

    Are you saying users switch sites without logging off and then logging back on? If that's the case, then of course trying to set the variable when the user logs on is not going to work as expected.

    If the variable needs to be defined immediately before launching the application, then define it in a launcher script that sets the variable, then launches the application.

    Bill

    Monday, December 9, 2013 5:11 PM
    Moderator
  • Yes, I know that, and i'm using this on login script for a long time ... I'm just try use in real time because login script sometimes fails, already set all the can be found about thousand and thousands of doc about login script failing but sometimes it fails, already set run synchronous, wait for network, etc, and sometimes it fails and I have to ask to the users "please logoff and login back" and this works, but don't want ask this for the users.

    Another problem that I have with login script is that sometimes the users close the notebook without turn off, and open on the new site. So not log again and environment is from the previous site when click on Oracle Runtime.

    Anyway thanks.

    Monday, December 9, 2013 5:11 PM
  • Another problem that I have with login script is that sometimes the users close the notebook without turn off, and open on the new site. So not log again and environment is from the previous site when click on Oracle Runtime.

    This is an important piece of information that you left out of your original post (I guessed it in my previous response).

    In your case, you want to define the variables before launching the application. Then do that. Create a script that sets the variables in the current environment, then start the application. Have users run the application using the script.

    Bill

    Monday, December 9, 2013 5:15 PM
    Moderator
  • Yes, I created a shortcut at the users desktop point \\domain\sysvol\....\..\login.vbs (my login script), and instructed the user to click on it, before clicking in the application, but, what i'm trying to do is having user just clicking in the application.

    Monday, December 9, 2013 5:19 PM
  • I am assuming "clicking in the application" means "start the application".

    What I am suggesting is creating a script that 1) defines the needed environment variables and then 2) starts the application. Users then launch the application by running the script.

    You can deliver this script with the application installation and copy a shortcut to the desktop (or wherever users are accustomed to starting the application).

    This is really an application installation design/delivery question, not a scripting question. I agree with what was posted earlier about engaging Oracle resources to solve this problem in a supported manner.

    Bill

    Monday, December 9, 2013 5:31 PM
    Moderator
  • variables set in a logon script or with GP can beset once and they will persist.  There is no need to redo them on every logon.

    There is also the SETX utility which can set persistent variables.

    In most cases newer Oracle systems do not require environment variables.  The only variable required are set to the system and all users get them.  They point at TNSNAMES globally and we use TNSNAMES to point to the resource servers. Check the Oracle site for tutorials and training on how to implement Oracle services and utilities.

    SETX /?


    ¯\_(ツ)_/¯

    Monday, December 9, 2013 8:00 PM
  • variables set in a logon script or with GP can beset once and they will persist. There is no need to redo them on every logon.

    This is correct, except I understood the OP to be saying that he neds need different environment variable values depending on where the user logged on (hence his attempt to use a logon script). I think this is not the optimal approach, for the reasons already adduced.

    Bill

    Monday, December 9, 2013 8:25 PM
    Moderator
  • Correct, I need them according to the site where the user is at the moment, that's why I set them as "Volatile" because I want them just while the users is logged in and in the site. When the users move to another site I need them according to the new site.

    My ERP is made in house, and has new/fix forms during the day that I copy to file server at sites. I don't want to copy forms to computer, just to servers (and this is working for a long time, except when login script fails). I know the the obvious would be " fix the login script problem" and I tried that for more the 2 years, including contracting consultant companies, without success (all gold partners MS). That's why i'm trying to fix using scripts.

    Like told before, just as example FORMS60_PATH=\\serverofthesitewhereuseris\share

    I do this at login script and works perfect (when the login scripts runs). I didn't some workaround like creating a short cut to user run login script when it fails. put it in startup, etc ... I'm just try to find a smart solution, steady of running workarounds.

    Monday, December 9, 2013 8:50 PM
  • If your logon script doesn't run consistently (for some reason), then I think the best short-term answer is to create a launcher script that sets the needed variable and launches the application, and get the users to run the application using the launcher script.

    The best long-term answer is to set this up using the correct Oracle server settings so that you only need to set one global variable per machine, and you can do this via GPO as noted previously.

    This is probably the best answer we can offer in a scripting forum.

    Bill

    Monday, December 9, 2013 8:58 PM
    Moderator
  • this exactly the topic of discussion: how to set the variables and launch the application at the same script, remembering that the application needs to know the variables that was set

    I don't know how much you know by Oracle Forms/Reports 6, it runs as client/server not as application server so it is several variables that needs be set, like FORMS60_PATH, REPORTS60_PATH, TNS_ADMIN (around 8) different dependent of the site

    Monday, December 9, 2013 9:03 PM
  • Here is a sample of how you can do this in a VBScript script:


    ' Set up the environment variable names and values.
    Dim Settings
    Set Settings = CreateObject("Scripting.Dictionary")
    Settings.Add "FORMS60_PATH", "\\servername\formspath"
    Settings.Add "REPORTS60_PATH", "\\servername\reportspath"
    Settings.Add "TNS_ADMIN", "\\servername\tnsadminpath"
    ' ...etc.
    
    Dim WshShell, WshEnvironment
    Set WshShell = CreateObject("WScript.Shell")
    Set WshEnvironment = WshShell.Environment("PROCESS")
    
    ' Set all of the variables in the current process.
    For Each Setting in Settings.Keys()
      WshEnvironment.Item(Setting) = Settings(Setting)
    Next
    
    ' Start your application. It will inherit the environment variables.
    WshShell.Run """c:\program files\application directory\yourapplication.exe"" parameters", 1, False
    

    Bill

    Monday, December 9, 2013 9:17 PM
    Moderator
  • variables set in a logon script or with GP can beset once and they will persist. There is no need to redo them on every logon.

    This is correct, except I understood the OP to be saying that he neds need different environment variable values depending on where the user logged on (hence his attempt to use a logon script). I think this is not the optimal approach, for the reasons already adduced.

    Bill


    A GP can be devised that is location sensitive.  It is done all of the time.

    ¯\_(ツ)_/¯

    Monday, December 9, 2013 9:22 PM
  • Correct, I need them according to the site where the user is at the moment, that's why I set them as "Volatile" because I want them just while the users is logged in and in the site. When the users move to another site I need them according to the new site.

    My ERP is made in house, and has new/fix forms during the day that I copy to file server at sites. I don't want to copy forms to computer, just to servers (and this is working for a long time, except when login script fails). I know the the obvious would be " fix the login script problem" and I tried that for more the 2 years, including contracting consultant companies, without success (all gold partners MS). That's why i'm trying to fix using scripts.

    Like told before, just as example FORMS60_PATH=\\serverofthesitewhereuseris\share

    I do this at login script and works perfect (when the login scripts runs). I didn't some workaround like creating a short cut to user run login script when it fails. put it in startup, etc ... I'm just try to find a smart solution, steady of running workarounds.

    A GP is/can be site sensitive.  This is one of the most useful uses for GP application of rules.  Different location different rules.

    The systems design community is now working to eliminate all logon scripts.  They are a legacy component and have been overused and misused for quite a while.  The old excuse was the GP couldn't do many things.  Microsoft upgraded GP with extensions that address almost ervy possible situation except bad design.  It is time to learn to use GP.

    When we move to the cloud logon scripts will be a liability.


    ¯\_(ツ)_/¯

    Monday, December 9, 2013 9:25 PM
  • Sure. This depends on the design. I already argued that an application launcher script (like the one I posted) is really only a short-term solution.

    Bill

    Monday, December 9, 2013 9:37 PM
    Moderator
  • Bill, for me if it works is a solution that i'm looking for but it didn't inherit the environment, look the example:

    Dim WSHShell
    Dim objEnv
    Set WSHShell = WScript.CreateObject("WScript.Shell")
    Set objEnv = WSHShell.Environment("Volatile")
    objEnv("A") = "B"

    WScript.Echo objEnv("A")

    WshShell.Run ("notepad %A%")

    Note that at the first time that you run %A% value nothing, at the second time it value B.

    Monday, December 9, 2013 9:53 PM
  • Don't use "volatile". Use "process".

    Bill

    • Marked as answer by EASF-BR Wednesday, December 11, 2013 9:33 AM
    Monday, December 9, 2013 10:01 PM
    Moderator