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 Date: Mon, 20 Sep 2004 12:06:41 -0400 (EDT) From: Igor Pechtchanski Reply-To: cygwin AT cygwin DOT com To: Dave Korn cc: cygwin AT cygwin DOT com Subject: Re: [APPS] ping python maintainer (and others) - Launching cygwin apps from cmd.exe vs. softlinks in /bin In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.39 On Mon, 20 Sep 2004, Dave Korn wrote: > 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. Alternatively, you could Google for "vi.bat site:cygwin.com" and apply the same technique to python. > 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? Some more randomly-ordered points: a) the cluster size can be as large as 32k, which means that even a symlink takes up that much space. b) FWIW, if the symlink is set up in a postinstall script instead of the tarball, it'll be a new style symlink. c) the code in spawn.cc currently treats any file with a .exe extension specially, and passes it on to CreateProcess without looking into it any more than that. It could, technically, check whether the file is an old-style symlink, and do the right thing in that case -- as always, . HTH, Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_ pechtcha AT cs DOT nyu DOT edu ZZZzz /,`.-'`' -. ;-;;,_ igor AT watson DOT ibm DOT com |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "Happiness lies in being privileged to work hard for long hours in doing whatever you think is worth doing." -- Dr. Jubal Harshaw -- 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/