Mail Archives: cygwin/2007/05/01/10:58:24
On 01 May 2007 15:33, Christopher Faylor wrote:
> On Tue, May 01, 2007 at 03:15:52PM +0100, Dave Korn wrote:
>> On 01 May 2007 14:59, Charles Wilson wrote:
>>> Because python is a command interpreter,
>
>>> Similarly, sh.exe
>>
>> I think these are two very strong arguments in favour.
>
> python.exe isn't anything like the interactive shell
AFAIUI, that's not what "command interpreter" means. I though shells were a
subcategory of command interpreters. YMMV.
>> I note that we already (appear to?) do the same for perl.
>
> Ok. I agree that is an argument in favor since I don't recall many
> complaints about perl. It is a simple copy though, AFAICT. I've
> registered my objections now and I'll leave the decision to the maintainer.
Likewise.
>> (/me remembers back to the insane gyrations I had to go through a
>> couple of years ago when I had to setup makefiles for my clients who
>> wanted to invoke them from cmd.exe using --win32 and have them work on
>> systems that could have either cygwin python or active python or both
>> and they could come in any order in the path.... <shudder>)
>
> This isn't really relevant to the discussion
Yes, it was a humorous aside. I certainly wasn't suggesting trying to
accomodate such exotic corner cases, but it amuses me to describe them.
>since the cygwin version of
> make wouldn't have any problem with symlinks.
JFTR, --win32 meant that it was using cmd.exe to launch python rather than
bash (and there were redirects in the commands, implying that it had to take
the slow path), which meant no symlinks, which meant those annoying NTVDM
popups when it tries to execute ascii as opcodes.
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/
- Raw text -