pwd vs $PWD, bash, cygwin vs Linux

[John Williams]

Hello,

I am resurrecting a topic that has been discussed before, but there
doesn't seem to be a clear resolution (at least not clear to me!). It
relates to the behaviour of the PWD variable in the case of multiply
nested Makefiles. it was touched upon e.g. here:

http://www.mail-archive.com/***@sources.redhat.com/msg16375.html

I'm doing a side by side comparison between Cygwin 1.5.16-1 and Linux
RedHat 8.0, both using bash shell 2.05b.0(1)-release, and make version
3.79.1

Here's my test setup (sorry for dodgy ASCII art)

Maketest
|
+ topdir
|
+ Makefile
|
+ subdir
|
+ Makefile

topdir/Makefile looks like this:

#####
#topdir/Makefile
TOPDIR := $(shell echo $$PWD)

all:
@echo In topdir, TOPDIR=$(TOPDIR)
@echo In topdir, PWD=$$PWD
make -C subdir all

.EXPORT_ALL_VARIABLES:
######

and topdir/subdir/Makefile looks like this:

#####
#topdir/subdir/Makefile
all:
@echo in subdir, TOPDIR=$(TOPDIR)
@echo in subdir, PWD=$$PWD
#####

Now, from the top-top level (Maketest), I run 'make -C topdir'. Under
my Cygwin setup, I get this:

[***@JWILLIAMS Maketest]$ make -C topdir
make: Entering directory `/cygdrive/z/Maketest/topdir'
In topdir, TOPDIR=/cygdrive/z/Maketest
In topdir, PWD=/cygdrive/z/Maketest
make -C subdir all
make[1]: Entering directory `/cygdrive/z/Maketest/topdir/subdir'
in subdir, TOPDIR=/cygdrive/z/Maketest
in subdir, PWD=/cygdrive/z/Maketest
make[1]: Leaving directory `/cygdrive/z/Maketest/topdir/subdir'
make: Leaving directory `/cygdrive/z/Maketest/topdir'
[***@JWILLIAMS Maketest]$

while under the identical setup on Linux, I get this:

[***@g512-9029 Maketest]$ make -C topdir
make: Entering directory `/mnt/home2/jwilliam/Maketest/topdir'
In topdir, TOPDIR=/mnt/home2/jwilliam/Maketest/topdir
In topdir, PWD=/mnt/home2/jwilliam/Maketest/topdir
make -C subdir all
make[1]: Entering directory `/mnt/home2/jwilliam/Maketest/topdir/subdir'
in subdir, TOPDIR=/mnt/home2/jwilliam/Maketest/topdir
in subdir, PWD=/mnt/home2/jwilliam/Maketest/topdir/subdir
make[1]: Leaving directory `/mnt/home2/jwilliam/Maketest/topdir/subdir'
make: Leaving directory `/mnt/home2/jwilliam/Maketest/topdir'
[***@g512-9029 Maketest]$

Essentially under Cygwin the PWD variable seems to be "frozen" at its
value upon first launching Make from the commandline, while under Linux
it is being updated for each child process spawned by `make -C XXX`

I know that Cygwin != Linux, however is it a reasonable expectation that
under the same shells, the same behaviour should apply?

The real context for all of this is building the net-tools package,
which uses these sort of constructs to manage its recursive Makefile
structure. I'm sure there are plenty of other GNU-esque packages out
there doing similarly.

Any insights or workarounds would be greatly appreciated.

Thanks,

John

[Christopher Faylor]

Post by John Williams
Essentially under Cygwin the PWD variable seems to be "frozen" at its
value upon first launching Make from the commandline, while under Linux
it is being updated for each child process spawned by `make -C XXX`
I know that Cygwin != Linux, however is it a reasonable expectation
that under the same shells, the same behaviour should apply?

In this case, the operative observation is bash != ash. PWD is a bash
construct. You would be much better off just using the gnu make
"CURDIR" variable. Changing PWD to CURDIR in your examples makes things
work as you'd expect.

cgf

[John Williams]

Post by Christopher Faylor

Post by John Williams
Essentially under Cygwin the PWD variable seems to be "frozen" at its
value upon first launching Make from the commandline, while under Linux
it is being updated for each child process spawned by `make -C XXX`
I know that Cygwin != Linux, however is it a reasonable expectation
that under the same shells, the same behaviour should apply?

In this case, the operative observation is bash != ash. PWD is a bash
construct. You would be much better off just using the gnu make
"CURDIR" variable. Changing PWD to CURDIR in your examples makes things
work as you'd expect.

Thanks for the quick response and workaround.

While what you say might be a true statement, "better off" means
different things to different people!

It's easy for me to say, but it seems cleaner for the compatability
layer (e.g. Cygwin) to model the expected behaviour (even behaviour
which might be considered buggy), than to push changes on fairly
standard and widely distributed source/build packages.

What surprised me was that the same shell, and same make, resulted in
different behaviour. I guess this is just reflecting differences in the
underlying process architectures of Linux vs Windows.

Cheers,

John

[Christopher Faylor]

Post by John Williams

Post by Christopher Faylor

Post by John Williams
Essentially under Cygwin the PWD variable seems to be "frozen" at its
value upon first launching Make from the commandline, while under Linux
it is being updated for each child process spawned by `make -C XXX`
I know that Cygwin != Linux, however is it a reasonable expectation
that under the same shells, the same behaviour should apply?

In this case, the operative observation is bash != ash. PWD is a bash
construct. You would be much better off just using the gnu make
"CURDIR" variable. Changing PWD to CURDIR in your examples makes things
work as you'd expect.

Thanks for the quick response and workaround.
While what you say might be a true statement, "better off" means
different things to different people!

"Better off" == "it works" vs. "not better off" == "it doesn't work".

Post by John Williams
What surprised me was that the same shell, and same make, resulted in
different behaviour. I guess this is just reflecting differences in the
underlying process architectures of Linux vs Windows.

Again, it *isn't* the same shell. You have now learned that it isn't
the same shell and you now know that this is the reason for the
inconsistency. ash isn't normally used as /bin/sh on linux. A stripped
down version of ash is used as /bin/sh for performance purposes on
cygwin. ash does not set PWD.

cgf

[John Williams]

Post by Christopher Faylor

Post by John Williams

Post by Christopher Faylor
In this case, the operative observation is bash != ash. PWD is a bash
construct. You would be much better off just using the gnu make
"CURDIR" variable. Changing PWD to CURDIR in your examples makes things
work as you'd expect.

Thanks for the quick response and workaround.
While what you say might be a true statement, "better off" means
different things to different people!
What surprised me was that the same shell, and same make, resulted in
different behaviour. I guess this is just reflecting differences in the
underlying process architectures of Linux vs Windows.

Again, it *isn't* the same shell. You have now learned that it isn't
the same shell and you now know that this is the reason for the
inconsistency. ash isn't normally used as /bin/sh on linux. A stripped
down version of ash is used as /bin/sh for performance purposes on
cygwin. ash does not set PWD.

OK - I see the confusion. Make is spawning ash as the subshell, not
bash. Now everything you said makes sense. Out of interest, can that
behaviour be modified at the runtime/user/Makefile level?

Cheers,

John

[Gary R. Van Sickle]

Post by Christopher Faylor

Post by Christopher Faylor

Post by John Williams

Post by Christopher Faylor
In this case, the operative observation is bash != ash. PWD is a
bash construct. You would be much better off just using

the gnu make

Post by Christopher Faylor

Post by John Williams

Post by Christopher Faylor
"CURDIR" variable. Changing PWD to CURDIR in your examples makes
things work as you'd expect.

Thanks for the quick response and workaround.
While what you say might be a true statement, "better off" means
different things to different people!
What surprised me was that the same shell, and same make,

resulted in

Post by Christopher Faylor

Post by John Williams
different behaviour. I guess this is just reflecting

differences in

Post by Christopher Faylor

Post by John Williams
the underlying process architectures of Linux vs Windows.

Again, it *isn't* the same shell. You have now learned

that it isn't

Post by Christopher Faylor
the same shell and you now know that this is the reason for the
inconsistency. ash isn't normally used as /bin/sh on linux. A
stripped down version of ash is used as /bin/sh for performance
purposes on cygwin. ash does not set PWD.

OK - I see the confusion. Make is spawning ash as the
subshell, not bash. Now everything you said makes sense.
Out of interest, can that behaviour be modified at the
runtime/user/Makefile level?
Cheers,
John

You could replace the /bin/sh.exe executable with a copy of bash.exe, but
that would be at the "everywhere, all the time" level. That used to be a
regularly suggested workaround for similar problems back in the proverbial
day, but it's been ages since I've done that myself, so I can't tell you
what other problems that might cause.

[Dave Korn]

----Original Message----

From: John Williams
Sent: 04 May 2005 06:20
OK - I see the confusion. Make is spawning ash as the subshell, not
bash. Now everything you said makes sense. Out of interest, can that
behaviour be modified at the runtime/user/Makefile level?

The make documentation regarding $SHELL would suggest so. Search for the
"Command execution" node in "info make".

cheers,
DaveK

[Igor Pechtchanski]

Post by John Williams

Post by Christopher Faylor

Post by John Williams

Post by Christopher Faylor
In this case, the operative observation is bash != ash. PWD is a
bash construct. You would be much better off just using the gnu
make "CURDIR" variable. Changing PWD to CURDIR in your examples
makes things work as you'd expect.

Thanks for the quick response and workaround.
While what you say might be a true statement, "better off" means
different things to different people!
What surprised me was that the same shell, and same make, resulted
in different behaviour. I guess this is just reflecting differences
in the underlying process architectures of Linux vs Windows.

Again, it *isn't* the same shell. You have now learned that it isn't
the same shell and you now know that this is the reason for the
inconsistency. ash isn't normally used as /bin/sh on linux. A
stripped down version of ash is used as /bin/sh for performance
purposes on cygwin. ash does not set PWD.

OK - I see the confusion. Make is spawning ash as the subshell, not
bash. Now everything you said makes sense. Out of interest, can that
behaviour be modified at the runtime/user/Makefile level?

In addition to what Gary said, you could also try the following (WARNING:
untested), which isn't as drastic:

mount -u -f -b -x "`cygpath -aw /bin/bash.exe`" /bin/sh.exe
mount -u -f -b -x "`cygpath -aw /bin/bash`" /bin/sh
make
umount -u /bin/sh.exe
umount -u /bin/sh

I may have gotten some flags slightly wrong -- "man mount" should help
with that.
HTH,
Igor

[Christopher Faylor]

Post by Igor Pechtchanski

Post by John Williams

Post by Christopher Faylor

Post by John Williams

Post by Christopher Faylor
In this case, the operative observation is bash != ash. PWD is a
bash construct. You would be much better off just using the gnu
make "CURDIR" variable. Changing PWD to CURDIR in your examples
makes things work as you'd expect.

Thanks for the quick response and workaround.
While what you say might be a true statement, "better off" means
different things to different people!
What surprised me was that the same shell, and same make, resulted
in different behaviour. I guess this is just reflecting differences
in the underlying process architectures of Linux vs Windows.

Again, it *isn't* the same shell. You have now learned that it isn't
the same shell and you now know that this is the reason for the
inconsistency. ash isn't normally used as /bin/sh on linux. A
stripped down version of ash is used as /bin/sh for performance
purposes on cygwin. ash does not set PWD.

OK - I see the confusion. Make is spawning ash as the subshell, not
bash. Now everything you said makes sense. Out of interest, can that
behaviour be modified at the runtime/user/Makefile level?

mount -u -f -b -x "`cygpath -aw /bin/bash.exe`" /bin/sh.exe
mount -u -f -b -x "`cygpath -aw /bin/bash`" /bin/sh
make
umount -u /bin/sh.exe
umount -u /bin/sh
I may have gotten some flags slightly wrong -- "man mount" should help
with that.
HTH,

I really don't understand why using CURDIR isn't the ultimate solution
here. If you can mess with your mount table or copy bash to sh, then
you really should be able to also change your Makefile to use $(CURDIR)
rather than $$PWD.

cgf

[Eric Blake]

Post by Christopher Faylor

Post by John Williams
I know that Cygwin != Linux, however is it a reasonable expectation
that under the same shells, the same behaviour should apply?

In this case, the operative observation is bash != ash. PWD is a bash
construct. You would be much better off just using the gnu make
"CURDIR" variable. Changing PWD to CURDIR in your examples makes things
work as you'd expect.

POSIX requires /bin/sh to keep $PWD accurate, but ash does not meet POSIX requirements (in this and a number of other instances). PWD is not just for bash, it is for all compliant shells. Unfortunately, all of the open-source compliant shells come with so much extra weight (read: interactive features that aren't used by shell scripts, but that consume memory and slow down forks) that none of them have been deemed acceptable for replacing ash as cygwin's /bin/sh.

Also, you can safely use /bin/pwd from coreutils to find out your real current directory, although it does not yet implement the POSIX-required -L vs. -P options.

--
Eric Blake

[Peter Farley]

But what if it is *not* your Makefile, but someone
else's, e.g. the many GNU source packages that expect
bash behavior? Surely you don't intend that ordinary
users (well, OK, anyone compiling from a source
package isn't really "ordinary") should modify every
package maintained by GNU in order to make it under
cygwin, do you?

With respect,

Peter

P.S. - If there have already been discussions or if
there already exists documentation on why ash vs. bash
(I gather it is for performance reasons), I'd
appreciate (a) pointer(s) so I could better learn the
history so I don't re-hash settled issues.

--- Christopher Faylor
<cgf-no-personal-reply-***@cygwin.com> wrote:
<Snipped>

Post by Christopher Faylor
I really don't understand why using CURDIR isn't
the ultimate solution here. If you can mess with
your mount table or copy bash to sh, then
you really should be able to also change your
Makefile to use $(CURDIR) rather than $$PWD.

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

[Christopher Faylor]

Post by Peter Farley
But what if it is *not* your Makefile,

I just went back and reread this thread. It isn't exactly clear that
this was not your Makefile. You mentioned a "test setup" which seemed
to imply that you were using your own Makefiles.

Post by Peter Farley
but someone else's, e.g. the many GNU source packages that expect bash
behavior?

Most GNU packages are interested in being portable. Assuming that every
system out there is POSIX compliant is not portable. I have a couple of
older systems that I use which would have the same problems as cygwin
if you use PWD in a Makefile. Actually, CURDIR would also be a problem
for them since they don't use GNU make. Since the workaround is trivial
it would make sense to not rely on PWD in any package that is supposed
to be disseminated widely.

Post by Peter Farley
Surely you don't intend that ordinary users (well, OK, anyone compiling
from a source package isn't really "ordinary") should modify every
package maintained by GNU in order to make it under cygwin, do you?

I would expect a GNU-maintained package to accept a patch to eliminate a
potential problem source.

However, I surely don't intend to keep talking about this any further.
I get the feeling that you want us (i.e., cygwin maintainers) to do
something globally to solve this. We've been using ash for many years
and we're not about to change anytime soon. You've been given enough
alternatives now that you should be able to get things working.

Cygwin is not guaranteed to be 100% POSIX compliant or 100% linux
compliant. Sometimes we make tradeoffs because of Windows constraints.
Since bash is noticeably slower than ash under Cygwin, we use ash as our
/bin/sh. That produces some problems for non-portable shell constructs.

cgf

[Dave Korn]

----Original Message----

From: Peter Farley
Sent: 04 May 2005 16:06
But what if it is *not* your Makefile, but someone
else's, e.g. the many GNU source packages that expect
bash behavior? Surely you don't intend that ordinary
users (well, OK, anyone compiling from a source
package isn't really "ordinary") should modify every
package maintained by GNU in order to make it under
cygwin, do you?

HELLO? CAN ANYONE HEAR ME? <tap-tap-tap> Testing, testing, is this
thing on? Am I invisible all of a sudden? Has everyone in the world gone
mad except me? Why is everyone coming out with awkward solutions involving
remounting mounts or fiddling with symlinks or hacking around every
poorly-written-makefile-containing-nonportable-bashisms-in-the-whole-world?


I did actually post the answer to this problem six hours and four posts
ago. I guess it must be stuck somewhere behind a heavy flow of spam and not
made it to the list yet. Anyway here it is again.

make SHELL=/bin/bash.exe

This FIXES your original testcase. Look, if you don't believe me:

***@mace ~/maketest> make -C topdir SHELL=/bin/bash.exe
make: Entering directory `/home/dk/maketest/topdir'
In topdir, TOPDIR=/home/dk/maketest/topdir
In topdir, PWD=/home/dk/maketest/topdir
make -C subdir all
make[1]: Entering directory `/home/dk/maketest/topdir/subdir'
in subdir, TOPDIR=/home/dk/maketest/topdir
in subdir, PWD=/home/dk/maketest/topdir/subdir
make[1]: Leaving directory `/home/dk/maketest/topdir/subdir'
make: Leaving directory `/home/dk/maketest/topdir'

P.S. - If there have already been discussions or if
there already exists documentation on why ash vs. bash
(I gather it is for performance reasons), I'd

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

appreciate (a) pointer(s) so I could better learn the

See the phrase between brackets in your previous line! When you run a big
configure or build of something of the scale gcc there may be anywhere
between tens and hundreds of thousands of sub-shell invocations in the
entire process, and given that forks are already quite a bit slow on cygwin,
it's really worth shaving time off them by using a leaner meaner shell.

cheers,
DaveK

[Christopher Faylor]

Post by Dave Korn
----Original Message----

From: Peter Farley
Sent: 04 May 2005 16:06
But what if it is *not* your Makefile, but someone else's, e.g. the
many GNU source packages that expect bash behavior? Surely you don't
intend that ordinary users (well, OK, anyone compiling from a source
package isn't really "ordinary") should modify every package maintained
by GNU in order to make it under cygwin, do you?

HELLO? CAN ANYONE HEAR ME? <tap-tap-tap> Testing, testing, is this
thing on? Am I invisible all of a sudden? Has everyone in the world
gone mad except me? Why is everyone coming out with awkward solutions
involving remounting mounts or fiddling with symlinks or hacking around
every
poorly-written-makefile-containing-nonportable-bashisms-in-the-whole-world?

Maybe because fixing the Makefile means not having to remember to type
"SHELL=/bin/bash.exe" every time you invoke make? That's why I didn't
suggest this in my first response even though I'm a makefile *guru*.

I agree that the mount technique doesn't make a lot of sense (and woe to
you if you hit CTRL-C at the wrong point) but your "solution" is
actually a workaround.

Of course, you could just put a

SHELL = /bin/bash

in the Makefile but then, gasp!, you'd be modifying the makefile and
shirley you don't intend every person in this space time continuum to do
that.

I guess if your goal is to just build a package and forget about it, then
using the command line is acceptable. You just have to remember to do that
again, when you build the package in six months. Or, maybe you could make
a shell alias! Yeah, that's the ticket.

cgf

[Igor Pechtchanski]

Post by Christopher Faylor

Post by Dave Korn
----Original Message----

From: Peter Farley
Sent: 04 May 2005 16:06
But what if it is *not* your Makefile, but someone else's, e.g. the
many GNU source packages that expect bash behavior? Surely you don't
intend that ordinary users (well, OK, anyone compiling from a source
package isn't really "ordinary") should modify every package maintained
by GNU in order to make it under cygwin, do you?

HELLO? CAN ANYONE HEAR ME? <tap-tap-tap> Testing, testing, is this
thing on? Am I invisible all of a sudden? Has everyone in the world
gone mad except me? Why is everyone coming out with awkward solutions
involving remounting mounts or fiddling with symlinks or hacking around
every
poorly-written-makefile-containing-nonportable-bashisms-in-the-whole-world?

Sorry, Dave, I should've said "In addition to what Gary and Dave said".

Post by Christopher Faylor
Maybe because fixing the Makefile means not having to remember to type
"SHELL=/bin/bash.exe" every time you invoke make? That's why I didn't
suggest this in my first response even though I'm a makefile *guru*.
I agree that the mount technique doesn't make a lot of sense (and woe to
you if you hit CTRL-C at the wrong point) but your "solution" is
actually a workaround.

The mount technique was a temporary alternative to "cp /bin/bash.exe
/bin/sh.exe". No more, no less. I agree in retrospect that it's a bit of
an overkill.

Post by Christopher Faylor
Of course, you could just put a
SHELL = /bin/bash
in the Makefile but then, gasp!, you'd be modifying the makefile and
shirley you don't intend every person in this space time continuum to do
that.

Frankly, CGF is absolutely right -- any Makefile that uses bash-specific
features in its commands should have SHELL=/bin/bash at the top. Period.

Post by Christopher Faylor
I guess if your goal is to just build a package and forget about it,
then using the command line is acceptable. You just have to remember to
do that again, when you build the package in six months. Or, maybe you
could make a shell alias! Yeah, that's the ticket.

Igor

[Dave Korn]

----Original Message----

From: Christopher Faylor
Sent: 04 May 2005 17:04
Maybe because fixing the Makefile means not having to remember to type
"SHELL=/bin/bash.exe" every time you invoke make?

s,every time you invoke make,on those rare occasions when you invoke make on
a buggy non-portable makefile that specifically is non-portable in this
particular fashion of expecting bash behaviour from any arbitrary /bin/sh
implementation,g

That's why I didn't
suggest this in my first response even though I'm a makefile *guru*.

I guess that first post of mine must _still_ not have arrived then,
because all I said was to use the $SHELL variable: I have never at any
point *denied* there is more than one way to set a make variable.

Of course, you could just put a
SHELL = /bin/bash
in the Makefile but then, gasp!, you'd be modifying the makefile and
shirley you don't intend every person in this space time continuum to do
that.

I'm not clear now... are you recommending changing the makefile locally,
or not?!

In any case, it's not necessarily the most appropriate answer to give in
reply to a post that asked "What if it is not your makefile?", which I
implicitly took as meaning "Is there a solution that *doesn't* involve
editing the makefile?".

I guess if your goal is to just build a package and forget about it, then
using the command line is acceptable. You just have to remember to do
that again, when you build the package in six months.

Whereas with your solution, you only have to remember to edit the makefile
and add "SHELL=/bin/bash" again, when you build the package in six months.
Hey, I really don't see one of those as being any more or less difficult /
easy / reliable / errorprone than the other.

Or, maybe you
could make a shell alias! Yeah, that's the ticket.
cgf

My *goal* was to suggest a solution that met the requirements specified by
the OP:

"Make is spawning ash as the subshell, not bash. [ ...snip... ] Can that
behaviour be modified at the runtime/user/Makefile level?"

The answer I gave was simple and correct and pointed at the *technique*
without specifying a particular implementation:

"The make documentation regarding $SHELL would suggest so."

When my first post seemed to have entirely skipped below everyone's
threshold of perception, I posted a concrete example. I didn't say it was
the only way to do it.




cheers,
DaveK

[Christopher Faylor]

To clarify:

1) The correct long-term solution to the problem of bash/ash
incompatibilities is to modify the makefile to avoid the problem.
If the Makefile is yours, then you are done. If the makefile is
from someone else, then you provide the someone else with a patch.

If you can be guaranteed that you are using GNU make then you can
use "$(CURDIR)" in place of $$PWD. Otherwise, you'll need to use
`pwd`.

2) The easiest workaround to the problem is "make SHELL=/bin/bash".
I did not suggest this originally because I thought that the makefile
was home-grown and would benefit from being permanently fixed.

This has the drawback of requiring you to remember to do this every
time you type "make" which is somewhat of a problem if you are doing
active development.

3) When I said "shirley you don't intend" I was parodying the poster who
was appalled by the idea of modifying the thousands of makefiles out
there which just must be rife with the use of PWD. It was not a serious
comment, since if you are going to modify your makefile to say "SHELL =
/bin/bash" you might as well just modify your makefile to use CURDIR.

cgf

[Gary R. Van Sickle]

-----Original Message-----
Sent: Wednesday, May 04, 2005 10:38 AM
Subject: RE: pwd vs $PWD, bash, cygwin vs Linux
HELLO? CAN ANYONE HEAR ME? <tap-tap-tap> Testing,
testing, is this
thing on? Am I invisible all of a sudden?

Do you guys hear that tapping?

;-)

[Peter Farley]

WHOA there. I think we have a slight failure to
communicate. I am NOT the OP, I was just chiming in
on the conversation (I should have said PMFJI right up
front, apologies for forgetting that).

That said, I understand your position better now,
especially with Dave's workaround (perfectly
acceptable to me, don't know about the OP).

I certainly did NOT intend to say or to imply that
cygwin maintainers should make any global fix to
address this issue. I just did not understand the
reason that bash was not the default shell. Now I do.
Thank you (and Dave Korn) for straightening me out.

Mea maxima culpa for not being clear in my question or
my comments.

Peter

--- Christopher Faylor

On Wed, May 04, 2005 at 08:05:40AM -0700, Peter

Post by Peter Farley
But what if it is *not* your Makefile,

I just went back and reread this thread. It isn't
exactly clear that this was not your Makefile.
You mentioned a "test setup" which seemed
to imply that you were using your own Makefiles.

Post by Peter Farley
but someone else's, e.g. the many GNU source
packages that expect bash behavior?

Most GNU packages are interested in being portable.
Assuming that every system out there is POSIX
compliant is not portable. I have a couple of
older systems that I use which would have the same
problems as cygwin if you use PWD in a Makefile.
Actually, CURDIR would also be a problem
for them since they don't use GNU make. Since the
workaround is trivial it would make sense to not
rely on PWD in any package that is supposed
to be disseminated widely.

Post by Peter Farley
Surely you don't intend that ordinary users (well,

OK, anyone compiling

Post by Peter Farley
from a source package isn't really "ordinary")

should modify every

Post by Peter Farley
package maintained by GNU in order to make it under

cygwin, do you?
I would expect a GNU-maintained package to accept a
patch to eliminate a potential problem source.
However, I surely don't intend to keep talking
about this any further. I get the feeling that you
want us (i.e., cygwin maintainers) to do
something globally to solve this. We've been using
ash for many years and we're not about to change
anytime soon. You've been given enough
alternatives now that you should be able to get
things working.
Cygwin is not guaranteed to be 100% POSIX compliant
or 100% linux compliant. Sometimes we make
tradeoffs because of Windows constraints.
Since bash is noticeably slower than ash under
Cygwin, we use ash as our /bin/sh. That produces
some problems for non-portable shell constructs.
cgf

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

[Dave Korn]

----Original Message----

From: Peter Farley
Sent: 04 May 2005 17:30
WHOA there. I think we have a slight failure to
communicate. I am NOT the OP, I was just chiming in
on the conversation

Oops, so you are! Umm, I mean, "So you aren't!" Ermmm.. guess I mean
"Pardon me for not checking!"



cheers,
DaveK

[Christopher Faylor]

Post by Dave Korn
----Original Message----

From: Peter Farley
Sent: 04 May 2005 17:30
WHOA there. I think we have a slight failure to
communicate. I am NOT the OP, I was just chiming in
on the conversation

Oops, so you are! Umm, I mean, "So you aren't!" Ermmm.. guess I mean
"Pardon me for not checking!"

Ditto. I even went back to check the original posting and didn't notice
the different From:. That's embarrassing. Sorry.

The points are still valid, ", however. I don't see any reason to raise
global concerns about makefile interoperability with linux just because
one person has a trivially-solveable problem with a couple of makefiles.

cgf

[Dave Korn]

----Original Message----

From: Christopher Faylor
Sent: 04 May 2005 18:13
The points are still valid, ", however. I don't see any reason to raise
global concerns about makefile interoperability with linux just because
one person has a trivially-solveable problem with a couple of makefiles.

"Trivially-solveable" ?

Aha, so you accept that a command-line workaround is a suitable and
proportionate fix after all!



GOTCHA! HAH!



<snigger>

cheers,
DaveK