[Filzip Command Line Options
Virginie Fayad
Yes, it's well documented how to get the name of your application's exe file and see if it is running. When the application in question is a java application, the running exe will always be java.exe, and so this method falls flat on its face since there could be any number of java applications currently running, all launched with java.exe.Each one will differ in the commandline parameters passed, including the main class name.
Edited to add: While the window class is a required parameter, the empty string (any window class) is a valid window class parameter. Here's a complete FindWindow function from one of my NSIS installers:
i have a folder structure in this pattern. I've just shown two sub directories and 2 files in each but generally I have n number of subdirectories at a single level and single level of files (but can be n number of files)under them.
First, the batch (%%variable) and Windows CMD (%variable) uses different variable naming.Second, i dont figure out how do you use zip from CMD. This is from Linux users i think. Use built-in zip manipulation is not like easy on Win, and even harder with batch scripting.
Explanation:for /d ... that matches any folder inside. Only folder ignoring files. (use for /f to filesmatch)for /d %d in ... the %d tells cmd wich name do you wanna assign to your variable. I put d to match widh d (directory meaning).for /d %d in (*) ... Very important. That suposses that I CD to desired folder, or run from. (*) this will mean all on THIS dir, because we use /d the files are not processed so no need to set a pattern, even if you can get only some folders if you need. You can use absolute paths. Not sure about issues with relatives from batch.for /d %d in (*) do zip -r ... Do ZIP is obvious. (exec zip itself and see the help display to use your custom rules). r- is for recursive, so anyting will be added.for /d %d in (*) do zip -r %d %d The first %d is the zip name. You can try with myzip.zip, but if will fail because if you have 2 or more folders the second cannot gave the name of the first and will not try to overwrite without more params. So, we pass %d to both, wich is the current for iteration folder name zipped into a file with the folder name. Is not neccesary to append ".zip" to name.
I like PodTech.io's answer to achieve this without additional tools. For me, it did not run out of the box, so I had to slightly change it. I am not sure if the command wScript.Sleep 12000 (12 sec delay) in the original script is required or not, so I kept it.
Late to the party, but I wanted to add on to another proposed answer that recommended tar, but the output zip archive could not be read because the format was wrong. In order to resolve this, one must include the argument --archive zip. Here is an example:
Also, if you are using tar from the command line then you can use argument -a instead of --format, and tar will automatically use the correct format based on the output file's extension ("zip" in this case). Unfortunately, -a is not available when using tar in a batch script.
The step I'm stuck on is, finding the right way to get at an unzip method
from within a git script. (see
-there-an-opposite-command-to-git-archive-for-importing-zip-files)I'm trying this on an XP netbook.
I have the full msysgit, with source code, which includes 7-zip, and I have
7-zip and Filzip on the XP side of the platform.I can't seem to either get a $ cmd dos_script.bat command line to execute
a dos batch file, (I can't locate a manual page for the passing of
parameters from the bash to the cmd command, so I'm not sure it even sees
the batch file name I've given it)Also I'm not sure how, or if, I can get the C:\msysgit\share\7-Zip code to
be usable from the bash - I'm pretty sure that this directory is the Windows
version used for packaging the MSysGit, rather than being an available
utility for the bash - but I thought I'd better mention it.Can anyone suggest how I can do the unzip (of a directory) step in the git
script from the available MSysGit installation code, without jumping into
some 'dependency hell' ;-)Philip
However, for a 'Git for Windows' basic user, how would they get the script
to run, given that it doesn't appear to have the unzip available to them. Or
is that a limitaion of the Git for Windows basic installation?Philip
I'm not sure what you call "basic installation" installation here. No
matter what features you (de-)select in the installer, you always get
all the files in your installation directory. Only some configuration
stuff changes.So here's what I think happened to you: At some point you installed
version 1.7.3.1 and chose to install the Windows Explorer "Git Bash"
context menu entries.Later, you installed version 1.7.6 in parallel (not updating the
existing version 1.7.3.1) but chose *not* to install the context menu
entries. This means these entries still launch version 1.7.3.1, while
the Start Menu entries were updated and launch version 1.7.6.My guess is that version 1.7.3.1 did not come with the unzip script yet,
but version 1.7.6 does. So the easiest way to fix this would be to
uninstall version 1.7.3.1 and reinstall 1.7.6 with the option to install
the Windows Explorer context menus checked.--
Sebastian Schuberth
I don't think that's it. I believe the difference is Git for Windows
vs msysGit. msysGit includes unzip, while Git for Windows does not.Basicly, Git for Windows is a Git (including a minimal runtime
environment), while msysGit is a fully blown msys-based development
environment.Stuffing all kinds of sometimes-useful-but-not-really-essential tools
into the Git for Windows distribution will end up bloating it, which
is the reason why non-essential tools aren't included.So the answer to the question would be that you had to download a
unzip tool from somewhere before the script can run. Just the same way
you'd have to for another git-unrelated tool.Alternatively, you could install msysGit rather than Git for Windows,
but it isn't quite as nicely packaged.
> Looking a bit more at the distribution, I'm not sure I completely
> agree with myself on this point: We already distribute gzip, gunzip,
> bzip and bunzip. Perhaps it would make sense to also include unzip in
> the distribution?
>
> Thoughts?
Looks good to me. As we're a Windows distribution of Git, we should
include an (un)zip tool for the zip format that is most common on
Windows.Please commit to devel.--
Sebastian Schuberth
> On Wed, Sep 28, 2011 at 12:20 PM, Erik Faye-Lund wrote:
> > Stuffing all kinds of sometimes-useful-but-not-really-essential tools
> > into the Git for Windows distribution will end up bloating it, which
> > is the reason why non-essential tools aren't included.
>
> Looking a bit more at the distribution, I'm not sure I completely
> agree with myself on this point: We already distribute gzip, gunzip,
> bzip and bunzip. Perhaps it would make sense to also include unzip in
> the distribution?
>
> Thoughts?
For the other compression mechanisms, both the compressor and
uncompressor are shipped (gzip/gunzip and bzip2/bunzip2), so why ship
only an uncompressor for ZIP? Shipping both zip and unzip, rather than
only unzip, seems like a good idea.-- ES
For the particular workflow I had in mind, the zip side is done on the
Windows side of the fence, e.g. by compressing a project folder.This way (being able to unzip such project zip files and commit them into
git) allows the easy 'capture' of such zip storage based workflows that
happen at a low level (It's a method my project uses for day to day
storage).That's not to say that having the matching pair wouldn't be the expected
capability. Having the zip/unzip capablity directly available on the
'linux/bash' side of the fence makes it a complete solution, and allows
simple scripts.Philip
>
> Stuffing all kinds of sometimes-useful-but-not-really-essential tools
> into the Git for Windows distribution will end up bloating it, which
> is the reason why non-essential tools aren't included.
>
> So the answer to the question would be that you had to download a
> unzip tool from somewhere before the script can run. Just the same way
> you'd have to for another git-unrelated tool.
One of my 'lack of understandings' is about whether Msysgit could even run
regular windows programmes, such as WinZip (for example) from the bash
prompt -- that is, I had assumed that Windows programes were separate from
the Linux programmes, on the basis that the two sorts of programmes hooked
into the OS by different routes. Is this the case? or had I misled myself
and I can run say the 7-zip.exe directly from the bash prompt, even though I
have the windows version installed?
It can. Think of Msysgit as Windows programs that emulate Linux
behavior. Msysgit executables are regular Windows executables, just
like 7-zip.exe. Msysgit is *not* something like colinux, or Wine the
other way around, or even a virtual machine. It's just a Cygwin fork.
You can. In fact, the files in C:\msysgit\share\7-Zip are the regular
Windows versions, not a special Mingw-compiled version of 7-Zip.But as the Mingw executables emulate Linux, you have to take care with
the path mangling when passing files to Windows executables from the
Mingw Bash. That is, basically use forward instead of backward
slashes.--
Sebastian Schuberth
Early versions of FORFILES were supplied in the NT resource kit and used Unix style '-' parameters,(still supported for backwards compatibility) also the /D option accepted dates only in DDMMYYYYHHMN format.
Recent versions of FORFILES contain a bug, in processing command line arguments: running a /c command that contains an argument such as FORFILES /C "PING -a" will fail. The expected convention is that argv[0] will contain the program name, but FORFILES instead passes the first argument as argv[0]. Old versions e.g. FORFILES version 1.46 (24th March 2006) do not suffer from this bug.
795a8134c1