trevor@trevan.UUCP (trevor) (07/07/89)
Using Microport System V/AT and the korn shell for logins I have found if I execute /bin/sh and then execute pwd I get an error message pwd: cannot read .. . I suspect it is something to do with the fact that the Korn shell has its own internal pwd. When using crontab I also get a warning message commands will be executed using /bin/sh Is there anything wrong in changing the name of ksh to sh or is there any incompatability. thanks trevor
davidsen@sungod.crd.ge.com (William Davidsen) (07/11/89)
In article <372@trevan.UUCP> trevor@trevan.UUCP (trevor) writes: | | Using Microport System V/AT and the korn shell for logins | I have found if I execute /bin/sh and then execute pwd I get an | error message pwd: cannot read .. . I suspect it is something to do with ^^^^^^^^^^^^^^^^^^^ What are the permissions on the parent directory? May very well be a legitimate problem (although a new one to me). | Is there anything wrong in changing the name of ksh to sh or | is there any incompatability. I think you will find that certain shell scripts won't work. I can't remember if it was 'style' or some other text package, but it use "^" instead of "|" for pipes. Keep /bin/sh handy by another name if you rename. I just run ksh as login and leave sh as it came. bill davidsen (davidsen@crdos1.crd.GE.COM) {uunet | philabs}!crdgw1!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
les@chinet.chi.il.us (Leslie Mikesell) (07/12/89)
In article <372@trevan.UUCP> trevor@trevan.UUCP (trevor) writes: > Is there anything wrong in changing the name of ksh to sh or >is there any incompatability. Among other possible problems you will find that if you have any rc or cron commands of the form: su user -c command ksh will execute the .profile of the user before executing the command. This can cause trouble if there are interactive prompts. Les Mikesell
aeb@cwi.nl (Andries Brouwer) (07/15/89)
In article <372@trevan.UUCP> trevor@trevan.UUCP (trevor) writes: > ... > Is there anything wrong in changing the name of ksh to sh or >is there any incompatability. I have been bitten several times, especially when installing new versions of system software, by the fact that ksh does not search the PATH for each command, but remembers where the command was. (I.e., some commands, sometimes all commands, are tracked aliases. There is an option to make all commands tracked aliases, but none to switch off this `feature'.) In an environment where one may have test versions of the software in one directory, and later move this to the final destination, or where one may create private versions of software in one's own bin directory, it is really very annoying to have ksh run different commands than sh. I have even had ksh expand the first argument to nohup, in a situation where nohup was the name of a shell script of my own, and the first argument was not at all a command name. Thus: ksh is a beautiful shell, but incompatible with sh. I think it was a mistake to make tracked aliases the default - I much prefer correct actions above fast actions. -- Andries Brouwer -- CWI, Amsterdam -- uunet!mcvax!aeb -- aeb@cwi.nl
ekrell@hector.UUCP (Eduardo Krell) (07/19/89)
In article <8272@boring.cwi.nl> aeb@cwi.nl (Andries Brouwer) writes: >I have been bitten several times, especially when installing new >versions of system software, by the fact that ksh does not >search the PATH for each command, but remembers where the command >was. (I.e., some commands, sometimes all commands, >are tracked aliases. There is an option to make all commands >tracked aliases, but none to switch off this `feature'.) I believe all you have to do is change the value of $PATH to force ksh into unbinding all the tracked aliases. I use PATH=$PATH which doesn't change the value of $PATH, but makes ksh throw away the old bindings. Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {att,decvax,ucbvax}!ulysses!ekrell Internet: ekrell@ulysses.att.com
aeb@cwi.nl (Andries Brouwer) (07/21/89)
In article <11900@ulysses.homer.nj.att.com> ekrell@hector.UUCP (Eduardo Krell) writes: >In article <8272@boring.cwi.nl> aeb@cwi.nl (Andries Brouwer) writes: > >>I have been bitten several times by the fact that ksh does not >>search the PATH for each command, but remembers where the command >>was. (I.e., some commands, sometimes all commands, >>are tracked aliases. There is an option to make all commands >>tracked aliases, but none to switch off this `feature'.) > >I believe all you have to do is change the value of $PATH to >force ksh into unbinding all the tracked aliases. I use > >PATH=$PATH > >which doesn't change the value of $PATH, but makes ksh throw >away the old bindings. Yes, I am well aware of that. [But note that tracked aliases do not cease to be tracked, so the only way to get rid of tracked aliases is to say unalias grep; unalias cc; ... in my profile, listing all tracked aliases. However, which names are tracked aliases is not documented anywhere, so one needs the source to do this.] The problem is not getting ksh to execute any particular command, the problem is recognizing that there might be a problem. The problem is just that ksh does the wrong thing, and hence is not compatible with sh. Moreover, ksh quite unexpectedly does the wrong thing. When I did timing tests on two versions of grep I wasted my time because ksh ran the wrong grep. When I constructed a new version of nohup and tested it with `nohup pwd', I was very surprised getting error messages from the line printer daemon. But, you see, ksh thought that nohup was the standard nohup (while in fact it was a Bourne shell script), and expanded `pwd' into `print - $PWD', and thus my shell script subsequently ran print, calling lpr on a directory. (Yes, after the expansion ksh ran my nohup, not the standard one.) In each case you tell me that I could have avoided problems by saying PATH=$PATH, but with sh I have no problems, and need not avoid them. Thus, the `tracked aliases' misfeature of ksh burdens my memory with yet another thing to worry about. Since I otherwise am quite happy with ksh, I hacked the source and just removed all tracked alias stuff, creating my private, more reliable ksh. These tracked aliases were not invented because they are useful, but because they save a few milliseconds on each command that I give. However, one hour of wasted time wipes out the milliseconds gained in many years. Such a feature can best be deleted altogether, or, when people insist, given as an option, turned off by default. -- Andries Brouwer -- CWI, Amsterdam -- uunet!mcvax!aeb -- aeb@cwi.nl
rjd@occrsh.ATT.COM (Randy_Davis) (07/21/89)
In article <372@trevan.UUCP> trevor@trevan.UUCP (trevor) writes: ... | Is there anything wrong in changing the name of ksh to sh or |is there any incompatability. It will break the at command, among other things... When "at" saves your enviroment for subsequent job execution, it goes through and saves all of them. The problem with this is that when the at job is later executed, at tries to go through and restore all of the enviroment variables, including the ksh-specific ones, such as RANDOM, PPID, PWD, RANDOM, SECONDS, and _ (last command line). Now, at this moment I am not sure, but at least one of these causes the "at" job to crash when it is restoring the enviroment. It has been a while since I tried it - sorry if my memory is vague... Randy Davis UUCP: ...(att.att.com!)ocrjd.att.com!randy ...(att.att.com!)occrsh.att.com!rjd
williamt@athena1.Sun.COM (William A. Turnbow) (07/22/89)
In article <8282@boring.cwi.nl> aeb@cwi.nl (Andries Brouwer) writes: >These tracked aliases were not invented because they are useful, >but because they save a few milliseconds on each command that I >give. ----------- Not that I disagree with making it an option, but your above statement is inaccurate in a networked environment or if you have a long path. I have anywhere from 15 to 25 path components, all of which are remote mounts. Due to distance, heavy loading or just plain lost requests, searching all these directories can some times take several seconds (usually under 1-2 though). This is only an annoyance at the interactive level. However, when running shell scripts, if your executable that you are using alot is in one of the later directories, you are talking about a POTENTIALLY much greater period of time. -wat-
allbery@ncoast.ORG (Brandon S. Allbery) (07/22/89)
As quoted from <11900@ulysses.homer.nj.att.com> by ekrell@hector.UUCP (Eduardo Krell): +--------------- | In article <8272@boring.cwi.nl> aeb@cwi.nl (Andries Brouwer) writes: | >I have been bitten several times, especially when installing new | >versions of system software, by the fact that ksh does not | >search the PATH for each command, but remembers where the command | >was. (I.e., some commands, sometimes all commands, | >are tracked aliases. There is an option to make all commands | >tracked aliases, but none to switch off this `feature'.) | | I believe all you have to do is change the value of $PATH to | force ksh into unbinding all the tracked aliases. I use +--------------- Sure there's a way to get ksh to stop tracking: "set +o trackall". You must still use "PATH=$PATH" or "hash -r" to zap the current tracked aliases, but after the "set" you won't have to worry about it any more. ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@NCoast.ORG uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser (Send inquiries to rhg@NCoast.ORG, *not* to me! I'm just the resident guru.) * "ncoast" regenerates again! The 5th "ncoast", coming August 1 (stay tuned) *
GU.GEYMONT%SCIENCE.UTAH.EDU@wasatch.utah.edu (Rick Geymont) (07/23/89)
As far as the ksh stuff goes, your guess is as good as mine. However, UUCP will always give you the warning message when you run it from other than the Bourne Shell. I get the same thing from the C-Shell. Rick Geymont ----------------------------------------------------------------------------- Only the weak try to control. --- Rhondell ---