creps@silver.bacs.indiana.edu (10/19/87)
With the version 4.3 of ndmake posted recently I believe there is a bug. I was trying to make the pccurses library, which included a couple of cd commands, but it didn't seem to be changing directories. Then I added a cd with no argument (to print the current directory) after the "cd smodel" command. Sure enough, it showed that the current directory had not changed. Here is a mini-transcript of what happened: (starting in c:\tmp), "make small" mkdir smodel (this works, the directory is created) copy ___ smodel (works, files are copied) cd smodel cd (I added this to see what happened; printed "c:\tmp", not "c:\tmp\smodel") Now, what happened? I seriously doubt it's a problem with the pccurses, because how can you screw up a "cd" command? Or is it some subtle thing that I missed to get it work right? - - - - - - - - - Steve Creps on the VAX 8650 running Ultrix 2.0-1 at Indiana University. creps@silver.bacs.indiana.edu "Go tell your master we are on a quest for the Holy Grail!" "Well... I dunno... I think he's already got one.>
creps@silver.bacs.indiana.edu (10/19/87)
Someone has pointed out to me that because the program must use a new command shell to execute the cd command, the environment in that new shell is not returned when it's completed executing. That is why the current directory appears not to have changed when the cd is done. It actually was changed, but in the new shell, and was not returned to the old shell. I missed it in the documentation the first time, but now that I go back to it I see that the makefile should include the following: (cd smodel ; cd ; ...) rather than: cd smodel cd ... So, to answer my own question: it WAS some subtle thing I missed. My apologies for the false alarm. - - - - - - - - - Steve Creps on the VAX 8650 running Ultrix 2.0-1 at Indiana University. creps@silver.bacs.indiana.edu "Go tell your master we are on a quest for the Holy Grail!" "Well... I dunno... I think he's already got one."
galvin@circle.UUCP (John Galvin) (10/19/87)
In message <15000037@silver> Steve Creps writes: > With the version 4.3 of ndmake posted recently I believe there > is a bug. I was trying to make the pccurses library, which included > a couple of cd commands, but it didn't seem to be changing directories. > Then I added a cd with no argument ( to print the current directory) > after the "cd smodel" command. Sure enough, it showed that the current > directory had not changed. Here is a mini-transcript of what happened: > (starting in c:\tmp), "make small" > mkdir smodel (this works, the directory is created) > copy ___ smodel (works, files are copied) > cd smodel > cd (I added this to see what happened; printed "c:\tmp", > not "c:\tmp\smodel") > Now, what happened? I seriously doubt it's a problem with the pccurses, > because how can you screw up a "cd" command? Or is it some subtle > thing that I missed In the Unix Programmer's Manual (yes, it's RTFM time again, DK is too good of a programmer to mess this one up) it notes under Make(1): "Commands that are directly executed by the shell, notably *cd(1)*, are ineffectual across newlines in *make*." In other words, try this on the "cd smodel" line in your makefile: cd smodel; cd you should get "c:\tmp\smodel" back. --John -- John Galvin UUCP: ...uwvax!geowhiz!uwspan!circle!galvin 1810 Fordem Ave. #6 FidoNet: Sysop of 121/0, and 121/1. (608) 249-0275 Madison, Wi 53704 AT&T: (608) 249-0150
mshiels@orchid.UUCP (10/20/87)
You need to do the 'cd' and any other commands in thet directory on the same line. IE: 'cd smodel; make ...; cd ..' I think you have to do this because the commands are run as a sub shell. -- Michael A. Shiels (MaS Network Software) mshiels@orchid.waterloo.EDU UUCP: ...path...!watmath!orchid!mshiels
nathan@eddie.MIT.EDU (Nathan Glasser) (10/21/87)
In previous articles creps@silver.uucp writes: >... >command shell to execute the cd command, the environment in that new shell >is not returned when it's completed executing. That is why the current >directory appears not to have changed when the cd is done. It actually was >changed, but in the new shell, and was not returned to the old shell. I > (cd smodel ; cd ; ...) >rather than: > cd smodel galvin@circle.uucp writes: >In the Unix Programmer's Manual (yes, it's RTFM time again, DK is too good >of a programmer to mess this one up) it notes under Make(1): > "Commands that are directly executed by the shell, notably *cd(1)*, > are ineffectual across newlines in *make*." >In other words, try this on the "cd smodel" line in your makefile: > cd smodel; cd >you should get "c:\tmp\smodel" back. If this were Unix, and we were using Unix make, what was stated above would be (almost) correct. In our case, things are different. In Dos, there is only one "current directory". Because of this "feature", the original makefile code should have worked using the standard ms-dos shell "command.com". From a comment creps@silver made above and others I didn't include, it seems that he does not use the standard command.com. The one he does use apparently remembers the current directory when it starts, and changes back to this directory at the termination. His solution also does not apply to standard command.com. Semicolons do not serve to separate commands on a single command line, nor is there any other way to do this. The comment about the environment is completely irrelevant, for both Dos and Unix. In short, normal users of Dos, command.com, and ndmake should ignore this whole discussion. It does not apply to them, and contains technical inaccuracies as well. -- Nathan Glasser fnord nathan@{mit-eddie.uucp, xx.lcs.mit.edu} "A tribble is the only love that money can buy." Presently there is insufficient evidence to conclude that tribbles spread AIDS.
creps@silver.bacs.indiana.edu (10/21/87)
>/* Written 4:17 pm Oct 20, 1987 by nathan@mit-eddie in silver:comp.sys.ibm > >From a comment creps@silver made above and others I didn't include, >it seems that he does not use the standard command.com. The one >he does use apparently remembers the current directory when it >starts, and changes back to this directory at the termination. > >His solution also does not apply to standard command.com. Semicolons >do not serve to separate commands on a single command line, nor is >there any other way to do this. For the record, I am using the standard command.com. No, semicolons don't separate commands on a line in DOS, but they DO in ndmake. Here is the exact text from the ndmake 4.3 documentation. I hope it ends this discussion once and for all. > MAKE supports multiple commands on a single line if the command is > enclosed in parentheses () and the commands are separated by semi- > colons (use \; if you need a semi-colon to *not* be interpreted as a > command separator). In fact, since each command line is executed in > its own shell, this is the only way to use DOS commands like "set" and > "chdir" so that they have any effect. For example, doing "make x" > where the makefile looks like: > x: > chdir \tmp > copy *.* a: > > will copy the contents of the *current* directory, not \tmp, to drive > A. This is because MAKE starts each command in the current directory. > The correct way to write this is: > x: > (chdir \tmp; copy *.* a:) - - - - - - - - - Steve Creps on the VAX 8650 running Ultrix 2.0-1 at Indiana University. creps@silver.bacs.indiana.edu "...and I noticed the lad with the thermonuclear device was the Chief Constable for the area..."
nathan@eddie.MIT.EDU (Nathan Glasser) (10/22/87)
In article <15000040@silver> creps@silver.bacs.indiana.edu writes: > For the record, I am using the standard command.com. No, semicolons don't >separate commands on a line in DOS, but they DO in ndmake. Here is the exact >text from the ndmake 4.3 documentation. I hope it ends this discussion once >and for all. Ok, I guess from ndmake semicolons do serve the intended puprose. However, I want to point out an inaccuracy in the quoted manual on this point. >> A. This is because MAKE starts each command in the current directory. This is the real reason why the semicolons are useful and necessary for doing cd's and expecting to see the result. >> command separator). In fact, since each command line is executed in >> its own shell, this is the only way to use DOS commands like "set" and >> "chdir" so that they have any effect. For example, doing "make x" This implies that cd is like set in that its effects are local to its own shell (command.com), which is not correct. -- Nathan Glasser fnord nathan@{mit-eddie.uucp, xx.lcs.mit.edu} "A tribble is the only love that money can buy." Presently there is insufficient evidence to conclude that tribbles spread AIDS.
kneller@cgl.ucsf.edu (Don Kneller) (10/22/87)
A possible bug is being discussed concerning NDMAKE and the way it handles "cd". I tried to remain as true to UNIX make as I could, so each shell line always starts in a separate subshell *in the current directory* (the directory NDMAKE started from). Thus to do a cd to another directory and get a directory listing you must do: (cd smodel; dir) In NDMAKE, the parentheses encaspulate a multiple-command shell line. Note that exactly the same syntax can be used with UNIX make. In UNIX, putting parentheses around a list of semicolon separated commands results in those commands being executed by the same subshell. In NDMAKE the parentheses are *required* around a multiple-command shell line. This is because several MSDOS utilities (notably MSC, LINK and LIB) use a semicolon to delineate the end of input and we want to use it as a command separator. As with UNIX make, in NDMAKE the use of semicolon as a command separator can be inhibited by preceeding it with a backslash: (echo foo\; echo bar) results in: foo; echo bar ----- Don Kneller UUCP: ...ucbvax!ucsfcgl!kneller INTERNET: kneller@cgl.ucsf.edu BITNET: kneller@ucsfcgl.BITNET