Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

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) version
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 & zsh-isms...

The way cygwin only works by having the cygwin dll installed in the os and
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 disk space?

 Darel Henman

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 system.

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 other app. 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 your app...

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:

bkw@tv ~
$ objdump -p /usr/bin/zsh.exe | grep "DLL Name:" | sort -u | cut -d ' ' -f 3 |
sed -e '/KERNEL32.dll/d' | xargs -r which

bkw@tv ~

Brian K. White    brian@xxxxxxxxx    http://www.myspace.com/KEYofR
filePro  BBx    Linux  SCO  FreeBSD    #callahans  Satriani  Filk!

Messages sorted by: Reverse Date, Date, Thread, Author