Question : force PowerShell to wait for cmdlet execution to end

Before I forget, credit where credit is due for as far as I've gotten: the following code is adapted from http://mow001.blogspot.com/2006/01/msh-out-zip-function.html.

Okay, here's my challenge: I would like to create a function that will accept a series of filenames (full paths) as arguments, and zip them ONE AT A TIME to the same folder and filename, but with ".zip" appended.

So [PS> zipfiles "g:\test\file1.txt" "g:\test\file2.txt"] will generate [g:\test\file1.txt.zip] and [g:\test\file2.txt.zip].

Here's something that works:

function zipFiles {
  for( $i = 0; $i -lt $args.length; $i++ ){
    # Define the source and destination file paths.
    $FileName = $args[$i]
    $ZipName = $FileName + ".zip"
   
    # Create code to zip the file.
    $cmds = ' $' + "ZipFile = (new-object -com shell.application).NameSpace('$ZipName');"
    $cmds += ' $' + "ZipFile.CopyHere('$FileName');"

    # Execute the code in a separate process and wait for it to exit, so we won't overload the machine.
    write-host "Zipping '$FileName...'"
    set-content $ZipName("PK" + [char]5 + [char]6 + ("$([char]0)" * 18))
    [diagnostics.process]::start("powershell", "-noexit -command & {$cmds}").waitforexit()
    write-host "...done."
  }
}

...BUT the "-noexit" is highly undesirable, since there are a lot of files to be zipped and I would like to be able to start it and walk away, rather than sit there and close the secondary window for each file.

The problem is, if I remove the "-noexit" it doesn't work.  The secondary window doesn't wait for CopyHere() to finish; it just opens and closes in a flash without doing anything.

The ideal solution would be something that tells PowerShell to wait for a given cmdlet to finish executing before going on to the next such that the secondary window wouldn't even be necessary.

Hopefully the solution is obvious to the Shellistas here, but I'm new and confused.

Answer : force PowerShell to wait for cmdlet execution to end

The code is using the shell.application COM object, which simply invokes the shell to perform the action for you, it runs asynchronously and doesn't have an option to run synchronously, so you're out of luck. It will also pop any errors up on screen. I am disappointed at windows lack of decent support for ZIP, I haven't found any way to zip files progmatically reliably (i.e. you can wait and get an exit code or whatever to determine success).

I'd suggest obtaining a 3rd party app that supports being invoked from the command line (like 7zip or winzip) and calling them to do the zipping for it, it will be more reliable.