Tobias Senz <[email protected]> wrote: >Hello! > >On 28.04.2012 16:47, Jeremy Nicoll - ml wget users wrote: >> a) For curl, I looked at the list of packages specified at: >> http://curl.haxx.se/download.html >> b) for wget, the binaries & dependencies zips described at >> http://gnuwin32.sourceforge.net/packages/wget.htm > >Any particular technical reason you're not just using Cygwin?
Ignorance of what it is. > In theory, if you don't like the installer you could just get the > particular packages with wget.exe and curl.exe inside and whatever > libraries they immedeately require. The problem is finding out what an installer does, before running it. Because of the way I've chosen to use Dropbox I /really/ prefer the simplest possible install done once on one machine, which makes the app available on them all. It simplifies the problem of having multiple machines to maintain. Until now all the CLI tools I've installed have either required no DLLs or have had just one that the author has provided themselves with their own support code in it, so typically oneoftheirapps.exe comes with theirsharedlib.dll, and there's been no problem putting those (and oneoftheirapps.ini, oneoftheirapps.chm etc) into one common folder. I've found quite a few apps that come with a choice of zip or setup, and surprisely often the zip version has very little in it. It becomes obvious that the setup version is mainly for people who don't know how to create shortcuts, quick launch area links etc... whereas I tend (if I use the installer) either to turn off these fripperies or have to go round the machine afterwards finding and deleting them. I also hate installers which generate no log of what they did. It's simpler just to copy stuff around and know what I did and why. > It'll tell you one by one when you start the .exe without the neccessary > .dlls present which ones it requires. There is a search function on > cygwin.com website to find files inside packages. The problems I've hit here and presumably because the utilities I'm installing come from a unix/linux background where there's a different philosophy about support libaries, which doesn't fit the Windows DLL concept very well. My own background is in MVS [now z/OS] systems programming, which of course has its own ways of solving this sort of problem. > If you don't fully know what problems that entails, probably better > install the normal way. -- Jeremy C B Nicoll - my opinions are my own.
