This is the mail archive of the
mailing list for the Cygwin project.
Re: Make and javac compliler problem in bash
- To: Carl Thompson <cet at carlthompson dot net>, Woody Jin <wjin>
- Subject: Re: Make and javac compliler problem in bash
- From: Woody Jin <wjin at houston dot geoquest dot slb dot com>
- Date: Tue, 13 Jun 2000 09:43:48 -0700
- Cc: Cygwin List <cygwin at sourceware dot cygnus dot com>
- References: <firstname.lastname@example.org b.com><email@example.com><firstname.lastname@example.org b.com><email@example.com><firstname.lastname@example.org b.com><email@example.com>
At 06:38 PM 6/12/00 -0700, Carl Thompson wrote:
>Woody Jin wrote:
>> But a better way would be to resolve it within Cygwin. By default,
>> any application that is not in cygwin may be considered as Windows
>> native application (WNA). So, when you launch WNAs, cygwin can convert
>> the unix style directory to DOS style. After the conversion, pass the
>> converted MS-DOS style path to the WNA. I don't know why you think
>> that this is so impossible or so difficult. It is just putting the
>> gvim's functionality into Cygwin.
>I like this idea, but I think this functionality would more properly go into
>the BASH patches for Cygwin than in the Cygwin DLL itself. Since BASH (like
>all Unix shells) processes metacharacters in command lines itself before
>sending them to the application, this would be an natural fit for that
>section of the code. The only real tricky part would be figuring out how to
>allow BASH to figure out whether an application is Cygwin or native Windows
>(or is that easy?).
Carl, this is why I have said from the beginning that some registration
process is required. Obviously, we cannot know.
Even though it is quite rare to use slashes in the arguments
for Windows Native Applications (WNA), we cannot generalize that
every argument that contains slash means directory.
For example, Oracle's SQL Plus will accept the argument like
"user/passwd@instance" - but then who will use this in Windows ?
Everyone I know (includeing myself) clicks on the icon to launch this.
Anyway, one possible way would be like:
% regwna javac # register javac as wna and convert all arguments
# that contains slashes into MS dos path
% regwna javac -1 # Same as the above but only the first argument
% regwna javac -$ # only the last argument
% regwna javac -aname "-classpath" # only the argument for -classpath
% regwna javac - r # remove javac as wna.
# etc etc ... I think that the developers
have a better
# idea of how this may be designed.
I don't think that this will completely solve the problem mathematically,
but I am quite certain that 99.9% of the problems related with path
incomatibility problem will be resolved.
Want to unsubscribe from this list?
Send a message to firstname.lastname@example.org