Zsh Mailing List Archive
Messages sorted by:
Re: Lonely spacecowboy
----- Original Message -----
From: "djh" <henman@xxxxxxxxxxxxxx>
To: "Brian K. White" <brian@xxxxxxxxx>
Sent: Tuesday, March 27, 2007 9:47 PM
Subject: Re: Lonely spacecowboy
From: "Brian K. White" <brian@xxxxxxxxx>
Subject: Re: Lonely spacecowboy
It doesn't work in one enviroment I use zsh a lot in.
$P$Gecho this is a test |read aa bb cc
$P$Gecho $aa $bb $cc
This is latest freestanding (static binary not needing cygwin dll)
of zsh for windows that I have been able to locate, which is quite old,
I don't see any advantage of using an out-of-date version of zsh. But,
then again I use cygwin's gnu tool chain and development enviroment.
Consequently I built and use: zsh 4.3.2 (i686-pc-cygwin)
Cygwin enables me to build new versions and use the latest debugged code &
The way cygwin only works by having the cygwin dll installed in the os
can't be delivered in a self-contained package with the file makes cygwin
unsuitable for me.
I don't understand what you are trying to say here.
Seems like your confusing apples with oranges. Or are you low on hard
Why might one want a static binary?
Wow that's a large question.... here goes, sorry this will be long...
It's very simple. It's not that cygwin is necessarily so horrible in _most_
cases, it's just, why live with a dependancy if I don't have to? There are
times where that dependancy will be a problem.
A standalone binary for sh, awk etc.. is about a million times more
convenient than anything that requires an actual install process (cygwin,
mks, uwin, sfu, etc...)
Thats why this was created: http://unxutils.sourceforge.net/
Which I can tell you don't be fooled by the age and simplicity of the site,
a lot of people use those in a lot of situations, but all quietly and
without fanfare since it's just guys like me getting jobs done and/or
incorporating them into other projects. I think the zsh I'm using is a
little newer than the one in that kit btw. I found it somewhere else.
Why in the world should I accept having to download and install cygwin, or
live without if I can't do that, just to run a little data through awk when
I'm sitting at some random workstation, when it's possible to just fetch a
single binary of a few k that I can run right there in a temp dir no matter
how permission-less the workstation is?
But forget me, I can always figure out something for myself of course.
But I also have an app that end users access via terminal emulator, that
sometimes requires a little bit of agent software on the end users pc.
(mostly to do with scanning documents and uploading the images back to the
server, all controlled from the server).
Why in the world should I accept the headache of requiring all those end
users to install cygwin when it's possible to have a simple self-extracting
rar that creates a completely simple and self-contained new directory with a
few binaries and scripts?
I have _no_ headaches now. I have never had to diagnose and fix a broken
install or tell an end user that it doesn't support their version of windows
or that their windows is screwed up somehow or their install is too
non-standard and broke assumptions in my installer... nor did I have to
write and maintain a fancy installer with gobs of brains to try and handle
all the possible cases, and my download is tiny so it's fast and painless
for everyone, even dialup.
The reason I can't have this simple usage with cygwin binaries is because of
the way cygwin.dll insists on there being only one cygwin.dll for the
Often with windows binaries, it's no big deal to just include any required
dll's in the applications own directory and there they don't interfere with
anything else on the system even if there happens to be the same exact dlls
(or a different version of the same dlls) installed in Windows by some
It's almost like shipping static binaries in that your program can be
completely self contained, neither requiring the user to install a
prerequisite/dependancy, nor at any risk of interfering with anything else
that may or may not already be installed. You can include /program
files/foo.dll which your foo.exe will use, and not require foo.dll to be
installed in /windows/system32 , nor does it affect your foo.exe if there
actually IS a foo.dll in windows/system32 but not exactly the right one for
You can't do that with cygwin because cygwin requires that there only be one
cygwin.dll on the system.
Others may exist as files on the filesystem of course, but only one will be
used no matter what you try to do.
Not all cygwin-built binaries necessarily need to link in cygwin.dll. For
example I have commissioned some programmers to make some customizations to
PuTTY for me and they used cygwin to build, and the resulting binaries don't
need cygwin at all to run.
But the cygwin version of zsh does:
$ objdump -p /usr/bin/zsh.exe | grep "DLL Name:" | sort -u | cut -d ' ' -f 3
sed -e '/KERNEL32.dll/d' | xargs -r which
Brian K. White brian@xxxxxxxxx http://www.myspace.com/KEYofR
filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!
Messages sorted by: