stenkvist@lne.kth.se (11/20/90)
I'm trying to get SKSH (the Unix like shell ) to work on my Amiga, but there seems to be a bug when used together with the A590 harddisc. When i start SKSH it newer alters the path. I use 'path -add ......' in the .skshrc file but the path always remain as '.,c:' or something. The ONLY way I found to make the path command work is to execute the Check_1.6SKSH command. It works even if I type Ctrl-c at the start of execution. This was all very confusing so I tried to disconnect the hard drive and start from a ordinar disc. This worked fine, so I connected the hard drive again and booted from the sane disc, and the problem was back. ( i've tried this for some times and it almost works the same. ) Is this a bug in SKSH or in the A590 or what ? . The version of SKSH I.ve tried is 1.6 alfa.
jesup@cbmvax.commodore.com (Randell Jesup) (11/21/90)
In article <0093FFDD.98022880@lne.kth.se> stenkvist@lne.kth.se writes: >I'm trying to get SKSH (the Unix like shell ) to work on my Amiga, but there > seems to be a bug when used together with the A590 harddisc. When i start > SKSH it newer alters the path. ... > This was all very confusing > so I tried to disconnect the hard drive and start from >a ordinar disc. This worked fine, The SKSH you're using must have a problem with NULL pointers. Some versions of the A590 roms put values in location 0, and SKSH must not be checking for NULL before dereferencing pointers. Note that any program that dereferences NULL is incorrect and is liekly to break if for some reason location 0 is non-0. There is NO guarantee that location 0 will be 0, and never has been (see the earlier discussion here on that). The "enforcer" utility catches references to 0 (as well as other low and illegal memory accesses). -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup Thus spake the Master Ninjei: "If your application does not run correctly, do not blame the operating system." (From "The Zen of Programming") ;-)
phil@adam.adelaide.edu.au (Phil Kernick) (11/21/90)
I have found what I also believe to be a bug in SKsh. I have my path set to ".,lc:,uucp:c" with the command compress in uucp:c and the command touch in lc: now I go into a directory with an executable called compress and an executable called touch. if I type compress it uses my compress in the current directory. if I type touch it uses touch in the lc: directory. Both are executable, and which tells me it should execute the command from the current directory. if I use ./touch it works. any ideas? Phil. -- Phil Kernick EMail: phil@adam.adelaide.edu.au Departmental Engineer Phone: +618 228 5914 Dept. of Psychology Fax: +618 224 0464 University of Adelaide Mail: GPO Box 498 Adelaide SA 5001
ked01@ccc.amdahl.com (Kim DeVaughn) (11/22/90)
In article <phil.659145660@adam.adelaide.edu.au> phil@adam.adelaide.edu.au (Phil Kernick) writes: > > I have found what I also believe to be a bug in SKsh. > > I have my path set to > > ".,lc:,uucp:c" > > with the command compress in uucp:c and the command touch in lc: > > now I go into a directory with an executable called compress and > an executable called touch. > > if I type compress it uses my compress in the current directory. > if I type touch it uses touch in the lc: directory. > > Both are executable, and which tells me it should execute the > command from the current directory. > > if I use ./touch it works. any ideas? This sounds precisely like what will happen if you made lc:touch resident at some point. The resident list used by SKsh gets searched before the path spec. Use "resident" to see if it's on the list. This is assuming you have disabled the builtin "touch" command (with an "unset -b touch" cmd, or used something like "alias touch $(which touch)", etc), and really are executing the lc:touch when you think you are (and not the builtin). What do "whence touch" and "which touch" tell you? /kim -- UUCP: kim@uts.amdahl.com -OR- ked01@juts.ccc.amdahl.com or: {sun,decwrl,hplabs,pyramid,uunet,oliveb,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 BIX: kdevaughn GEnie: K.DEVAUGHN CIS: 76535,25
koren@hpfcdc.HP.COM (Steve Koren) (11/22/90)
> I have found what I also believe to be a bug in SKsh. > I have my path set to > ".,lc:,uucp:c" > with the command compress in uucp:c and the command touch in lc: > now I go into a directory with an executable called compress and > an executable called touch. > if I type compress it uses my compress in the current directory. > if I type touch it uses touch in the lc: directory. I bet it doesn't! See below... > Both are executable, and which tells me it should execute the > command from the current directory. > if I use ./touch it works. any ideas? Yup. SKsh has a builtin called touch which takes precidence over any external binary of that name. You can change this multiple ways; one is to alias touch to $(which touch). Another is to "unset" it as a builtin. When you said "./touch" you told it to use the one in the current directory, ignoring any builtin or other binary elsewhere in the path. - steve
koren@hpfcdc.HP.COM (Steve Koren) (11/22/90)
> >I'm trying to get SKSH (the Unix like shell ) to work on my Amiga, but there > > seems to be a bug when used together with the A590 harddisc. When i start > > SKSH it newer alters the path. > > This was all very confusing > > so I tried to disconnect the hard drive and start from > >a ordinar disc. This worked fine, > The SKSH you're using must have a problem with NULL pointers. Some > versions of the A590 roms put values in location 0, and SKSH must not be > checking for NULL before dereferencing pointers. Note that any program that If indeed this is the problem it is certainly a bug in SKsh. (As Randell mentioned, dereferencing null pointers is not wise). However, I'm not yet entirely convinced this is the cause of the problem for several reasons I won't discuss here. What happens if you explicitly set the PATH variable instead of using the shell function? Send me mail and we will try to resolve the problem... - steve
stenkvist@lne.kth.se (11/25/90)
Hi After some testing I'm quit sure about these B*GS in SKSH. 1. If address 0 keeps a value other than 0 (when startinh SKSH) and especially if the value can be interpreted as string such as "gdos" (this is the case with some of the A590 ROM:s such as mine ) the PATH function will NOT work. Also if you try to dir (I'm not sure about ls ) you will recieve a visit from from our god old G*RU. 2. Place some value in address 0 such as $47,$27,$52,$27.Now type echo $IBM ( or some other nonexisting variable name ). The text GURU will appear. A null pointer is interpreted as a four character string. Since Exec-base usualy starts with $00 the string will not be longer than 4 bytes ( but since 68000 only cares about 3 bytes in the address you actually can change this without GURUing ). This may not seem so alarming since this is all reading of address 0 but... 3. While having some non null value at address 0 type a start of a filename that exists in the path. Use name completion (tab) to fill in name. SKSH now owerwrite address 0, Urrrghhh. The easiest way to see this is using metascope's memory-window and poking around. ( I used some simple hardware to detect reads and writes of address 0.) . SKSH is by no means the only program that reference address 0, there seems to be a address-0-read when pushing a key. At last, I wrote an AREXX program to compile the current file in CED with Benchmark Modula-2 by ADDRESS'ing SKSH and sending the command to its AREXX-port. This script always works one time but not more. The second time it freeze CED and REXX and I must reboot. Is this something you've noticed ? I hope those observations I've made can make a good product even better. Thank you for supplying it at the first time. Anders Stenkvist Lm ERICSSONS V. 3 S-126 37 HAGERSTEN Tel. +08-454079
koren@hpfcdc.HP.COM (Steve Koren) (11/27/90)
> After some testing I'm quit sure about these B*GS in SKSH. > 1. If address 0 keeps a value other than 0 (when startinh SKSH) > and especially if the value can be interpreted as string such as [several null pointer related bugs deleted]. I will add these to my bug list (which will become Kim's bug list very shortly now). BTW, the best way to report bugs is to email them to me (or Kim DeVaughn after last week). They stand a good chance of being overlooked when posted to the net as I, and possibly Kim as well, are in the habit of occassionally skipping large chunks of c.s.a[.*] just for time reasons. RE: null pointers; I haven't done any dereferencing of null pointers *on purpose*. I suppose a few might have slipped in by accident. I have had several people report the file completion problem, but I believe this to be the *only* place where location zero is written to. I'm sure Kim will look into this; it is a fairly serious problem. There may be several others where location zero is read from; these tend to be found at a slower rate than the other type. But both need to be fixed. Thanks for the reports; they always help. - steve