I'm attempting to zip a folder containing subfolders and items, using Windows shell CopyHere command:
https://msdn.microsoft.com/en-us/library/windows/desktop/bb787866(v=vs.85).aspx
https://msdn.microsoft.com/en-us/library/windows/desktop/ms723207(v=vs.85).aspx
Update: Note, prefer a native solution-- this is for a distributed Excel VBA tool, so bundling 3rd-party files is not ideal. And, need synchronous compression.
I can easily add a folder and its contents to the zip:
oShell.Namespace(sZipPath).CopyHere "C:\My Folder"
So we know CopyHere can process multiple objects inside a folder in 1 statement.
The problem is, the above command puts the containing-folder at the root of the zip, and it's contents inside of it. But, i don't want the containing folder-- just its contents.
The doc mentions a wildcard (option 128), but when i use a wildcard, i get an error:
oShell.Namespace(sZipPath).CopyHere "C:\My Folder\*"
The file name you specified is not valid or too long.
Perhaps there's a way to use my 1st command above, and then move the items in the zip to the root of the zip?
It would be acceptable to loop through each item in the source folder, adding one at a time to the zip. But, because CopyHere is asynchronous, each subsequent CopyHere fails if the previous CopyHere is not finished. None of the fixes work for this issue:
Comparing number of items in source-folder and destination-zip fail, because if the zip contains a folder, that counts as only 1 item (the items it contains are not counted. https://stackoverflow.com/a/16603850/209942
Waiting a while between each item works, but a timer is unacceptable: it's arbitrary. I cannot guess in advance the size or compress-time of each object.
Checking to see if the zip is locked for access failed for me. If I block my loop until the file is not locked, I still get a file-access error. https://stackoverflow.com/a/6666663/209942
Function FileIsOpen(sPathname As String) As Boolean ' true if file is open
Dim lFileNum As Long
lFileNum = FreeFile
Dim lErr As Long
On Error Resume Next
Open sPathname For Binary Access Read Write Lock Read Write As #lFileNum
lErr = Err
Close #lFileNum
On Error GoTo 0
FileIsOpen = (lErr <> 0)
End Function
Update: VBA can call shell commands synchronously (instead of creating a shell32.shell object in VBA), so if CopyHere works on command-line or PowerShell, that could be the solution. Investigating...
Automating Shell objects really isn't a viable approach as you have already discovered. The Explorer Shell doesn't really expose this capability in any other manner though, at least not before Windows Vista and then not in any fashion easily used from VB6 programs or VBA macros.
Your best bet is a 3rd party ActiveX library, but be careful about 64-bit VBA hosts where you'll need a 64-bit version of such a library.
Another option is to acquire a later copy of the zlibwapi.dll and use some VB6 wrapper code with it. This is also a 32-bit solution.
That's what Zipper & ZipWriter, Zipping from VB programs does. Considering your requirements (which for some reason includes a fear of the Timer control) you could use the synchronous ZipperSync Class. See post #4 there. That code includes a simple AddFolderToZipperSync bundling up the logic to add a folder instead of just a single file.
The downside of the synchronous class is that a large archival operation freezes your program UI until it completes. If you don't want that use the Zipper UserControl instead.
You could also take the ideas from that to write your own wrapper class.
Solution:
Windows contains another native compression utility: CreateFromDirectory at a PowerShell prompt.
https://msdn.microsoft.com/en-us/library/system.io.compression.zipfile.createfromdirectory(v=vs.110).aspx
https://blogs.technet.microsoft.com/heyscriptingguy/2015/03/09/use-powershell-to-create-zip-archive-of-folder/
This requires .Net 4.0 or later:
> Add-Type -AssemblyName System.IO.Compression
> $src = "C:\Users\v1453957\documents\Experiment\rezip\aFolder"
> $zip="C:\Users\v1453957\Documents\Experiment\rezip\my.zip"
> [io.compression.zipfile]::CreateFromDirectory($src, $zip)
Note, you may have to provide the complete pathnames-- active directory was not implicit on my machine.
The above compression is synchronous at the PowerShell prompt, as the OP requests.
Next step is executing synchronously from VBA. The solution there is the .Run method in Windows Script Host Object Model. In VBA, set a reference to that, and do the following, setting the 3rd parameter of .Run command, bWaitOnReturn to True:
Function SynchronousShell(sCmd As String)As Long
Dim oWSH As New IWshRuntimeLibrary.WshShell
ShellSynch = oWSH.Run(sCmd, 3, True)
Set oWSH = Nothing
End Function
Now call SynchronousShell, and pass it the entire compression script.
I believe the only way for this process to work is if CreateFromDirectory is executed in the same session as Add-Type.
So, we must pass the whole thing as 1 string. That is, load all 4 commands into a single sCmd variable, so that Add-Type remains associated with the subsequent CreateFromDirectory. In PowerShell syntax, you can separate them with ;
https://thomas.vanhoutte.be/miniblog/execute-multiple-powershell-commands-on-one-line/
Also, you'll want to use single-quotes instead of double-quotes, else double quotes around the strings are removed when the daisy-chained commands are passed to powershell.exe
https://stackoverflow.com/a/39801732/209942
sCmd = "ps4 Add-Type -AssemblyName System.IO.Compression; $src = 'C:\Users\v1453957\documents\Experiment\rezip\aFolder'; $zip='C:\Users\v1453957\Documents\Experiment\rezip\my.zip'; [io.compression.zipfile]::CreateFromDirectory($src, $zip)"
Solved. The above constitutes the complete solution.
Extra info: Additional comments below are for special circumstances:
Multi-version .Net environments
If a .NET < 4.0 is the active environment on your OS, then System.IO.Compression does not exist-- the Add-Type command will fail. But if your machine has the .NET 4 assemblies available, you can still do this:
Create a batch file which runs PowerShell with .Net 4. See https://stackoverflow.com/a/31279372
In your Add-Type command above, use the exact path to the .Net 4 Compression assembly. On my Win Server 2008:
Add-Type -Path "C:\Windows\Microsoft.NET\assembly\GAC_MSIL\System.IO.Compression.FileSystem\v4.0_4.0.0.0__b77a5c561934e089\System.IO.Compression.FileSystem.dll"
Portability
Turns out, on my machine, I can copy the compression dll to any folder, and make calls to the copy and it works:
Add-Type -Path "C:\MyFunnyFolder\System.IO.Compression.FileSystem.dll"
I don't know what's required to ensure this works-- it might require the full .Net 4.0 or 2.0 files to be located in their expected directories. I assume the dll makes calls to other .Net assemblies. Maybe we just got lucky with this one :)
Character Limit
Depending on the depth of our paths and filenames, character-count may be a concern. PowerShell may have a 260-character limit (not sure).
https://support.microsoft.com/en-us/kb/830473
https://social.technet.microsoft.com/Forums/windowsserver/en-US/f895d766-5ffb-483f-97bc-19ac446da9f8/powershell-command-size-limit?forum=winserverpowershell
Since .Run goes through the Windows shell, you also have to worry about that character limit, but at 8k+, it's a bit roomier:
https://blogs.msdn.microsoft.com/oldnewthing/20031210-00/?p=41553
https://stackoverflow.com/a/3205048/209942
Site below offers a 24k+ character method, but i've not studied it yet:
http://itproctology.blogspot.com/2013/06/handling-freakishly-long-strings-from.html
At minimum, since we can put the dll wherever we like, we can put it in a folder near C: root-- keeping our character-count down.
Update: This post shows how we can put the whole thing in a script-file, and call it with ps4.cmd. This may become my preferred answer:
.\ps4.cmd GC .\zipper.ps1 | IEX
-- depending on answer here.
CopyHere:
Re the question: can CopyHere command execute on command-line?
CopyHere can be executed directly at PowerShell prompt (code below). However, even in powershell it's asynchronous-- control returns to PowerShell prompt before the process is finished. Therefore, no solution for the OP. Here's how it's done:
> $shellapp=new-object -com shell.application
> $zippath="test.zip"
> $zipobj=$shellapp.namespace((Get-Location).Path + "\$zippath")
> $srcpath="src"
> $srcobj=$shellapp.namespace((Get-Location).Path + "\$srcpath")
> $zipobj.Copyhere($srcobj.items())
Related
To run a CUDA C program we build the program and then run the binary file created from the command line as
/.prgm_bin_file
If for example the program needs some input files like for programs to image processing, I want to supply the data files or the input files at the time of compilation.
How can I do that. How the above command can be edited to give the required files.
Thanks in advance.
If your program opens data files to use for input, it's using some file I/O API to do so. For example, one possible method is to use fopen.
Just to use it as an example, if you are using fopen, it expects a filename (a character string) passed as the first parameter.
Many programs will take this filename from a the command line used to invoke the program. But there's nothing that would prevent you from hard-coding the filename:
fp=fopen("mydata", "r");
In that case, the program would always attempt to open the file mydata
But if your program is already designed to use the filename as a command line parameter, it's not clear that this is any more useful than just invoking your program that way:
./prgm_bin_file mydata
The Visual Studio (2010) gui provides options for specifying second command variable file for target. I however cant find this option for the command line implementation - vsdbcmd.exe.
Running vsdbcmd deploy for dbschema to dbschema with only source model command variables given results that objects that implement the variables are treated as having changes. Resulting in incorrect(improper) update script.
The command i use currently:
vsdbcmd.exe /a:deploy /dd:- /dsp:sql /model:Source.dbschema /targetmodelfile:Target.dbschema /p:SqlCommandVariablesFile=Database.sqlcmdvars /manifest:Database.deploymanifest /DeploymentScriptFile:UpdateScript.sql /p:TargetDatabase="DatabaseName"
What im looking for is the /p:TargetSqlCommandVariablesFile, if such thing exists ...
The result script is the same as running so GUI compare without specifying the sqlcmd vars for target
I found what looks like full documentation for VSDBCMD.EXE at this link.
I think you may be looking for something like:
/p:SqlCommandVariablesFile=Filepath
In the end i found no info on the possibility to do what I required - checked vsdbcmd libs with IL spy for hidden parameters - didn't find any.
Reached my goal by parsing the dbschema files for both target and current and parsing the cmd variable values directly into them - then doing the compare on modified dbschemas. This approach no longer allows to change sql cmd vars in resulting script (as the values are already baked into code), however this was deemed as acceptable loss.
Not the most beautiful solution but so far i have had no issues with it.
I have a program which performs a useful task. Now I want to produce the plain-text source code when the compiled executable runs, in addition to performing the original task. This is not a quine, but is probably related.
This capability would be useful in general, but my specific program is written in Fortran 90 and uses Mako Templates. When compiled it has access to the original source code files, but I want to be able to ensure that the source exists when a user runs the executable.
Is this possible to accomplish?
Here is an example of a simple Fortran 90 which does a simple task.
program exampl
implicit none
write(*,*) 'this is my useful output'
end program exampl
Can this program be modified such that it performs the same task (outputs a string when compiled) and outputs a Fortran 90 text file containing the source?
Thanks in advance
It's been so long since I have touched Fortran (and I've never dealt with Fortran 90) that I'm not certain but I see a basic approach that should work so long as the language supports string literals in the code.
Include your entire program inside itself in a block of literals. Obviously you can't include the literals within this, instead you need some sort of token that tells your program to include the block of literals.
Obviously this means you have two copies of the source, one inside the other. As this is ugly I wouldn't do it that way, but rather store your source with the include_me token in it and run it through a program that builds the nested files before you compile it. Note that this program will share a decent amount of code with the routine that recreates the code from the block of literals. If you're going to go this route I would also make the program spit out the source for this program so whoever is trying to modify the files doesn't need to deal with the two copies.
My original program (see question) is edited: add an include statement
Call this file "exampl.f90"
program exampl
implicit none
write(*,*) "this is my useful output"
open(unit=2,file="exampl_out.f90")
include "exampl_source.f90"
close(2)
end program exampl
Then another program (written in Python in this case) reads that source
import os
f=open('exampl.f90') # read in exampl.f90
g=open('exampl_source.f90','w') # and replace each line with write(*,*) 'line'
for line in f:
#print 'write(2,*) \''+line.rstrip()+'\'\n',
g.write('write(2,*) \''+line.rstrip()+'\'\n')
f.close
g.close
# then complie exampl.f90 (which includes exampl_source.f90)
os.system('gfortran exampl.f90')
os.system('/bin/rm exampl_source.f90')
Running this python script produces an executable. When the executable is run, it performs the original task AND prints the source code.
I'm trying to start the process Store.Client.UI.exe which is located at: "C:\Program Files\Intel\IntelAppStore\bin\Store.Client.UI.exe", or "C:\Program Files (x86)\Intel\IntelAppStore\bin\Store.Client.UI.exe" for 64bit like me, so I use the code:
If My.Settings.instpathtype = 86 Then
Process.Start("C:\Program Files\Intel\IntelAppStore\bin\Store.Client.UI.exe")
Else
Process.Start("C:\Program Files (x86)\Intel\IntelAppStore\bin\Store.Client.UI.exe")
End If
Where my.settings.instpathtype is whether the computer is 64 or 32 bit. But when I run it, it doesn't run Store.Client.UI.exe for some reason. When I go into Explorer and type "C:\Program Files (x86)\Intel\IntelAppStore\bin\Store.Client.UI.exe" it runs Store.Client.UI.exe. What's wrong?
From the code that you posted, I don't know where/how you're getting the value for instpathtype, or what type it is declared as.
But regardless, you really shouldn't be doing it this way. Hard-coding paths to the file system is a very bad practice if you want your code to "Just Work." What you posted above will not only break depending on the bitness of the OS, but also if the user has renamed or moved their Program Files folder. If my boot drive is E:, your code will fail on my computer as well.
Instead, you should be using the special system folders. That way, you don't even need to check whether you're running on a 32-bit or 64-bit operating system. The .NET Framework provides a really easy way of getting at these values with the Environment.GetFolderPath method, and specifying the type of folder you want to retrieve.
In this case, you want the 32-bit Program Files folder, regardless of the host OS's bitness, so you can use the ProgramFilesX86 value to retrieve the appropriate folder, like so:
Process.Start(System.Environment.GetFolderPath(Environment.SpecialFolder.ProgramFilesX86) & "\\Intel\\IntelAppStore\\bin\\Store.Client.UI.exe")
When you are encountering problems like this, debugging comes in. Try to display what My.Settings.instpathtype outputs, by a simple MessageBox or similar. If your testing machine is 32 bit, and if the output is different from 86, change it.
EDIT: So I guess you have a 64 bit machine? Try it the other way around. Swap the statements under If and Else, then put My.Settings.instpathtype's output at the condition.
EDIT: If there are no errors on the condition, then it might be because \ is being read as an escape character. You can fix it by adding another \ before it.
If My.Settings.instpathtype = 86 Then
Process.Start("C:\\Program Files\\Intel\\IntelAppStore\\bin\\Store.Client.UI.exe")
Else
Process.Start("C:\\Program Files (x86)\\Intel\\IntelAppStore\\bin\\Store.Client.UI.exe")
End If
It's possible the process is starting and then exiting immediately with an error. Use the return process from Process.Start and check some of its properties, such as proc.exitcode, proc.starttime, and proc.exittime.
dim proc as process
...
proc = Process.Start("C:\\Program Files\\Intel\\IntelAppStore\\bin\\Store.Client.UI.exe")
By default AutoCAD installs a text based file called acad2010.lsp at the set location below
Dim FILE_NAME As String = "C:\Program Files\AutoCAD 2010\Support\acad2010.lsp"
However it my be that the user/ administrator/ or third party has changed the location of this file. Is it possible to then locate it using the following
Dim FILE_NAME As String = "C:\*\acad2010.lsp"
In other words search the entire c:\ drive for file acad2010.lsp?
If this doesn't work can you please let me know what would?
You could search for it with an FSO. It's not going to be fast however you do it but this is the fastest way I can think of.
http://www.microbion.co.uk/developers/fso.htm should give you a rough idea of how it's done.
Your solution will not work. Is not possible to locate it using *. (BTW is possible in ms-builds scripts). The only way of doing it is:
1- Create a FindFile function (check for example
http://xlvba.3.forumer.com/index.php?showtopic=125)
2- Use it to locate the exact path of the file. (It could be really time
consuming)
3- From this point your code is the same...
Unfortunately, you can't use wildcards in a filepath. You have two options:
Prompt the user for the file location using the "Open File" dialog. The code to do this varies based on which Office product you are using. In Excel, you would use the Application.FindFile method (more info here).
Write your own function to search the filesystem for the file. Microsoft provides an example here.
If that file is used by internal functions of the application, the installer will have recorded a registry key for the file's location.
Open regedit.exe and search for the file name and path.
You can read a registry entry using this VBA one-liner:
CreateObject("WScript.Shell").RegRead(strRegPath)
You may need a terminating backslash on the key address, but that's a safe and simple registry access method. More details on the MSDN site:
https://msdn.microsoft.com/en-us/library/x05fawxd%28v=vs.84%29.aspx