DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:reply-to:message-id:to:subject
	:in-reply-to:references:mime-version:content-type
	:content-transfer-encoding; q=dns; s=default; b=fjZtSfuMXMd1LJjW
	FngO8SfWXdyAPhQPOlxIK3xCGVSPfDgCKP6GHcqOPjXtEwTdQQwvm8zBQ/7R3Zdz
	ETkvRi0Q05TlV52gOYud6s6bDIfuEf666W8m1rs2gxc+GsWZcylHFPLd6/5d6VZ1
	a2ppdl8fd0+gjszRzG8eYeY10NU=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Mon, 6 Jul 2015 19:11:39 +0300
From: Andrey Repin <anrdaemon AT yandex DOT ru>
Reply-To: cygwin AT cygwin DOT com
Message-ID: <825494649.20150706191139@yandex.ru>
To: Sarbjit singh <sarbjit1987 AT gmail DOT com>, cygwin AT cygwin DOT com
Subject: Re: Migrating from MKS to Cygwin
In-Reply-To: <CAKtakaiJFAwkfTSsxhrNFbgktCqzXdTz2CbT1ikB23wyeHPSxw@mail.gmail.com>
References: <CAKtakaiJFAwkfTSsxhrNFbgktCqzXdTz2CbT1ikB23wyeHPSxw AT mail DOT gmail DOT com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Note-from-DJ: This may be spam

Greetings, Sarbjit singh!

> My organization is evaluating Cygwin as a replacement for MKS. We will
> be using Cygwin primarily for running our regression cases on windows
> (Regression cases are common for Unix and  Windows Platforms).
[1]

> Goal is to migrate to Cygwin with minimal changes to be done at regression
> test cases scripts (Makefile etc.).

> So far, the main challenges are  with "pwd" command and  the
> invocation of applications with .bat extension.
[2]

Sorry, but your [1] does not correlate with [2].

> PWD Command:

> There are few regression cases which uses 'pwd' command in the
> Makefile.
> Since, in the cygwin environment, POSIX paths are returned and these are not
> compatible with the software applications under test i.e. the software
> application is not able to resolve these paths.

That's not true. "Your software" does not need to resolve these paths, in
first place.
If you need to pass $CWD as a parameter to native application for some reason,
wrap it into cygpath, or wrap invocation itself into a .CMD file, where all
directory resolutions will be native.
Please don't use .BAT extension when using NT CMD extended features.

I have this little trick for my own needs.

eval $(
_XXX="$(cygpath -alm "$0")" || true
_dpf0="${_XXX:-$(readlink -fn "$0")}"
echo _dpf0="$_dpf0"
echo _dp0="$(dirname "$_dpf0")"
)

It sets the equivalents of NT CMD's %~dp0 and %~dpf0 macroses.
It is trivial to reverse it to always get native $CWD under both OS.

> As a workaround, I did the following :

> - Define a bash function in .bashrc file, which internally calls
> cygpath to return windows style paths. This will return the windows
> style paths on bash shell but this function is not available in
> Makefile.

I'm pretty sure make calls bash without RC files.
If it ever calls bash as bash, and not /bin/sh.

> - So, for Makefile, I have declared macro (makefile variable) and
> using the cygpath to return windows style paths. But, this would
> require changes in the Makefile i.e. to replace 'pwd' with ${PWD}.

To me, it sounds like you are solving nonexistent problem, or your makefiles
are not constructed properly.
make always descend into a directory and execute commands inside it. You don't
need to worry about the value of pwd at all.
What is your REAL question?

> - In order to minimize any changes in the Makefile, I also tried
> downloading the GNU coreutils for Windows port and replacing pwd.exe

THAT is the worst solution possible.

> (/usr/bin) with the pwd.exe from coreutils. In this case, if I do pwd,
> then I still get POSIX paths, but if I call pwd.exe with absolute
> path, then it returns windows style paths. I am not sure, why it is
> not working when pwd is called without any path.

> Invocation of applications with .bat extension:

> Second main difference that is observed is that in Cygwin, you have to
> call the application with extension if it is .bat. This works
> seamlessly on MKS.

Then your tests are badly constructed and need a complete rewrite.
ALWAYS use full names, or you open up a can of worms and can not predict the
invocation results. Simple example:
[anrdaemon AT DAEMON2 C:\Users\anrdaemon\bin\1]
$ dir /B
xxx.cmd
xxx.com
xxx.exe
xxx.sh

Which one will be executed, when you call xxx from windows command prompt?
What? No, wrong answer.

[anrdaemon AT DAEMON2 C:\Users\anrdaemon\bin\1]
$ xxx
this is a CMD file.

[anrdaemon AT DAEMON2 C:\Users\anrdaemon\bin\1]
$ echo %PATHEXT%
.CMD;.SH;.EXE

[anrdaemon AT DAEMON2 C:\Users\anrdaemon\bin\1]
$

CMD will be executed first, and com will not be executed ever.

While you are at it, switch to shell scripts and only call CMD batch files
where absolutely necessary (i.e. where they are a part of application you
test, not a part of test itself).

> Since, the software installation can't be changed to address this
> problem, so far the workarounds are :

> - Create an alias, but again this won't work in Makefile

> - Create a softlink dynamically while running regressions (pre regression setup)

> - Create a file with the application name and call the .bat file. Keep
> these new executable files in a accessible path.

Right solution: Fix your tests. They are broken.

> Queries:

> - Can someone please conform if the workarounds being used are OK. Is
> there any better way of addressing these problems. Any patches for
> both the problems?

They are not OK, they are crutches and bandaids to an inherently broken
design.

> - Why is the pwd not working, when pwd is used from coreutils.

Because it is not used.


-- 
With best regards,
Andrey Repin
Monday, July 6, 2015 18:28:33

Sorry for my terrible english...


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple