RE: pwd vs $PWD, bash, cygwin vs Linux
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 -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: pwd vs $PWD, bash, cygwin vs Linux
On Wed, 4 May 2005, John Williams wrote: Christopher Faylor wrote: 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 -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! The Sun will pass between the Earth and the Moon tonight for a total Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: pwd vs $PWD, bash, cygwin vs Linux
On Wed, May 04, 2005 at 09:27:15AM -0400, Igor Pechtchanski wrote: On Wed, 4 May 2005, John Williams wrote: Christopher Faylor wrote: 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, 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 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: pwd vs $PWD, bash, cygwin vs Linux
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 [EMAIL PROTECTED] wrote: Snipped 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 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: pwd vs $PWD, bash, cygwin vs Linux
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: [EMAIL PROTECTED] ~/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' [EMAIL PROTECTED] ~/maketest 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 -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: pwd vs $PWD, bash, cygwin vs Linux
On Wed, May 04, 2005 at 04:38:08PM +0100, Dave Korn wrote: 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 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: pwd vs $PWD, bash, cygwin vs Linux
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 [EMAIL PROTECTED] wrote: On Wed, May 04, 2005 at 08:05:40AM -0700, Peter Farley wrote: 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. 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. 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 __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: pwd vs $PWD, bash, cygwin vs Linux
On Wed, 4 May 2005, Christopher Faylor wrote: On Wed, May 04, 2005 at 04:38:08PM +0100, Dave Korn wrote: 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. 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. 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. 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 -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! The Sun will pass between the Earth and the Moon tonight for a total Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: pwd vs $PWD, bash, cygwin vs Linux
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 -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: pwd vs $PWD, bash, cygwin vs Linux
Original Message From: Christopher Faylor Sent: 04 May 2005 17:04 On Wed, May 04, 2005 at 04:38:08PM +0100, Dave Korn wrote: 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 -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: pwd vs $PWD, bash, cygwin vs Linux
On Wed, May 04, 2005 at 05:50:14PM +0100, Dave Korn wrote: 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 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: pwd vs $PWD, bash, cygwin vs Linux
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 -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: pwd vs $PWD, bash, cygwin vs Linux
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 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: pwd vs $PWD, bash, cygwin vs Linux
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Korn Sent: Wednesday, May 04, 2005 10:38 AM To: cygwin@cygwin.com 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? ;-) -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
pwd vs $PWD, bash, cygwin vs Linux
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/cygwin@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: [EMAIL PROTECTED] 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' [EMAIL PROTECTED] Maketest]$ while under the identical setup on Linux, I get this: [EMAIL PROTECTED] 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' [EMAIL PROTECTED] 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 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: pwd vs $PWD, bash, cygwin vs Linux
On Wed, May 04, 2005 at 11:08:43AM +1000, John Williams wrote: 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 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: pwd vs $PWD, bash, cygwin vs Linux
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 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: pwd vs $PWD, bash, cygwin vs Linux
Christopher Faylor wrote: On Wed, May 04, 2005 at 11:08:43AM +1000, John Williams wrote: 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 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: pwd vs $PWD, bash, cygwin vs Linux
On Wed, May 04, 2005 at 02:32:07PM +1000, John Williams wrote: Christopher Faylor wrote: On Wed, May 04, 2005 at 11:08:43AM +1000, John Williams wrote: 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. 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 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: pwd vs $PWD, bash, cygwin vs Linux
Christopher Faylor wrote: 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 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: pwd vs $PWD, bash, cygwin vs Linux
Christopher Faylor wrote: 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 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. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
