Migrating from MKS to Cygwin

Migrating from MKS to Cygwin

[Sarbjit singh]

Hi All,

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). 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.

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.

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.

- 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}.

- In order to minimize any changes in the Makefile, I also tried
downloading the GNU coreutils for Windows port and replacing pwd.exe
(/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.

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.

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?

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

Thanks in Advance,
Sarbjit

--
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

Re: Migrating from MKS to Cygwin

[Björn Kautler]

Hi Sarbjit,

pwd is a bash built-in function.
This means, even if you do not have any pwd installed, you still could
call pwd from Bash.
And no matter what pwd you have installed, it will not be called if
you just call "pad" from Bash.
If you use some path though, the installed one is used.
I guess you tested with the Windows port only from Bash, not from the Makefile?
Because I'd think it should work from there, except if it spawns some
Bash process and makes the call there.

Anyways, I'd rather not replace the Cygwin executable by another one
and depend on this.
E. g. If you update, it gets replaced again and behavior changes.
What I'd recommend is, either put the Windows port, or even better a
shellscript - that is called pwd and calls pwd by path and then uses
cygpath to transform the result - earlier in the PATH (e. g.
/usr/local/bin).

For the .bat case, I'd either create a symlink beside the .bat or in
/usr/local/bin, or if it does not work, a shellscript that calls the
.bat.

Regards
Björn

2015-07-06 8:12 GMT+02:00 Sarbjit singh <sarbjit1987@gmail.com>:
> Hi All,
>
> 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). 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.
>
> 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.
>
> 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.
>
> - 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}.
>
> - In order to minimize any changes in the Makefile, I also tried
> downloading the GNU coreutils for Windows port and replacing pwd.exe
> (/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.
>
> 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.
>
> 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?
>
> - Why is the pwd not working, when pwd is used from coreutils.
>
> Thanks in Advance,
> Sarbjit
>
> --
> 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
>

--
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

Re: Migrating from MKS to Cygwin

[Marco Atzeri]

On 7/6/2015 8:12 AM, Sarbjit singh wrote:
> Hi All,
>
> 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). 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.
>
> PWD Command:

Iy you need to translate between cygwin style and windows style
paths the best way is to use cygpath

 From Bash prompt:

$ pwd
/cygdrive/c/WINDOWS/system32

$ cygpath -w $(pwd)
C:\WINDOWS\system32

$ pwd
/tmp

$ cygpath -w $(pwd)
E:\cygwin64\tmp

>
> Thanks in Advance,
> Sarbjit

--
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

Re: Migrating from MKS to Cygwin

[Andrey Repin]

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@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@DAEMON2 C:\Users\anrdaemon\bin\1]
$ xxx
this is a CMD file.

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

[anrdaemon@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

Re: Migrating from MKS to Cygwin

[Warren Young]

On Jul 6, 2015, at 12:12 AM, Sarbjit singh <sarbjit1987@gmail.com> wrote:
> 
> My organization is evaluating Cygwin as a replacement for MKS.

Why replace something that is working with another thing that does pretty much the same thing?

I’m genuinely interested in the answer.  I’m pretty sure you have a good answer, but I must ask because I cannot guess which right answer applies in your case.

> There are few regression cases which uses 'pwd' command in the
> Makefile.

Why?  You should be using relative paths, for the most part.  You might root the project at the very start of the build process as Automake does with $(top_builddir), but after that, everything should be relative.  You should not be consulting absolute paths at all once the build is under way.

Windows copes with forward slashes just fine in paths, so that as long as you stay away from drive letters and UNC — as when you can when you restrict yourself to relative paths — the same paths work the same way on Cygwin, native Windows, Linux, etc.

I say all of this not merely to solve your immediate problem.  It is good general advice which solves a great many problems.  A system dependent on specific absolute paths breaks when moved to any dissimilar machine type.

The grey-beards here may remember problems when apps moved from one *ix type using e.g. /usr/foo for user home directories to SysV, the first version of Unix to finally standardize the home directory scheme as /home/foo.  There was a fair bit of software that did silly hard-coded things like /usr/$USER and consequently broke.

> Define a bash function in .bashrc file

Masking /bin/pwd and the Bash builtin pwd to make them behave in a non-POSIX manner is ill-conceived.  You will cause problems with other programs that expect them to behave as specified by POSIX.

> 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}.

I have less of a problem with this, since you can do whatever you like in your own Makefiles.

However, if it were up to me, I think I would just convert everything to POSIX form, so that the Unix and Windows cases work the same way.  Then you don’t need to play games with pwd.

Alternately, you can abstract away the difference at the build system layer, such as by switching to CMake.  It has its own testing system, CTest.

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

I’m with Andrey: BAD IDEA.

> Since, the software installation can't be changed to address this
> problem

Why not?  Software is infinitely malleable.

Anyone claiming software can’t be changed is really saying, “I don’t *want* to change it for reason X.”  Maybe they have a good reason, maybe not.  But it is never the case that software *can’t* be changed.
--
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