I am running into a problem automating an installation procedure. I want to install a program, and then patch it with a custom UserPatch to remove some glitches.
The UserPatch executable must be run from the installation directory, so I must retrieve this address from the installer. Then, after the program is installed, the script must copy the UserPatch file to the installation directory, and run it from there.
I retrieve the pathname as shown below. The script copies the raw text from the window, which I strip down to just the line containing the pathname.
WinActivate("Dir browse box title")
$InstallDir = WinGetText("Dir browse box title")
$split = StringSplit( $InstallDir, "&Path", 1)
$InstallDir = $split[2]
$split = StringSplit( $InstallDir, "&OK", 1)
$InstallDir = $split[1]
ControlClick("Dir browse box title", "&Drives", "[Class:CButtonClassName; INSTANCE:2]")
Sleep(100)
When printing "$InstallDir" after the above procedure, it shows exactly what I want it to be: "C:\Program Files (x86)\Path to\Installation folder" (without '"').
The problem is this: It doesn't copy the file when I run the code snippet below. It does work when I hardcode the pathname (commented in the code below), but not when using the $InstallDir variable as retrieved by the code snippet above.
; Install the UserPatch
; $InstallDir = "C:\Program Files (x86)\Path to\Installation folder"
$UserPatchName = "SetupAoC.exe"
FileCopy($UserPatchName, $InstallDir & "\" & $UserPatchName)
Run($InstallDir & "\" & $UserPatchName)
WinWait("SetupAoC - Feature Update Tool")
ControlClick("SetupAoC - Feature Update Tool", "Install", "[Class:DirectUIHWND; INSTANCE:1]")
Send("{SPACE}")
Sleep(2000)
WinClose ("SetupAoC - Install Complete")
WinClose ("SetupAoC - Feature Update Tool")
I've got the feeling that I'm missing something obvious, but I really can't tell what the problem is? Any ideas?
Thanks in advance!
EDIT in reply to comments:
After
$InstallDir = WinGetText("Dir browse box title")
the value of $InstallDir is
&Drives
C:\ Crucial M500
&Folders
&Path
C:\Program Files (x86)\Path to\Installation folder
&OK
&Cancel
I then use StringSplit, which creates an array of strings, separated by the specified delimiter.
OK, problem eliminated.
The problem was that my "C:\path...." string was preceded and trailed by two #CRLF characters (new lines). These were also present in the raw data that I copied from the window, as I didn't include them in my delimiters.
I didn't notice them when printing the output, as they're white-space. I found out when writing the $InstallDir variable to a file, in a desperate attempt.
Anyway, Solved with
$InstallDir = StringReplace($InstallDir, #CRLF, "")
Thanks for the tips, #Matrix and #McBarby!
Related
I first noticed this problem a bit ago when I posted this thread. Essentially, I'm getting a very strange issue where Python "sees" files that don't actually exist in my file browser when working with files.
As in, if I open a file with an absolute path, modify and print the contents of it through Python, it will print exactly what it's supposed to. But when I try to open the same file through the same absolute path on my Windows file browser, the file is not updated with my modifications.
I experienced a similar issue recently as well - renaming files. Here's a simple script I wrote to replace all spaces in filenames with underscores.
rename.py:
import os
i = 0
path = "E:/sample_path/"
for filename in os.listdir(path):
src = path + filename
dst = path + filename.replace(" ", "_")
os.rename(src, dst)
i += 1
print(str(i) + " files processed.")
Upon doing some prints in Python, I can see that all the files in the directory are being renamed correctly but it just wasn't correctly updating when I actually viewed the directory. Both in the file browser and in using the dir command. Same with creating new files in Python, they exist in the eyes of Python, but they are nowhere to be found in Windows, even with hidden files being visible and all.
Now for the interesting part: This script works if I open the python editor in cmd and import it. So I know it's all correct, no syntax errors or anything - it's just a strange error occurring with Python.
For example, if I go into command prompt and type python rename.py it won't return any errors and will even output the correct results - x files processed. but it will not actually modify any "real" files.
But if I go into command prompt and type python to bring up the cmd editor, then type import rename it gives the correct output and updates all the files correctly. So for the time being this workaround helps, but it's a very strange issue and I have yet to see anyone else encounter it. It's almost like Python creates a temporary duplicate of the filesystem and is not completing it's sync back to Windows.
I've tried reinstalling Python several times, both x64 and x86 verisons and nothing has fixed it so far.
EDIT: Here's a simplified example illustrating my issue.
write.py:
f = open("newfile.txt", "w+")
f.write("hello new file")
f.close()
read.py:
f = open("newfile.txt", "r")
for l in f.readlines():
print(l)
If I run write.py, no errors are returned. But also no file named newfile.txt is visible in my current working directory. However, if I run read.py it prints hello new file. So clearly both of these are accessing the same invisible file somewhere.
I'm trying to write a sublime text build to execute an indesign jsx script strait from sublime text on Windows. For the Mac there's a build by Basil https://github.com/basiljs/basil.js/tree/master/extras/Sublime%20Text that consists of a build and an osascript.
The build is:
// copy this file to ~/Library/Application Support/Sublime Text 2/Packages/User
{
"cmd": ["osascript", "$packages/Basiljs/run_idscript_6.0.scpt", "$file"]
}
The osascript is:
--usage:
--osascript run.scpt myscript.jsx
on run argv
set aScriptPath to "#include \"" & item 1 of argv & "\""
tell application "Adobe InDesign CS6"
do script aScriptPath language javascript
end tell
end run
I would like to do this with For Windows for my build I have done
{
"cmd": ["wscript", "$packages/creative-scripts/run_indesign.vbs", "$file"]
}
and for my wscript I have done
myScript = Wscript.Arguments.Item(0)
Set myInDesign = CreateObject("InDesign.Application")
MsgBox myScript ' just to check the path
Set myFileSystemObject = CreateObject("Scripting.FileSystemObject")
Set myFile = myFileSystemObject.GetFile(myScript)
myInDesign.DoScript myFile, 1246973031
I was getting the following error message
Error: Object required: 'idScriptLanguage'
Code: 800A01A8
I have now edited the script putting in the change as per Vlad's answer and it work very well now.
Trevor
Replacing the idScriptLanguage.idJavascript with it's actual value (1246973031) will solve the problem.
I have come up with a solution with this sublime build :-)
{
// for script to run must have #target "InDesign-7.0" "InDesign" Ietc. in it :-( otherwise the script will just open in the estk
"cmd": ["C:\\Program Files (x86)\\Adobe\\Adobe ExtendScript Toolkit CC\\ExtendScript Toolkit.exe", "-run", "$file"]
}
Above is for a 64 bit system just remove the " (x86)" for a 32 bit one
Take note of the need for the #target
It will come up with a standard warning "Do you about to run .... Do you wish to run the script?"
So one needs to press y space or enter. Not too big a deal, but to suppress this one can put the script into the "Adobe Scripts" folder in Document then the warning won't come up.
See https://forums.adobe.com/message/4689581 and http://jfli04.blogspot.co.il/2011/08/how-to-run-js-in-estk-with-command-line.htm
This is my function to remove the directory after uninstalling.
Basically, in my .ism file, there are 2 .rul files(setup.rul and VerGetFileProperty.rul). I have added some code to clean the directory in setup.rul. I build, and one setup.exe is formed. While I run setup.exe, it will ask me to select the db, if I select a db, its says the db server is not found. But if I run the original setup, it will auto detect db server and install. How is the setup.exe getting created? I haven't made any changes on searching for db server part. I have just created a function to remove the directory while uninstalling.
function fnClean()
NUMBER nrv;
begin
if (ExistsDir (INSTALLDIR ^ "XYZ Dir") = EXISTS) then
SetDialogTitle(DLG_ASK_YESNO,"Delete Logs");
nrv = AskYesNo( "Do you want to delete all log files now? Say No if you prefer delete them later manually.", YES );
if ( nrv ) then
nrv = DeleteDir (INSTALLDIR ^ "XYZ Dir", ALLCONTENTS);
DeleteDir (INSTALLDIR, ALLCONTENTS);
endif;
else
DeleteDir (INSTALLDIR, ALLCONTENTS);
endif;
end;
I assume your installer either calling some exe that is generating the log files, or the log files are generated by using whatever application you are installing.
If you are using an MSI(Windows Installer) based project, you can add the files to the RemoveFile table. You'll want to use a InstallMode of 2 (remove on uninstall)
editing to expand answer
cmd_line = "cmd /c """ & objNamedArgs.Item("SQLCMD") & """ " & objNamedArgs.Item("CONNECT") & _" -i " & sql_file & " > " & log_file & " 2>&1"
-i "sqlfile" is an argument to the sqlcmd program. -i means "input" and the sqlfile will be whatever is being specified, usually a .sql script.
logfile means: redirect output of whatever command (in this case, sqlcmd) into the file specified by logfile.
The 2>&1 is already answered here.
So, that's it. How can I write to a text file using AppleScript?
I've tried googling around, but answers seem to be years old and I'm not really sure what should be the preferred idiom this days.
on write_to_file(this_data, target_file, append_data) -- (string, file path as string, boolean)
try
set the target_file to the target_file as text
set the open_target_file to ¬
open for access file target_file with write permission
if append_data is false then ¬
set eof of the open_target_file to 0
write this_data to the open_target_file starting at eof
close access the open_target_file
return true
on error
try
close access file target_file
end try
return false
end try
end write_to_file
Interfacing with it can be cleaned up with the following...
my WriteLog("Once upon a time in Silicon Valley...")
on WriteLog(the_text)
set this_story to the_text
set this_file to (((path to desktop folder) as text) & "MY STORY")
my write_to_file(this_story, this_file, true)
end WriteLog
A short version in pure AppleScript:
set myFile to open for access (choose file name) with write permission
write "hello world" to myFile
close access myFile
It seems there is no native one command solution. Instead you have to open and later close the file.
#JuanANavarro.
When using the shell you should use quoted form of for the TEXT and the file path.
This will help stop errors with spaces in file names and characters like apostrophes in the text for example.
set someText to "I've also learned that a quick hack, if one only wants to spit a bit of text to a file, is to use the shell."
set textFile to "/Users/USERNAME/Desktop/foo.txt"
do shell script "echo " & quoted form of someText & " > " & quoted form of textFile
The above script works fine.
If I did not have & quoted form of someText
but instead I had & someText I would get the following error.
error "sh: -c: line 0: unexpected EOF while looking for matching `''
sh: -c: line 1: syntax error: unexpected end of file" number 2
The apostrophes in "I've" is seen as part of the command.
If I had
set textFile to "/Users/USERNAME/Desktop/some foo.txt" as my file path ( note the space.) And did not have & quoted form of textFile but instead I had & textFile
Then when the file was written out it would write to a file named "some" and not "some foo.txt"
I've also learned that a quick hack, if one only wants to spit a bit of text to a file, is to use the shell.
do shell script "echo TEXT > some_file.txt"
For me running do shell script was too slow on a PowerBook G4 when executed in a loop 300000 times ;), but of course that's quicker to write which sometimes makes sense. You would also want to escape shell characters like this:
do shell script "echo " & quoted form of foobar & " >> some_file.txt"
and for aesthetic reasons I would use
tell me to do shell script "#..."
but I haven't verified yet (what I believe) that if "do shell script" is in a block of "tell Finder" for example it is Finder process that creates a subshell. With "tell me to do shell script" at least Script Editor log looks better for me. ;)
I'm using the following winrar command line to create zip archives:
rar.exe a -df -ep -ag[yyyyMMddhhmmss] -ms[txt] C:\MyZipFile.zip C:\tmp\MyFiles*.txt
The archives created are in RAR format instead of ZIP. Is there a way to create regular ZIP and not RAR archives?
Make certain you are using WinRAR.exe and not Rar.exe.
If you are using the command line to do this make sure you type:
winrar a -afzip c:\test.zip c:\test.csv
not:
a -afzip c:\test.zip c:\test.csv
It works for me. I also got it to work in SSIS.
WinRAR has a detailed description of its command line syntax in its help files (WinRAR Help), chapter "Command line syntax".
All the commands such as "a" (add to an archive), "d" (delete from an archive), "e" (extract from an archive ignoring paths) and switches such as "-af" (specify whether to create a rar or a zip file), "-ad" (append archive name to destination path) or "-p" (encrypt the archive using password protection) are listed there.
There are quite a lot of options. I recommend reading the command line syntax rules when working with WinRAR via command lines.
In order to trigger WinRAR zip-packaging from within a MS Access database application, I use in the VBA code for example
Shell c:\Programme\WinRAR\winrar.exe a -afzip -p <AnyPasswordYouLike> "e:\MyStuff\TargetFolder\Output.zip" "e:\MyStuff\SourceFolder\Input.docx"
Of course, the file paths and names are ususally entered via variables, e.g. like
Dim strWinrarCommandline As String
'... and the other variables as well declared in advance, of course...
strWinrarCommandline = strWinrarPathAndSwitches & "-p" & strPassword & " " & Chr(34) & strOutputFullName & Chr(34) & " " & Chr(34) & strInputFullName & Chr(34)
'And then call Winrar simply by:
Shell strWinrarCommandline
So rar.exe is currently unable to create zip files by itself only by calling in the Windows version it is possible.