I'm looking for something similar to this question. However, I am looking specifically to dynamically find the location of the system's temp folder (i.e. the temp folder used by services.)
Is this possible?
Thanks,
Here you go (in VBS)
Set environmentVars = WScript.CreateObject("WScript.Shell").Environment("Process")
tempFolder = environmentVars("TEMP")
msgbox(tempFolder)
I'm not sure if your system will have an environment variable called "TEMP", so go to the command line and type
set
You'll get a list of environment vars, and their values. Pick the one that has your temp folder in it.
Set objShell = CreateObject("WScript.Shell")
Set colEnvironment = objShell.Environment("PROCESS")
objPath = colEnvironment("temp")
WScript.Echo objPath
In that case
Set objShell = CreateObject("WScript.Shell")
Set colEnvironment = objShell.Environment("PROCESS")
objPath = colEnvironment("windir")
WScript.Echo objPath & "\temp"
hope this will help
After researching a little into this, I believe there is no way to use environment variables to capture the location of another user's %TEMP% folder (in this case the System user).
The SYSTEM environment variables is stored in registry key: HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager\Environment
The environment variables for users is stored in registry keys: HKEY_USERS[user SID]\Environment
In order to get the value of any environment variable (in particular TEMP), need to check the presence of this variable in the branch for specified the user. If it is there, then you can use it. If it is not there, then you need to take a value from the system registry branch.
In C#, its...
System.Collections.IDictionary Vars = System.Environment.GetEnvironmentVariables();
String TempPath = Vars["TEMP"];
You get an entire array of elements... Path, Temp, SessionName, PathExt, UserDomain, SystemDrive, WinDir, etc...
Maybe this may be of some use: System.IO.Path.GetTempPath()
Related
I have this script saved in "test.vbs":
Set FSO = CreateObject("Scripting.FileSystemObject")
Set File = FSO.OpenTextFile(workFolder &"\test.txt", 2, True)
File.Write "testing"
File.Close
Set File = Nothing
Set FSO = Nothing
Set workFolder = Nothing
When I run the script I want to pass the value of the "workFolder" variable.
How can I do this? Can I do it? Something like "cscript test.vbs workFolder:'C:\temp\'" perhaps?
Bonus question: Is it neccessary to clean up the passed variable with "Set workFolder = Nothing" or does VBSCript do that automatically when it terminates? Maybe "Set File = Nothing" and "Set FSO = Nothing" is unneccessary also? Please let me know if you know the answer to both these questions.
You can use WScript.Arguments to access the arguments passed to your script.
Calling the script:
cscript.exe test.vbs "C:\temp\"
Inside your script:
Set File = FSO.OpenTextFile(WScript.Arguments(0) &"\test.txt", 2, True)
Don't forget to check if there actually has been an argument passed to your script. You can do so by checking the Count property:
if WScript.Arguments.Count = 0 then
WScript.Echo "Missing parameters"
end if
If your script is over after you close the file then there is no need to set the variables to Nothing. The resources will be cleaned up automatically when the cscript.exe process terminates. Setting a variable to Nothing usually is only necessary if you explicitly want to free resources during the execution of your script. In that case, you would set variables which contain a reference to a COM object to Nothing, which would release the COM object before your script terminates. This is just a short answer to your bonus question, you will find more information in these related questions:
Is there a need to set Objects to Nothing inside VBA Functions
When must I set a variable to “Nothing” in VB6?
Inside of VBS you can access parameters with
Wscript.Arguments(0)
Wscript.Arguments(1)
and so on. The number of parameter:
Wscript.Arguments.Count
Each argument passed via command line can be accessed with: Wscript.Arguments.Item(0) Where the zero is the argument number: ie, 0, 1, 2, 3 etc.
So in your code you could have:
strFolder = Wscript.Arguments.Item(0)
Set FSO = CreateObject("Scripting.FileSystemObject")
Set File = FSO.OpenTextFile(strFolder, 2, True)
File.Write "testing"
File.Close
Set File = Nothing
Set FSO = Nothing
Set workFolder = Nothing
Using wscript.arguments.count, you can error trap in case someone doesn't enter the proper value, etc.
MS Technet examples
You can also use named arguments which are optional and can be given in any order.
Set namedArguments = WScript.Arguments.Named
Here's a little helper function:
Function GetNamedArgument(ByVal argumentName, ByVal defaultValue)
If WScript.Arguments.Named.Exists(argumentName) Then
GetNamedArgument = WScript.Arguments.Named.Item(argumentName)
Else
GetNamedArgument = defaultValue
End If
End Function
Example VBS:
'[test.vbs]
testArg = GetNamedArgument("testArg", "-unknown-")
wscript.Echo now &": "& testArg
Example Usage:
test.vbs /testArg:123
To answer your bonus question, the general answer is no, you don't need to set variables to "Nothing" in short .VBS scripts like yours, that get called by Wscript or Cscript.
The reason you might do this in the middle of a longer script is to release memory back to the operating system that VB would otherwise have been holding. These days when 8GB of RAM is typical and 16GB+ relatively common, this is unlikely to produce any measurable impact, even on a huge script that has several megabytes in a single variable. At this point it's kind of a hold-over from the days where you might have been working in 1MB or 2MB of RAM.
You're correct, the moment your .VBS script completes, all of your variables get destroyed and the memory is reclaimed anyway. Setting variables to "Nothing" simply speeds up that process, and allows you to do it in the middle of a script.
I have this script saved in "test.vbs":
Set FSO = CreateObject("Scripting.FileSystemObject")
Set File = FSO.OpenTextFile(workFolder &"\test.txt", 2, True)
File.Write "testing"
File.Close
Set File = Nothing
Set FSO = Nothing
Set workFolder = Nothing
When I run the script I want to pass the value of the "workFolder" variable.
How can I do this? Can I do it? Something like "cscript test.vbs workFolder:'C:\temp\'" perhaps?
Bonus question: Is it neccessary to clean up the passed variable with "Set workFolder = Nothing" or does VBSCript do that automatically when it terminates? Maybe "Set File = Nothing" and "Set FSO = Nothing" is unneccessary also? Please let me know if you know the answer to both these questions.
You can use WScript.Arguments to access the arguments passed to your script.
Calling the script:
cscript.exe test.vbs "C:\temp\"
Inside your script:
Set File = FSO.OpenTextFile(WScript.Arguments(0) &"\test.txt", 2, True)
Don't forget to check if there actually has been an argument passed to your script. You can do so by checking the Count property:
if WScript.Arguments.Count = 0 then
WScript.Echo "Missing parameters"
end if
If your script is over after you close the file then there is no need to set the variables to Nothing. The resources will be cleaned up automatically when the cscript.exe process terminates. Setting a variable to Nothing usually is only necessary if you explicitly want to free resources during the execution of your script. In that case, you would set variables which contain a reference to a COM object to Nothing, which would release the COM object before your script terminates. This is just a short answer to your bonus question, you will find more information in these related questions:
Is there a need to set Objects to Nothing inside VBA Functions
When must I set a variable to “Nothing” in VB6?
Inside of VBS you can access parameters with
Wscript.Arguments(0)
Wscript.Arguments(1)
and so on. The number of parameter:
Wscript.Arguments.Count
Each argument passed via command line can be accessed with: Wscript.Arguments.Item(0) Where the zero is the argument number: ie, 0, 1, 2, 3 etc.
So in your code you could have:
strFolder = Wscript.Arguments.Item(0)
Set FSO = CreateObject("Scripting.FileSystemObject")
Set File = FSO.OpenTextFile(strFolder, 2, True)
File.Write "testing"
File.Close
Set File = Nothing
Set FSO = Nothing
Set workFolder = Nothing
Using wscript.arguments.count, you can error trap in case someone doesn't enter the proper value, etc.
MS Technet examples
You can also use named arguments which are optional and can be given in any order.
Set namedArguments = WScript.Arguments.Named
Here's a little helper function:
Function GetNamedArgument(ByVal argumentName, ByVal defaultValue)
If WScript.Arguments.Named.Exists(argumentName) Then
GetNamedArgument = WScript.Arguments.Named.Item(argumentName)
Else
GetNamedArgument = defaultValue
End If
End Function
Example VBS:
'[test.vbs]
testArg = GetNamedArgument("testArg", "-unknown-")
wscript.Echo now &": "& testArg
Example Usage:
test.vbs /testArg:123
To answer your bonus question, the general answer is no, you don't need to set variables to "Nothing" in short .VBS scripts like yours, that get called by Wscript or Cscript.
The reason you might do this in the middle of a longer script is to release memory back to the operating system that VB would otherwise have been holding. These days when 8GB of RAM is typical and 16GB+ relatively common, this is unlikely to produce any measurable impact, even on a huge script that has several megabytes in a single variable. At this point it's kind of a hold-over from the days where you might have been working in 1MB or 2MB of RAM.
You're correct, the moment your .VBS script completes, all of your variables get destroyed and the memory is reclaimed anyway. Setting variables to "Nothing" simply speeds up that process, and allows you to do it in the middle of a script.
I have the below VBScript (values and names changed)
Dim InstanceName
Set objShell = WScript.CreateObject("WScript.Shell")
Set objEnv = objShell.Environment("USER")
objEnv("PLUGIN") = "plugin"
objEnv("CONF") = "location"
Set ArgObj=Wscript.Arguments
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objTextFile = objFSO.OpenTextFile("path.txt", 1)
AbsolutePath = objTextFile.ReadLine
objTextFile.Close
directory = "C:\Program Files\"&AbsolutePath&"\bin"
executable = directory&"\app-"&InstanceName&".exe"
objShell.CurrentDirectory = directory
objShell.Run Chr(34) & executable & Chr(34), 1, false
Set objShell = Nothing
My program uses the environment variables PLUGIN and CONF. However, the first time the program is launched using the script, it cannot find the environment variables. The subsequent launches work fine as the environment variables are already set.
I can see them when I check in control panel even after the first launch but the executable doesn't seem to pick them up.
How can I make the variables be set correctly for the executable the first time the script is run?
Thanks!
The problem is that the values are not being stored as User environment variables. Reading through the documentation you want to make sure that you set the Environment property of the WScript.Shell object to the correct set of environment variables, as per the documentation the values are;
System
User
Volatile
Process
Would recommend changing the code to use;
Set objEnv = objShell.Environment("SYSTEM")
and go from there.
I'm coding a new VBS script, which should create a TXT file in the Documents directory. While with other inputs I used %USERNAME% for the User Name of the PC, the command "CreateTextFile" seems to want the real directory, without including any variables like %USERNAME%.
I'm kinda of new to this so I can't figure it out.
That's what I tried:
Dim objFS, objFile
Set objFS = CreateObject("Scripting.FileSystemObject")
Set objFile = objFS.CreateTextFile("C:\Users\%USERNAME%\Documents\Demo.txt", true)
objFile.WriteLine("some sample text")
It should understand %USERNAME% as the UserName of the PC, but doesn't.
What I get as result is the program saying he can't find the directory C:\Users\%USERNAME%\Documents.
To get the desktop one uses
SpecialFolders Property
Returns a SpecialFolders object (a collection of special folders).
object.SpecialFolders(objWshSpecialFolders)
Arguments
object WshShell object.
objWshSpecialFolders The name of the special folder. (eg Desktop)
Environment strings are not expanded. You can pass an entire string containing environmental variables. EG "%userprofile%\Desktop". This code lists all variables available https://pastebin.com/rrEyVxFd.
ExpandEnvironmentStrings Method
Returns an environment variable's expanded value.
object.ExpandEnvironmentStrings(strString)
Arguments
object WshShell object.
strString String value indicating the name of the environment variable
you want to expand.
There are plenty longer drawn-out, which are appropriate but these are a couple examples - much easier:
Option Explicit
Msgbox CreateObject("WScript.Network").UserName
' or into a variable
Dim oShell : set oShell = CreateObject("WScript.Network")
Dim UserName : UserName = oShell.UserName
Msgbox UserName
Set oShell = Nothing
I have this script saved in "test.vbs":
Set FSO = CreateObject("Scripting.FileSystemObject")
Set File = FSO.OpenTextFile(workFolder &"\test.txt", 2, True)
File.Write "testing"
File.Close
Set File = Nothing
Set FSO = Nothing
Set workFolder = Nothing
When I run the script I want to pass the value of the "workFolder" variable.
How can I do this? Can I do it? Something like "cscript test.vbs workFolder:'C:\temp\'" perhaps?
Bonus question: Is it neccessary to clean up the passed variable with "Set workFolder = Nothing" or does VBSCript do that automatically when it terminates? Maybe "Set File = Nothing" and "Set FSO = Nothing" is unneccessary also? Please let me know if you know the answer to both these questions.
You can use WScript.Arguments to access the arguments passed to your script.
Calling the script:
cscript.exe test.vbs "C:\temp\"
Inside your script:
Set File = FSO.OpenTextFile(WScript.Arguments(0) &"\test.txt", 2, True)
Don't forget to check if there actually has been an argument passed to your script. You can do so by checking the Count property:
if WScript.Arguments.Count = 0 then
WScript.Echo "Missing parameters"
end if
If your script is over after you close the file then there is no need to set the variables to Nothing. The resources will be cleaned up automatically when the cscript.exe process terminates. Setting a variable to Nothing usually is only necessary if you explicitly want to free resources during the execution of your script. In that case, you would set variables which contain a reference to a COM object to Nothing, which would release the COM object before your script terminates. This is just a short answer to your bonus question, you will find more information in these related questions:
Is there a need to set Objects to Nothing inside VBA Functions
When must I set a variable to “Nothing” in VB6?
Inside of VBS you can access parameters with
Wscript.Arguments(0)
Wscript.Arguments(1)
and so on. The number of parameter:
Wscript.Arguments.Count
Each argument passed via command line can be accessed with: Wscript.Arguments.Item(0) Where the zero is the argument number: ie, 0, 1, 2, 3 etc.
So in your code you could have:
strFolder = Wscript.Arguments.Item(0)
Set FSO = CreateObject("Scripting.FileSystemObject")
Set File = FSO.OpenTextFile(strFolder, 2, True)
File.Write "testing"
File.Close
Set File = Nothing
Set FSO = Nothing
Set workFolder = Nothing
Using wscript.arguments.count, you can error trap in case someone doesn't enter the proper value, etc.
MS Technet examples
You can also use named arguments which are optional and can be given in any order.
Set namedArguments = WScript.Arguments.Named
Here's a little helper function:
Function GetNamedArgument(ByVal argumentName, ByVal defaultValue)
If WScript.Arguments.Named.Exists(argumentName) Then
GetNamedArgument = WScript.Arguments.Named.Item(argumentName)
Else
GetNamedArgument = defaultValue
End If
End Function
Example VBS:
'[test.vbs]
testArg = GetNamedArgument("testArg", "-unknown-")
wscript.Echo now &": "& testArg
Example Usage:
test.vbs /testArg:123
To answer your bonus question, the general answer is no, you don't need to set variables to "Nothing" in short .VBS scripts like yours, that get called by Wscript or Cscript.
The reason you might do this in the middle of a longer script is to release memory back to the operating system that VB would otherwise have been holding. These days when 8GB of RAM is typical and 16GB+ relatively common, this is unlikely to produce any measurable impact, even on a huge script that has several megabytes in a single variable. At this point it's kind of a hold-over from the days where you might have been working in 1MB or 2MB of RAM.
You're correct, the moment your .VBS script completes, all of your variables get destroyed and the memory is reclaimed anyway. Setting variables to "Nothing" simply speeds up that process, and allows you to do it in the middle of a script.