Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com From: "Dave Korn" To: Subject: [APPS] ping python maintainer (and others) - Launching cygwin apps from cmd.exe vs. softlinks in /bin Date: Mon, 20 Sep 2004 16:09:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: X-OriginalArrivalTime: 20 Sep 2004 15:09:50.0640 (UTC) FILETIME=[E024DB00:01C49F23] I thought this topic ought to be on the -apps list, but the description does say... "It is not (with one exception) for bug reports, "it would be nice", or "how do I" type of musings." ... so I'm mentioning this here instead. It's quite a common idiom in cygwin packages (based on longstanding unix tradition) to have an executable that has the version number appended to it, and then use a soft-link to provide an unadorned executable, e.g.: dk AT mace /bin> ls -la python* lrwxrwxrwx 1 dk Users 13 Jan 5 2004 python.exe -> python2.3.exe -rwxr-x---+ 1 dk Users 4608 Dec 30 2003 python2.3.exe Now, in this particular case "python.exe" is a cygwin old-style softlink rather than a windoze .lnk-style shortcut. This means that it can't be invoked from cmd.exe; because a cygwin old-style softlink is basically a text file, cmd.exe notices that it has no PE/MZ header, but since it's got a .exe extension, cmd.exe thinks it has to be _some_ kind of executable, so it guesses the only thing left - that it's an old 16-bit MSDOS .com-type executable - and invokes NTVDM, which loads the file into memory and starts happily executing ASCII bytes as opcodes (or at any rate, happily until it gpfaults within the first few bytes). It's a shame, because most normal cygwin apps can be invoked either from bash or from cmd. And it's a shame in particular for Python, because the cygwin and win32-native versions are very close to functionally interchangeable, and if it wasn't for this slight hiccup they could be used that way (with only a little attention to not using OS-specific features in your python scripts). Using a non-symbolic link works for me; "ln /bin/python2.3.exe /bin/cmd-invokable-python.exe" gets me something I can invoke from either DOS/cmd or bash/sh. Using a new-style symlink fails in several interesting ways: 1) Well, there's the .lnk extension to take into account, which is a minor nuisance because you can't invoke it with just 'python.exe'. 2) Also, "ln -s" sets utterly wrong ACLs on the link it creates, such that I have no "read and execute" permission. (I think this is a genuine bug, but I'll start a separate thread for it once I've confirmed that.) 3) So after I modify the ACLs, and invoke it by typing "shortcutname.exe.lnk" at a cmd.exe shell, something very bizarre happens: it forks off from the shell, and both cmd.exe and the python exe are running simultaneously, connected to the same stdin and fighting each other for chars from my command lines. [ Can I refer to this as "a terrible forking bug" without getting banned from the list? :-O ] Now, I know that using a hardlink has the effect on FAT filesystems of simply duplicating the file, and so this might not be a desirable or possible solution to adopt in the majority of cases. I'm not sure how compatible it would or wouldn't be with the cygwin packaging scheme, for starters. But the python executable is a special case, because it's tiny: 4608 bytes, because all the actual functionality is in a .dll, and the .exe simply has to load the .dll and call out to it. So in this particular case, (and any similar ones, such as zsh, perl, and conceivably even tclsh, although at 16kb the waste/redundancy starts to become more worth considering) it might be entirely reasonable to simply provide two identical duplicate .exes in the package, mightn't it? cheers, DaveK -- Can't think of a witty .sigline today.... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/