delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2003/01/24/19:02:25

Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <02d901c2c405$0511fa20$78d96f83@pomello>
From: "Max Bowsher" <maxb AT ukf DOT net>
To: <caelum AT debian DOT org>, <cygwin AT cygwin DOT com>
References: <000901c2c3fd$ae0ff9e0$0201a8c0 AT ISIS>
Subject: Re: idea for a new project, libntcmd
Date: Sat, 25 Jan 2003 00:02:15 -0000
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

Rafael Kitover wrote:
>>> 2) support cmd.exe builtins like del/copy/exists/etc, and execute
>>> dos batch files. Things like if and goto, because they're only
>>> useful in batch, would present little problem as well.
>>
>> Yuk! Why?
>
> Often when I go between cmd and zsh, I get my copy/cp del/rm mixed up.
> This would also apply to folks who have to use both the unix and
> windows command lines on a regular occasion.

Solution: Don't use cmd ;-)

No, seriously, wouldn't shell aliases and/or stub .exes or batch files give
you most of this functionality *right now*?

> Also to support simple
> Makefiles, batch files etc. in various packages.

I have to ask: Why try to coerce a makefile designed for a cmd.exe shell
into running with bash?

> Making aliases or shell functions would not work well, because those
> are not propagated to subprocesses.

Aliases, no, unless you put them in your shell's startup file. In bash at
least, you can 'export -f' functions.

>>> This would allow better interaction between the windows and cygwin
>>> worlds, and also be convenient for windows users new to unix.
>>
>> Really? Or would it simply delay them learning the knowledge to
>> function in
>> an environment that does not make specific allowances for them?
>
> Well, the goal would be for new cygwin users, who often have little
> knowledge of UNIX, to have more space to get comfortable in learning
> the environment.

Chris answered this perfectly.

Anyway, a compatibility package of shell scripts or stub exes ought to be
easy to acheive, and has the advantage of working with all shells.

>>> It should also allow for running windows makefiles
>>> as-is.
>>
>> This feels more like MSYS territory than Cygwin.
>
> This would be useful for MSYS, which is a fork of Cygwin too of
> course. We don't want MSYS to diverge too greatly, especially since
> Cygwin is a perfectly functional environment for building mingw
> programs.

Define "We" ;-)

>>> Thoughts? Is this interesting/crazy/impossible?
>>
>> Well, you're getting a biased opinion here - I hate cmd. But I think
>> this
>> has 2 flaws:
>>
>> 1) You want to make bash play nice with Windows paths - what about
>> all those
>> supplementary tools that makefiles often invoke?
>
> If a makefile uses visual studio or borland tools, we'd assume the
> user has those installed and in their paths. Perhaps some simple
> wrappers for some visual studio command line tools could also be made
> to use the cygwin equivalents.

But then why does this makefile want to run under Cygwin make and bash??


Max.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019