Sign in to follow this  
Followers 0
Willow

Pass a variable to DOS and unzip with 7zip

14 posts in this topic

I am attempting to pass a variable (user selects a zip file to unzip) to DOS so that 7zip can unzip the file. The problem is that 7zip errors out with "cannot find archive".

$message = "Select a file to unzip."

$var = FileOpenDialog($message, "c:\archives"& "\", "Archives (*.zip)", 1 + 4 )

If @error Then
    MsgBox(4096,"","No File(s) chosen")
Else
    

    Run(@ComSpec & " /k c:\daily\7z e -o" & $var)

EndIf

Can anyone help with this or suggest another method.

Thanks

Willow

Share this post


Link to post
Share on other sites



Might be a good Idea if the location contains spaces... and quotes are escaped by quotes... so it's

Run(@ComSpec & " /k c:\daily\7z e -o """ & $var & """")

or

Run(@ComSpec & ' /k c:\daily\7z e -o "' & $var & '"')

Share this post


Link to post
Share on other sites

Sorry guys, none of the suggestions are working. Any other options as I do not wish to resort to vbscript...

Willow

Share this post


Link to post
Share on other sites

Is the 7zip you're using the standalone version, if not, is 7z.dll in the same folder?

Just checking if your 7zip is working.

Also, does 7zip correctly process the multiselect return value of FileOpenDialog in its extract command?

I checked the help file and it returns "Directory|file1|file2|..."

Maybe disable the multiselect option for FileOpenDialog?

Share this post


Link to post
Share on other sites

Hi there...

Give this a try, maybe it'll be usefull.

#include <guiconstantsex.au3>

$def_browse_in = "C:\"
$def_browse_out = "C:\"


$gui = GUICreate("Select Archive", 270, 150)
GUICtrlCreateLabel("Choose Input File", 25, 10)
GUICtrlCreateLabel("Choose Output Location", 25, 55)
$Input = GUICtrlCreateInput("", 25, 25, 155, 20)
$Output = GUICtrlCreateInput("", 25, 70, 155, 20)
$Browse_In = GUICtrlCreateButton("Browse", 190, 25, 50, 20)
$Browse_Out = GUICtrlCreateButton("Browse", 190, 70, 50, 20)
$Execute = GUICtrlCreateButton("Execute", 135, 110, 60, 30)
$Exit = GUICtrlCreateButton("Exit", 200, 110, 60, 30)
GUISetState(@SW_SHOW)

While 1
    Switch GUIGetMsg()
        Case $GUI_EVENT_CLOSE
            Exit
        Case $Exit
            Exit
        Case $Browse_In
            $message_in = "Select a file to unzip"
            $aName = FileOpenDialog($message_in, $def_browse_in, "Archives (*.zip)")
            GUICtrlSetData($Input, $aName)
        Case $Browse_Out
            $message_out = "Select a destination"
            $dName = FileSelectFolder($message_out, "C:\", "", $def_browse_out)
            GUICtrlSetData($Output, $dName)
        Case $Execute
            Run(@ComSpec & " /k c:\daily\7z e -o " & $Input & " " & $Output)
    EndSwitch
WEnd

Share this post


Link to post
Share on other sites

5t0n3r:

I like this concept with the GUI, unfortunately when it runs, it errors out with the message: "error: incorrect command line". The DOS window is in the drive / folder where the zip file is located. In this case, d:\

I have also made sure that c:\daily is in the system path and that 7z.exe works independently of Autoit, meaning the same file can be unzipped from the command line.

Share this post


Link to post
Share on other sites

Willow, the function Run does nothing special. If it works in your Start > Run box, then it works in AutoIt. If it doesn't work in your Start > Run box, then it doesn't work in AutoIt.

Share this post


Link to post
Share on other sites

#10 ·  Posted (edited)

I think the problem is more that you allow multi-select in the dialog:

$message = "Select a file to unzip."
$var = FileOpenDialog($message, "c:\archives" & "\", "Archives (*.zip)", 1 + 4)
If @error Then
    MsgBox(4096, "", "No File(s) chosen")
Else
    ;MsgBox(4096, "", $var)
    $avar = StringSplit($var,"|")
    if $avar[0] > 1 Then
        for $i = 2 to $avar[0]
            ;MsgBox(4096, "", $avar[1] & $avar[$i])
            Run(@ComSpec & ' /c "c:\daily\7z.exe" e -o "' & $avar[1] & $avar[$i] & '"')
        Next
    Else
        ;MsgBox(4096, "", $avar[1])
        Run(@ComSpec & ' /c "c:\daily\7z.exe" e -o "' & $avar[1] & '"')
    endif
EndIf
Edited by KaFu

Share this post


Link to post
Share on other sites

#11 ·  Posted (edited)

Thanks for all the help guys, the problem turned out to be the syntax for 7z.

Here is the new and working code. The difference mainly is that the 7z -o switch needs to have a path associated with it. The -i! switch will only extract a single file which is all that is needed. The -y switch will always overwrite the daydata.txt which is allowable in this case.

$message = "Select a file to unzip."

$var = FileOpenDialog($message, "c:\archives" & "\", "Archives (*.zip)", 1 + 4 )

If @error Then
    MsgBox(4096,"","No File(s) chosen")
Else
    $var = StringReplace($var, "|", @CRLF)
    

    Run(@ComSpec & " /c c:\daily\7z  e -i!daydata.txt -y -oc:\daily "& $var)
Edited by Willow

Share this post


Link to post
Share on other sites

#12 ·  Posted (edited)

Hehe, interesting how people get confused and call the command prompt "DOS"

Oh poor old DOS, what have they done to you ? :D

Edited by Inverted

Share this post


Link to post
Share on other sites

Well, the command prompt uses the same old DOS commands. Not exactly sure if its the actual DOS commands or a port or something.

Share this post


Link to post
Share on other sites

#14 ·  Posted (edited)

In addition to people calling it DOS, I don't understand why people insist on calling

Run(@ComSpec & " /c

When they are not calling an internal CMD commnd. If it's a separate EXE (like 7-Zip), YOU DON'T NEED TO CALL @ComSpec

Well, the command prompt uses the same old DOS commands. Not exactly sure if its the actual DOS commands or a port or something.

COMMAND.COM (called when running actual DOS programs) is the original 16 bit deal running in a virtual machine (ntvdm).

CMD.EXE, although it uses similar command names and syntax as DOS, is 100% "port" or recode to the 32 bit NT kernel.

And in the case of this thread, there's no reason command prompt or "DOS"'s COMMAND should be called at all.. Just directly call the console based application.

Edited by TurionAltec

Share this post


Link to post
Share on other sites

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 account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0