wjc@ho5cad.ATT.COM (Bill Carpenter) (12/08/89)
In article <12086@cbnews.ATT.COM> res@cbnews.ATT.COM (Robert E. Stampfli) writes:
res> have access to the ksh sources, so I use a ksh compiled from
res> these, and not the one that came with the distribution disks.
When I recently reloaded everything onto a new hard drive, I was
reminded of just how bizarre the distribution "ksh" is (even with the
fixdisk). Go ahead and ask it what version it is, and you'll get some
random piece of string from a source file instead an actual ksh
version ID. That's just a clue to what other wierdness to expect from
that particular a.out.
It's been a long time since I thought about this, but as I recall the
version that was available from THE STORE! was quite a bit saner than
the "official" stuff (even though perhaps an older version).
--
Bill Carpenter att!ho5cad!wjc or attmail!billres@cbnews.ATT.COM (Robert E. Stampfli) (12/08/89)
In article <1717@mtunb.ATT.COM> jcm@mtunb.UUCP (John McMillan) writes: > >1) Replacing SH with KSH is a serious breach of sanity. > KSH is ALMOST a superset of SH -- but the differences are VERY > REAL. It can waste hours or days for support people when folks > play this game. With all due respect for John McMillan and his useful postings, I must admit to having made ksh my standard /bin/sh years ago and, so far as I can tell, have experienced only one bad side effect: the % expansion to filename in vi broke. I heard rumors that spell and lint would break, but I did not experience this. The only thing that consistently bites me is that I use the "set -o nounset" option on my account, and this blows many scripts out of the water. I do have access to the ksh sources, so I use a ksh compiled from these, and not the one that came with the distribution disks. If anyone actually has an example of ksh breaking a command, etc, I would really like to hear about it. Please send me the particulars so I can try it on my system. -- Rob Stampfli / att.com!stampfli (uucp@work) / kd8wk@w8cqk (packet radio) 614-864-9377 / osu-cis.cis.ohio-state.edu!kd8wk!res (uucp@home)
rjg@sialis.mn.org (Robert J. Granvin) (12/08/89)
>With all due respect for John McMillan and his useful postings, I must admit >to having made ksh my standard /bin/sh years ago and, so far as I can tell, >have experienced only one bad side effect: > [...] >If anyone actually has an example of ksh breaking a command, etc, I would >really like to hear about it. Please send me the particulars so I can try >it on my system. It's not necessarily bad on the command level, though it could be, but it can be "bad" on the operational level, as an example earlier. To clarify, consider this two line sequence (this was the source of much "discussion" several months ago): cd /usr/spool/uucppublic find . -type f -mtime +30 -exec rm -f {} \; These lines are found in the /usr/lib/uucp/uudemon.day script of the original (Vanilla) UUCP distribution. Ignoring the original hype, paranoia, oopses, goofs and doomsaying that brought, the problem here is basically: What happens if /usr/spool/uucppublic goes away? If it's running under /bin/sh, nothing. You'll get a message in your mailbox, and the script will stop. If it's running under /bin/ksh, the cd will fail, you will stay in your defined "home" directory, and the find will continue. In the case of uucp, this will cause little or no damage. But consider if it was run as root (which I've also seen people use to run their UUCP crons(*))... Your home directory would be /, and nothing would be safe. It can also be counter argued that the success or failure of a cd should be checked, which is a valid point. But it's simply a misunderstanding, or lack of understanding, of how ksh differs from sh that can get you into trouble. Likely to happen? Probably not. Impossible to happen? Never. Although I'm quite interested in knowing how else ksh differs from sh. Some of this has already proven to be valuable knowledge. (*) No comments from this quarter about people who run their administrative crons under root and have ksh as default. Erf. :-) -- ________Robert J. Granvin________ INTERNET: rjg@sialis.mn.org ____National Computer Systems____ BITNET: rjg%sialis.mn.org@nic.mr.net __National Information Services__ UUCP: ...amdahl!bungia!sialis!rjg "Insured against Aircraft, including self-propelled missiles and spacecraft."
rs@cbnewsm.ATT.COM (robert.w.sanderman) (12/08/89)
In article <12086@cbnews.ATT.COM>, res@cbnews.ATT.COM (Robert E. Stampfli) writes: > If anyone actually has an example of ksh breaking a command, etc, I would > really like to hear about it. Please send me the particulars so I can try > it on my system. We had someone copy ksh over /bin/sh on a 3B2 on which I was trying to install Starlan. The sysadm command uses /bin/sh to process the install script and the one for Starlan definitely needs it. Using /bin/ksh caused it to look like it installed correctly but Starlan never worked. It took the better part of a week before we tracked down the problem. I got real good at loading floppies however (11 in the set) :-) Bob Sanderman
michael@stb.uucp (Michael Gersten) (12/09/89)
In article <12086@cbnews.ATT.COM> res@cbnews.ATT.COM (Robert E. Stampfli,55216,cb,1C315,6148604268) writes: >In article <1717@mtunb.ATT.COM> jcm@mtunb.UUCP (John McMillan) writes: >> >>1) Replacing SH with KSH is a serious breach of sanity. >> KSH is ALMOST a superset of SH -- but the differences are VERY >> REAL. It can waste hours or days for support people when folks >> play this game. > >With all due respect for John McMillan and his useful postings, I must admit >to having made ksh my standard /bin/sh years ago and, so far as I can tell, >... >If anyone actually has an example of ksh breaking a command, etc, I would >really like to hear about it. Please send me the particulars so I can try >it on my system. Ok. Here's a VERY real problem with ksh vs sh. Note that I have cross posted to news.software.b. (Oh yea--system is 3b1, running a moderately old ksh. Not too old, but not too recent either). I recently installed C news on my system. Played with inews (a nice little shell script), but could not get non-local groups to post correctly. I traced it to a line that calls sed to turn a '.' into a '\.' for passing to egrep; it was instead passing '\\.'. Turns out the line in the script had 4 backslashes; I trimmed it to 2. Worked fine. Then I ported rn. Worked fine. Pnews ran beautifully. Then I tried to followup an article. It didn't work. It was now substituting a '&' for the '.'; this was from the next character in the sed command that was being substituted (its a pretty hairy line). Some trials and tribulations later, I discovered that when ksh finds a shell script, it executes it itself; when system() or execvp() is called, it uses /bin/sh for shell scripts. They have slightly different rules for handling the '\\' sequence in scripts. So far ONLY C news inews breaks on this. Well, not quite. Configure (from rn) will core-dump its ksh. Yea, not just an error, but the shell dumps core. Never did trace that one down. Finally, there is the biggest difference I've found so far. This one bit me *HARD* when I started installing shell scripts that paid attention to EDITOR and VISUAL, neither of which was set anywhere in my system (/etc/profile, /etc/rc, ~/.profile, etc). EDITOR would be set to /bin/ed. Worse, this was NOT in the environment (printenv did NOT show it), but it WAS passed to shell scripts. So shell scripts would get a different environment than non-scripts. This is the biggest difference I've found so far. Michael
mmengel@cuuxb.ATT.COM (Marc W. Mengel) (12/13/89)
In article <2077@sialis.mn.org> rjg@sialis.mn.org (Robert J. Granvin) writes: >To clarify, consider this two line sequence (this was the source of >much "discussion" several months ago): > >cd /usr/spool/uucppublic >find . -type f -mtime +30 -exec rm -f {} \; >[...] >What happens if /usr/spool/uucppublic goes away? > >If it's running under /bin/sh, nothing.[...] under /bin/ksh, >the cd will fail, you [will remove $HOME, everything if root]. This is just a case of the -e flag not being turned on by default when running scripts in ksh; something that is easily configurable (at least if you have source), or easily put in your script, or in crontab. Since the -e flag is *not* documented as the default in plain old /bin/sh, you are better off explicitly turning it on if you rely on it, since other versions of /bin/sh might not have it on... So if your script read: set -e cd /usr/spool/uucppublic find . -type f -mtime +30 | xargs rm -f you wouldn't do the find if /usr/spool/uucppublic wasn't there in either shell, ever. -- Marc Mengel mmengel@cuuxb.att.com attmail!mmengel ...!{lll-crg|att}!cuuxb!mmengel
rjg@sialis.mn.org (Robert J. Granvin) (12/13/89)
In article <4365@cuuxb.ATT.COM> mmengel@cuuxb.UUCP (Marc W. Mengel) writes: |In article <2077@sialis.mn.org> rjg@sialis.mn.org (Robert J. Granvin) writes: |>To clarify, consider this two line sequence (this was the source of |>much "discussion" several months ago): |> |>cd /usr/spool/uucppublic |>find . -type f -mtime +30 -exec rm -f {} \; |>[...] |>What happens if /usr/spool/uucppublic goes away? |> |>If it's running under /bin/sh, nothing.[...] under /bin/ksh, |>the cd will fail, you [will remove $HOME, everything if root]. | |This is just a case of the -e flag not being turned on by default |when running scripts in ksh; something that is easily configurable |(at least if you have source), or easily put in your script, or |in crontab. Since the -e flag is *not* documented as the default |in plain old /bin/sh, you are better off explicitly turning it |on if you rely on it, since other versions of /bin/sh might not |have it on... | |So if your script read: | | set -e | cd /usr/spool/uucppublic | find . -type f -mtime +30 | xargs rm -f | |you wouldn't do the find if /usr/spool/uucppublic wasn't |there in either shell, ever. Of course, I can argue that if you have source and know enough to enable the -e option by default, or know enough to systematically go through your system and make sure that all scripts are "safe" under ksh and have any needed modifications, that you are _keenly_ aware of the damage a ksh for sh change could make, and probably wouldn't go through the trouble or bother... But, if you really wanted to... (Remember that the vast majority of users and even System Administrators can't tell you any differences between ksh and sh. You might find a surprising number of people who don't realize that ksh offers history and aliases. These are the people one needs to be most "concerned" about. Not the people with source who know all about it...) -- ________Robert J. Granvin________ INTERNET: rjg@sialis.mn.org ____National Computer Systems____ BITNET: rjg%sialis.mn.org@nic.mr.net __National Information Services__ UUCP: ...amdahl!bungia!sialis!rjg "Go ahead... be naughty. Save Santa the trip."