MichaelPracht Posted November 3, 2010 Posted November 3, 2010 I've created and compiled a script that lives in Windows\System32. When I run it, I want to create a log file in the folder where the script is executed (so, I run it from c:\ but it lives in c:\Windows\System32 and I want it to create c:\script.log). The problem is that @WorkingDir and @ScriptDir returns "C:\Windows\System32" instead of the directory where the script was executed. Anybody know how I can set a variable to the folder path where the script is actually called from? If I just execute: FileWriteLine("test.log", "Output goes here.") ...then it creates the log file in the folder where the script lives (C:\Windows\System32), instead of where I am when I execute the script.
Varian Posted November 3, 2010 Posted November 3, 2010 Just useFileChangeDir("C:\")before you start the output to file
MichaelPracht Posted November 3, 2010 Author Posted November 3, 2010 On 11/3/2010 at 2:54 PM, 'Varian said: Just useFileChangeDir("C:\")before you start the output to file But I won't know where the script is being run from. So, for example the script may be run from G:\folder\mystuff and I would want to create the log file G:\folder\mystuff\script.log
willichan Posted November 3, 2010 Posted November 3, 2010 How are you executing the script? My UDFs: Barcode Libraries, Automate creation of any type of project folder, File Locking with Cooperative Semaphores, Inline binary files, Continue script after reboot, WinWaitMulti, Name Aggregator, Enigma, CornedBeef Hash
MichaelPracht Posted November 3, 2010 Author Posted November 3, 2010 From a command window. The script is in C:\Windows\System32, which is in my PATH, but I may execute it from C:\thisfolder\thatfolder\righthere
trancexx Posted November 3, 2010 Posted November 3, 2010 Then pass command line parameter with desired location and add parsing in your script. Regardless of the solution you seem to be confused with the terms. ♡♡♡ . eMyvnE
MichaelPracht Posted November 3, 2010 Author Posted November 3, 2010 Confused with what terms? If you mean: runme -path "c:\thispath" well, I'd rather not force the user to reenter the path they're already in. I assumed the script could know where it is being run from.
Varian Posted November 3, 2010 Posted November 3, 2010 Then run it this way:RunWait("C:\Windows\System32\YourProgram.exe", @ScriptDir)You'll have to provide the full executable path since your working folder is different
trancexx Posted November 3, 2010 Posted November 3, 2010 (edited) On 11/3/2010 at 6:14 PM, 'MichaelPracht said: Confused with what terms?With this... On 11/3/2010 at 6:14 PM, 'MichaelPracht said: I assumed the script could know where it is being run from.It knows, but you don't. @WorkingDir and @ScriptDir are just fine. What you want is something else and that's not related to your script but to the process that starts them. Edited November 3, 2010 by trancexx ♡♡♡ . eMyvnE
MichaelPracht Posted November 4, 2010 Author Posted November 4, 2010 Ok, let me try to explain this again. I have a compiled script, let’s say it’s called “files-list.exe”, and its purpose is to write a list of the files in the folder where it’s executed from into a text file (called “files-list.txt”) that the user can then edit or print. The compiled script has been placed in C:\WINDOWS\System32 (which is in the user’s PATH) so that it can be called from any folder on the user’s system. The user starts a command prompt. They navigate to “C:\Documents and Settings\All Users\Desktop” and then they type “files-list”. The script executes. If the script tries to create files-list.txt in @WorkingDir, the script is created at C:\WINDOWS\System32\files-list.txt. If it tries to create the text file in @ScriptDir, it creates C:\WINDOWS\System32\files-list.txt. I’ve not found a way to tell the script to create the file in <currentdir>\files-list.txt. The answer is probably very simple, but so far it eludes me.
Richard Robertson Posted November 4, 2010 Posted November 4, 2010 Is your script receiving elevated permissions? If so, it will run with a changed working directory.
MichaelPracht Posted November 5, 2010 Author Posted November 5, 2010 It looks like @WorkingDir will not return the actual current/working directory unless your script is run from an elevated command prompt. Adding #requireadmin to the beginning of the script is not sufficient enough. This behavior isn’t specified on the website (http://www.autoitscript.com/autoit3/docs/macros.htm). So, my problem now has become: how do I detect that the script was not run from an elevated command prompt, so I can instruct the user? If they run the script from a non-elevated command prompt and it tries to create “files-list.txt” in @WorkingDir, it will attempt to create “C:\WINDOWS\System32\files-list.txt”. Whether the script succeeds or fails to write there, the user will be looking in their current folder, thinking that the script didn’t work. I don’t want to tell the user to look in “C:\WINDOWS\System32” because (aside from being a hassle) I want them to be able to place the compiled script in ANY folder in their PATH. Ideas? BTW, $CurPath = EnvGet("cd") returns an empty string regardless of whether I run from an elevated or non-elevated command prompt (I'm running on 32-bit Windows 7 Enterprise.)
Richard Robertson Posted November 5, 2010 Posted November 5, 2010 You should use the Au3Wrapper command of #AutoIt3Wrapper_Res_requestedExecutionLevel=requireAdministrator That might solve it.
Juvigy Posted November 5, 2010 Posted November 5, 2010 Quote C:\Windows\System32, which is in my PATH, but I may execute it from C:\thisfolder\thatfolder\righthereAnd how would you do that ? No mater from where you execute it , the exe is still in C:\Windows\System32 right ? @WorkingDir will change only if you make a shortcut with another workingdir path. I think it would be best to do:1. FileWriteLine(@MyDocumentsDir & "test.log", "Output goes here.")or2. FileWriteLine(@UserProfileDir & "test.log", "Output goes here.")or something like that
MichaelPracht Posted November 5, 2010 Author Posted November 5, 2010 The beginning of my script now looks like this: #RequireAdmin #AutoIt3Wrapper_Res_requestedExecutionLevel=requireAdministrator However, @WorkingDir still returns "C:\WINDOWS\System32", if not run from an elevated command prompt.
MichaelPracht Posted November 5, 2010 Author Posted November 5, 2010 On 11/5/2010 at 1:48 PM, 'Juvigy said: And how would you do that ? No mater from where you execute it , the exe is still in C:\Windows\System32 right ? @WorkingDir will change only if you make a shortcut with another workingdir path. I think it would be best to do:1. FileWriteLine(@MyDocumentsDir & "test.log", "Output goes here.")or2. FileWriteLine(@UserProfileDir & "test.log", "Output goes here.")or something like thatI just don't want the user to have to navigate somewhere else for the output. I want to create it in the same folder they're already in.
BrewManNH Posted November 5, 2010 Posted November 5, 2010 If you change your program to accept command line arguments, you can run it from a batch file placed anywhere in your system's path, such as the Windows\System32. In your batch file that you use to run your program, add the command line argument %CD% and that will be translated to the current folder that you are running the batch file from. Example batch file: dir "%cd%" This will give you a directory listing of all files in the current directory. If I posted any code, assume that code was written using the latest release version unless stated otherwise. Also, if it doesn't work on XP I can't help with that because I don't have access to XP, and I'm not going to.Give a programmer the correct code and he can do his work for a day. Teach a programmer to debug and he can do his work for a lifetime - by Chirag GudeHow to ask questions the smart way! Reveal hidden contents I hereby grant any person the right to use any code I post, that I am the original author of, on the autoitscript.com forums, unless I've specifically stated otherwise in the code or the thread post. If you do use my code all I ask, as a courtesy, is to make note of where you got it from. Back up and restore Windows user files _Array.au3 - Modified array functions that include support for 2D arrays. - ColorChooser - An add-on for SciTE that pops up a color dialog so you can select and paste a color code into a script. - Customizable Splashscreen GUI w/Progress Bar - Create a custom "splash screen" GUI with a progress bar and custom label. - _FileGetProperty - Retrieve the properties of a file - SciTE Toolbar - A toolbar demo for use with the SciTE editor - GUIRegisterMsg demo - Demo script to show how to use the Windows messages to interact with controls and your GUI. - Latin Square password generator
JoHanatCent Posted November 5, 2010 Posted November 5, 2010 Try: RunWait(@ComSpec & " /c %SystemDrive%&&cd %temp%&&echo %cd%>temp.tmp", "", @SW_hide); create temp file to save %cd% $file = FileOpen(@TempDir & "\temp.tmp", 0) ; Check if file opened for reading OK If $file = -1 Then MsgBox(0, "Error", "Unable to open file." & $file) Exit EndIf ; Read in lines of text until the EOF is reached While 1 $line = FileReadLine($file) If @error = -1 Then ExitLoop MsgBox(0, "Current DIR:", $line) WEnd FileClose($file) FileDelete(@TempDir & "\temp.tmp")
MichaelPracht Posted November 5, 2010 Author Posted November 5, 2010 On 11/5/2010 at 2:00 PM, 'JoHanatCent said: Try: RunWait(@ComSpec & " /c %SystemDrive%&&cd %temp%&&echo %cd%>temp.tmp", "", @SW_hide); create temp file to save %cd% $file = FileOpen(@TempDir & "\temp.tmp", 0) ; Check if file opened for reading OK If $file = -1 Then MsgBox(0, "Error", "Unable to open file." & $file) Exit EndIf ; Read in lines of text until the EOF is reached While 1 $line = FileReadLine($file) If @error = -1 Then ExitLoop MsgBox(0, "Current DIR:", $line) WEnd FileClose($file) FileDelete(@TempDir & "\temp.tmp") This returns "C:\WINDOWS\System32", so no advantage here that I can see (but thanks for the suggestion).
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now