fox@marlow.uucp (Paul Fox) (09/05/88)
I have a problem with make and the c-shell. My login shell is the
cshell and here is a copy of my .cshrc:
------------------------------------------
if (! $?DEPTH) setenv DEPTH ""
setenv DEPTH ":$DEPTH"
set history=150
set path = ( . /usr/bin /bin /etc /usr/local/bin /usr/games /usr/lib /usr/lbin /usr/dbin )
alias h history
alias ls ls -spaCF
alias cd cd \!\* \; set prompt = '\[33m\[1m\($USER@sleepy\)`pwd`$DEPTH\ \[32m'
#
set cdpath = ( / $HOME)
#
alias f finger
alias cu cu -s 2400
alias cls echo '\[2J\[H'
alias sane stty sane echoe kill '^U' intr '^C' erase ''
alias GR /usr/local/bin/gr
alias nl nl -ba
alias nroff nroff -mm
alias sdiff sdiff -w80
#alias rps pscript \!\* \| rsh alice cat \\\> /dev/laser
alias rps pscript \!\* \| rsh alice lpr
alias rpr cat \!\* \| rsh alice lpr
alias man man \!\* \| more
alias lpr rsh alice lpr
alias which alias \| /usr/local/bin/which -i
------------------------------------------
On my Uport V.3, if you create the following makefile
fred:
cd .. ; date
and type 'make fred', you get the the date as expected, but you
also get an extra prompt. I've tried this under SunOS 4, and the problem
doesnt exist there. Is this a problem with the System 5 make ?
I also have this problem under Xenix. The problem has something to do
with the alias for 'cd'. The shell seems to be pattern sensitive
to the 'set prompt' in this alias. I think you can delete the other
alias's and the problem persists.
PLEASE CAN SOMEONE HELP ME...ITS DRIVING ME NUTS.
=====================
// o All opinions are my own.
(O) ( ) The powers that be ...
/ \_____( )
o \ |
/\____\__/ Tel: +44 628 891313 x. 212
_/_/ _/_/ UUCP: fox@marlow.uucpkarl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (09/12/88)
fox@marlow.uucp writes:
Is this a problem with the System 5 make ?
No, it's a problem in your setting of $prompt. You should set prompt
iff there already exists a prompt, i.e.,
if ($?prompt) then
alias cd 'chdir \!*; set prompt="$cwd> "'
endif
Otherwise, you're unconditionally introducing a prompt into a context
where none should exist. (And didn't exist, since csh knew whether it
was running interactively from a tty, and sets prompt only if so.)
--Karlguy@gorodish.Sun.COM (Guy Harris) (09/13/88)
> On my Uport V.3, if you create the following makefile > > fred: > cd .. ; date > > and type 'make fred', you get the the date as expected, but you > also get an extra prompt. I've tried this under SunOS 4, and the problem > doesnt exist there. Is this a problem with the System 5 make ? Arguably, yes. The S5 "make" uses the shell specified by the SHELL environment variable to execute commands. This is bogus, since it cause sany Makefile that uses Bourne shell constructs to fail when it is run by a user whose login shell is the C shell. The SunOS "make" always uses the Bourne shell to execute commands. You might try sticking SHELL=/bin/sh at the front of your Makefile to see if it fixes things.
mesard@bbn.com (Wayne Mesard) (09/13/88)
From article <21621@tut.cis.ohio-state.edu>, by karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste): > You should set prompt > iff there already exists a prompt, i.e., > if ($?prompt) then > alias cd 'chdir \!*; set prompt="$cwd> "' > endif > > Otherwise, you're unconditionally introducing a prompt into a context > where none should exist. (And didn't exist, since csh knew whether it > was running interactively from a tty, and sets prompt only if so.) Or more generally, put the following line at the top of your .cshrc file: if ($?prompt == 0) exit Since most users only need the stuff in .cshrc when they'll be typing to the shell. This speeds up programs which might invoke csh (such as make(1)) as well as dain bramaged shell C-shell scripts which don't have the -f option in their first line. -- void *Wayne_Mesard(); MESARD@BBN.COM BBN, Cambridge, MA
swilson%thetone@Sun.COM (Scott Wilson) (09/13/88)
In article <67870@sun.uucp> guy@gorodish.Sun.COM (Guy Harris) writes: >The SunOS "make" always uses the Bourne shell to execute commands. If there are no shell metacharacters, the command is invoked directly and no shell is involved. From the SunOS 4.0 make man page: The SHELL macro, when set to a single-word value such as /usr/bin/csh, indicates the name of an alternate shell to use. Note: make executes commands containing no shell meta- characters directly. Builtin commands, such as dirs in the C shell, are not recognized unless the command line includes a metacharacter (for instance, a semicolon). An interesting question is are there C shell metacharacters that are not Bourne shell metacharacters? And what if you wanted make to use a custom shell that had different metacharacters? Seems like make should always call the shell if it's specified to be something other than /bin/sh or /bin/csh. BTW, a quick look at the source suggests (to me) that make is looking for: # | = ^ ( ) ; & < > * ? [ ] : $ ` ' " \ as a shell metacharacter. -- Scott Wilson arpa: swilson@sun.com Sun Microsystems uucp: ...!sun!swilson Mt. View, CA "It's the end of the world as we know it, and I feel fine." -R.E.M.
guy@gorodish.Sun.COM (Guy Harris) (09/13/88)
> >The SunOS "make" always uses the Bourne shell to execute commands. > > If there are no shell metacharacters, the command is invoked directly > and no shell is involved. I knew that, but it's a minor detail, so I left it out of the discussion. Unless your shell is quite strange, commands involving no shell metacharacters should work the same way regardless of whether "make" runs them directly or whether they're run under the Bourne, C, Korn, ... shell (modulo bizarro and probably undesirable interactions with the way the shell sets the command's environment up, and thinks like that). > An interesting question is are there C shell metacharacters that are > not Bourne shell metacharacters? How about "{" and "}", as in "rm {foo,bar,bletch}.c"? This isn't the only problem; the Bourne and C shells have different syntaxes for some operations. For instance, if you want to run the command "foo" with both its standard output and standard error redirected to "bar", it's foo >bar 2>&1 in the Bourne shell, but foo >&bar in the C shell. In addition, some Makefiles include shell conditional constructs, and the syntax for those is quite different between the Bourne and C shells. > Seems like make should always call the shell if it's specified to be > something other than /bin/sh or /bin/csh. "make" should always call "/bin/sh" regardless of what SHELL says; otherwise, you run the risk of Makefiles working for person A (whose login shell is the Bourne shell) and failing for person B (whose login shell is the C shell) - or, for that matter, succeeding for person A (whose login shell is the Korn shell) and failing for person B (whose login shell is the Bourne shell), since the Korn shell is a superset of the Bourne shell. Users with shells that are "none of the above" can also find that other people's Makefiles blow up.
andrew@frip.gwd.tek.com (Andrew Klossner) (09/13/88)
> I have a problem with make and the c-shell. My login shell is the > cshell and here is a copy of my .cshrc: > ... > alias cd cd \!\* \; set prompt = '\[33m\[1m\($USER@sleepy\)`pwd`$DEPTH\ \[32m' > ... > On my Uport V.3, if you create the following makefile > > fred: > cd .. ; date > > and type 'make fred', you get the the date as expected, but you > also get an extra prompt. This is one of those well-known but undocumented csh problems. The solution is, in your .cshrc, put the "alias cd" and any setting of $prompt under if ($?prompt) then alias cd ... set prompt=... endif Csh only sets $prompt for an interactive shell. It's also a good idea to put other interactive-only work, like running tset or setting EDITOR, here, to speed up csh script processing (assuming you don't instead put it in .login). Although I'm a rabid csh user, it's my personal opinion that a "make" that doesn't always use /bin/sh (apparently this one depends on $SHELL) is broken. -=- Andrew Klossner (decvax!tektronix!tekecs!andrew) [UUCP] (andrew%tekecs.tek.com@relay.cs.net) [ARPA]
ok@quintus.uucp (Richard A. O'Keefe) (09/13/88)
In article <67925@sun.uucp> swilson@sun.UUCP (Scott Wilson) writes: >An interesting question is are there C shell metacharacters that are >not Bourne shell metacharacters? Are not "{", ",", and "}" C-shell metacharacters? E.g. "echo a{b,c,d}e" prints "abe ace ade".
awm@doc.ic.ac.uk (Aled Morris) (09/14/88)
In article <67967@sun.uucp>, guy@gorodish.Sun.COM (Guy Harris) writes: > > >The SunOS "make" always uses the Bourne shell to execute commands. [...] > > Seems like make should always call the shell if it's specified to be > > something other than /bin/sh or /bin/csh. > > "make" should always call "/bin/sh" regardless of what SHELL says; otherwise, > you run the risk of Makefiles working for person A (whose login shell is the > Bourne shell) and failing for person B (whose login shell is the C shell) In the past I worked on a HP-UX (h-pux? :-) system. Their version of make(1) runs the users shell (probably "SHELL" from envp) unless a _make_ variable called "SHELL" was set. All my Makefiles would begin SHELL = /bin/sh and portability was assured! :-) (this is from memory, no flames please...) Perhaps this is a system V make(1) feature? Aled Morris systems programmer mail: awm@doc.ic.ac.uk | Department of Computing uucp: ..!ukc!icdoc!awm | Imperial College talk: 01-589-5111x5085 | 180 Queens Gate, London SW7 2BZ #pragma "Opinions expressed are my own, not those of the University of London"
fox@marlow.uucp (Paul Fox) (09/15/88)
Once again thank you for all of you who answered my original question.
Here is another related question -- when make sees a complicated
command line with one of the magic characters present (eg ; * ? etc)
does it open a pipe to the appropriate shell and send each command upto
the ';' separately to the shell, or does it just assume the
the -e switch to the shell will work ?
=====================
// o All opinions are my own.
(O) ( ) The powers that be ...
/ \_____( )
o \ |
/\____\__/ Tel: +44 628 891313 x. 212
_/_/ _/_/ UUCP: fox@marlow.uucpguy@gorodish.Sun.COM (Guy Harris) (09/16/88)
> Perhaps this ("make" using the "make" variable SHELL to specify which > shell to use - gh) is a system V make(1) feature? Yes, it was introduced in either the System III or the System V "make". I'd call it a "misfeature", not a "feature", since it breaks existing Makefiles when run by users whose login shell isn't "/bin/sh". The reason why the environment variable SHELL affects the shell "make" uses is that the S3/S5 "make" imports environment variables and turns them into "make" variables. (If anyone cares to make the argument "The versions of UNIX AT&T ships only comes with one shell; why should they have worried about BSD's C shell?", I note that S5 has - and, I think, S3 had - the SHELL environment variable and, like every other reasonably sane version of UNIX, those versions let users have shells other than "/bin/sh", so this argument is not valid. It's not a BSD vs. S5 issue, or even a Bourne shell vs. C shell issue; those just happen to be the most obvious places where it could break things. Making things work only if SHELL is the Bourne shell or a look-alike is often the wrong thing to do; nevertheless, S3/S5 did it anyway - *vide* the stuff that's done in "/etc/profile", such as setting TZ. "/etc/profile" is not sourced if your shell isn't a Bourne shell look-alike; this not only screws C shell users, but UUCP accounts as well.) We took this misfeature out of the S5 "make", either when we added it (in SunOS 3.0, if I remember correctly) or some time after that; we did so precisely because it *did* break existing Makefiles.
nick@ccicpg.UUCP (Nick Crossley) (09/17/88)
In article <68616@sun.uucp> guy@gorodish.Sun.COM (Guy Harris) writes: >Yes, it was introduced in either the System III or the System V "make". I'd >call it a "misfeature", not a "feature", since it breaks existing Makefiles >when run by users whose login shell isn't "/bin/sh". > I personally like this feature/misfeature, as it allows me to invoke ksh. Certainly for makefiles which I intend to be portable, I only use sh commands, but for my own development I use commands/scripts which need ksh. Our site does not install ksh as sh, and I cannot reliably use the #! mechanism as ksh lives in different places on different machines. (Yes, I know that is silly, but that is how it currently is.) Anyway, #! would only allow ksh scripts, not ksh commands directly from the make file. This is also why I would say that any version of make which attempts to be 'efficient' and exec directly a rule line which does not include shell meta-characters is broken; such versions of make do not take account of new shells such as ksh, and even then would have to be kept in step with the evolution of sh. -- <<< standard disclaimers >>> Nick Crossley, CCI, 9801 Muirlands, Irvine, CA 92718-2521, USA Tel. (714) 458-7282, uucp: ...!uunet!ccicpg!nick
guy@gorodish.Sun.COM (Guy Harris) (09/17/88)
> I personally like this feature/misfeature, as it allows me to invoke ksh. Fine. Plenty of other people don't like it, because it causes makefiles to exhibit incorrect behavior when invoked by users with shells other than the Bourne shell. There is, admittedly, a workaround/fix for this - namely, putting "SHELL=/bin/sh" at the beginning of all your makefiles - but it's still kind of impolite to require people to change their makefiles in this fashion, especially if you don't tell them they have to do this. Now, maybe you rate your convenience above the convenience of those other people. I suspect those other people would rate things differently, and in general "don't gratuitously break things" is considered a good rule. > Certainly for makefiles which I intend to be portable, I only use sh > commands, but for my own development I use commands/scripts which need > ksh. I tend to doubt that there are many Makefiles or shell scripts that absolutely *NEED* ksh. There are many that might be more *convenient* to write using "ksh", but I suspect they can all be done without Korn shell features. I suggest you learn to do your development without using those features in your scripts. I use the Korn shell as my shell, but I make a point of *not* using Korn shell features in scripts and the like, because I have no idea whether somebody else will have the Korn shell available to them. The fact that some feature might be convenient to you hardly proves that it is, to quote your summary line, "Not a misfeature".
cquenel@polyslo.CalPoly.EDU (Rodent Of Unusual Size) (09/18/88)
In article <68801@sun.uucp> guy@gorodish.Sun.COM (Guy Harris) writes: > There is, admittedly, a workaround/fix for this - namely, >putting "SHELL=/bin/sh" at the beginning of all your makefiles From a software engineering point of view, ignoring for the moment what breaks and the inconvenience involved, the above is the most appealing to me. each line of a makefile executes "as if the shell executed it" (some shell), and it makes sense to declare at the top of the Makefile, what program is to be used as an interpreter for each line. I am NOT saying "everyone should do this", but it does seem like a safe thing to do. I'm also not saying this is an excuse for careless "make" implementations, just giving my opinion. (Sheesh, I don't think (Sheesh, I don't thin THAT needs a disclaimer, eh ?) --chris ------------------------------------------------------------------------------- | Chris Quenelle | Smart Mailers -> cquenel@polyslo.CalPoly.EDU | | Computer Systems Lab | Dumb Mailers -> !ucbvax!voder!polyslo!cquenel | | Cal Poly State Univ. |-------------------------------------------------| | San Luis Obispo, CA 93407 | /earth is 98% full, please delete anyone you can| -------------------------------------------------------------------------------
guy@gorodish.Sun.COM (Guy Harris) (09/19/88)
> > There is, admittedly, a workaround/fix for this - namely, > >putting "SHELL=/bin/sh" at the beginning of all your makefiles > > From a software engineering point of view, ignoring for the moment > what breaks and the inconvenience involved, the above is the most appealing > to me. The problem is that the article that started this discussion off was one complaining about something breaking, so "ignoring for the moment what breaks" avoids the whole point of the discussion! Yes, if everybody had always stuck "SHELL=/bin/sh" at the front of their Makefiles, it would have arguably been completely OK to enhance "make" in the way it was enhanced. Unfortunately, since this particular "make" "enhancement" wasn't present in older versions of "make", people generally *didn't* put "SHELL=/bin/sh" at the front of their Makefiles, so things *did* break when this "enhancement" was added.
chris@cetia.UUCP (Chris Bertin) (09/19/88)
In article <24946@ccicpg.UUCP>, nick@ccicpg.UUCP (Nick Crossley) writes: > In article <68616@sun.uucp> guy@gorodish.Sun.COM (Guy Harris) writes: > >Yes, it was introduced in either the System III or the System V "make". I'd > >call it a "misfeature", not a "feature", since it breaks existing Makefiles > >when run by users whose login shell isn't "/bin/sh". > > > > I personally like this feature/misfeature, as it allows me to invoke ksh. If 'make' had been modified to get its shell from a different variable (say 'MAKESHELL', for example), no existing makefiles would have been broken and you would still be able to use a different shell. It is a misfeature. Chris -- Chris Bertin | CETIA | 150, Av Marcelin Berthelot, Z.I. Toulon-Est +33(94)212005 | 83088 Toulon Cedex, France Ext: 239 | inria!cetia
nick@ccicpg.UUCP (Nick Crossley) (09/20/88)
In article <68801@sun.uucp> guy@gorodish.Sun.COM (Guy Harris) writes: >Fine. Plenty of other people don't like it, because it causes makefiles to >exhibit incorrect behavior when invoked by users with shells other than the >Bourne shell. There is, admittedly, a workaround/fix for this - namely, >putting "SHELL=/bin/sh" at the beginning of all your makefiles - but it's still >kind of impolite to require people to change their makefiles in this fashion, >especially if you don't tell them they have to do this. > This is not necessay, because SysV make also imports all environment variables as make variables. Thus one can write :- make SHELL=/bin/sh ... or SHELL=/bin/sh make for one-off makes, and 'alias Make=<one of the above>' for other occasions. The -e flag to make (environment values override local settings) can also be useful. >Now, maybe you rate your convenience above the convenience of those other >people. I suspect those other people would rate things differently, and in >general "don't gratuitously break things" is considered a good rule. This is a valid argument against any change, but since the 'fix' is so trivial, I do not consider it overwhelming in this case. >I tend to doubt that there are many Makefiles or shell scripts that absolutely >*NEED* ksh. There are many that might be more *convenient* to write using >"ksh", but I suspect they can all be done without Korn shell features. > >I suggest you learn to do your development without using those features in your >scripts. I use the Korn shell as my shell, but I make a point of *not* using >Korn shell features in scripts and the like, because I have no idea whether >somebody else will have the Korn shell available to them. If I were to do this, why should I use the Korn shell at all? Why should we ever change and enhance anything? Of course I *can* do anything with sh, but some things are *much* easier to write using ksh. My reasons for using ksh are not just the interactive features (command editing and history, etc.); I switched from sh to ksh partly because of the improved script facilities, arithmetic and bug fixes in features like functions. The one point I would agree on is that it is sometimes unfortunate that the environment value used is just 'SHELL', as that also affects the shell launched by vi, etc. I would like for that always to be ksh, but for make to use sh sometimes. Currently I use a Make alias as above, but a better solution would be for make to look for the environment variable 'MAKESHELL', and default to 'SHELL' (or /bin/sh if you insist) if that did not exist. In fact the latter solution should satisfy both of us, should it not? -- <<< standard disclaimers >>> Nick Crossley, CCI, 9801 Muirlands, Irvine, CA 92718-2521, USA Tel. (714) 458-7282, uucp: ...!uunet!ccicpg!nick
swilson%thetone@Sun.COM (Scott Wilson) (09/20/88)
>Unfortunately, since this particular "make" "enhancement" >wasn't present in older versions of "make", people generally *didn't* put >"SHELL=/bin/sh" at the front of their Makefiles, so things *did* break when >this "enhancement" was added. On no, maybe it's time for an ANSI comittee to standardize make, and six years later we'd have ANSI make.... :-) -- Scott Wilson arpa: swilson@sun.com Sun Microsystems uucp: ...!sun!swilson Mt. View, CA "And the fool loves war, and the gentle die." -The Call "What's so funny about peace, love, and understanding." -Elvis Costello
gwyn@smoke.ARPA (Doug Gwyn ) (09/20/88)
In article <68932@sun.uucp> swilson@sun.UUCP (Scott Wilson) writes: >On no, maybe it's time for an ANSI comittee to standardize make, ... An IEEE committee is already working on it.
allbery@ncoast.UUCP (Phil Smith) (09/20/88)
As quoted from <29592@bbn.COM> by mesard@bbn.com (Wayne Mesard): +--------------- | From article <21621@tut.cis.ohio-state.edu>, by karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste): | > You should set prompt | > iff there already exists a prompt, i.e., | > if ($?prompt) then | > alias cd 'chdir \!*; set prompt="$cwd> "' | > endif | | Or more generally, put the following line at the top of your .cshrc | file: | | if ($?prompt == 0) exit +--------------- Uh, that may work on recent BSD csh'es, but on mine and most likely in the ISC csh, it'll cause both .cshrc and the csh to exit -- you won't even be able to log in! ++Brandon -- Brandon S. Allbery, uunet!marque!ncoast!allbery DELPHI: ALLBERY For comp.sources.misc send mail to ncoast!sources-misc "Don't discount flying pigs before you have good air defense." -- jvh@clinet.FI
guy@gorodish.Sun.COM (Guy Harris) (09/20/88)
> This is not necessay, because SysV make also imports all environment > variables as make variables. Which is part of the problemn in the first place.... > Thus one can write :- > > make SHELL=/bin/sh ... > or SHELL=/bin/sh make > > for one-off makes, and 'alias Make=<one of the above>' for other occasions. > The -e flag to make (environment values override local settings) can also be > useful. Again, not in this case; the whole problem is that the environment variable has an undesired value! Obliging users to have an alias for "make", or to type either of the two aforementioned constructs, is not all that much better than obliging them to change their Makefiles. The whole point is that things that used to work don't work any more, and the only argument for breaking things that appears to have been offered is that users can use Korn shell constructs in their Makefiles. Big deal. > If I were to do this, why should I use the Korn shell at all? Because it has improved interactive features. > Why should we ever change and enhance anything? Because there are some cases where the enhancements are either 1) sufficiently widely available that you can get away with blowing off systems that don't have them or 2) sufficiently useful that you can justify blowing off systems that don't have them. Since the Korn shell is not part of any AT&T or Berkeley UNIX distribution, I have reason to believe that it is not widely enough available to justify 1), and I haven't run across any cases where its features are so useful that I can justify 2). > ... but a better solution would be for make to look for the environment > variable 'MAKESHELL', and default to 'SHELL' (or /bin/sh if you insist) > if that did not exist. In fact the latter solution should satisfy both of > us, should it not? As long as it defaults to "/bin/sh", yes. Unfortunately, AT&T didn't implement it that way.
henry@utzoo.uucp (Henry Spencer) (09/21/88)
In article <68932@sun.uucp> swilson@sun.UUCP (Scott Wilson) writes: >On no, maybe it's time for an ANSI comittee to standardize make, and six >years later we'd have ANSI make.... :-) The Posix 1003.2 bunch at IEEE are tackling this, I believe. I don't envy them. -- NASA is into artificial | Henry Spencer at U of Toronto Zoology stupidity. - Jerry Pournelle | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
dce@mips.COM (David Elliott) (09/27/88)
In article <128@cetia.UUCP> chris@cetia.UUCP (Chris Bertin) writes: >In article <24946@ccicpg.UUCP>, nick@ccicpg.UUCP (Nick Crossley) writes: >> >> I personally like this feature/misfeature, as it allows me to invoke ksh. > >If 'make' had been modified to get its shell from a different variable (say >'MAKESHELL', for example), no existing makefiles would have been broken and >you would still be able to use a different shell. It is a misfeature. This still doesn't make it. If I write my makefile such that is requires sh and you set MAKESHELL to '/bin/csh', there's still a problem. It's even worse if you are some influential customer of mine and you decide to force the issue ("Well, things shouldn't break just because I change my MAKESHELL variable, so you have to fix all 759 makefiles in your source"). The only obviously correct solution is to say that make defaults to using sh, and will use an alternate shell if specified in the makefile itself. After all, the makefile is written with a shell in mind, so adding the assignment of SHELL if it's not the default makes the makefile "self-documenting". -- David Elliott dce@mips.com or {ames,prls,pyramid,decwrl}!mips!dce