ram@kepler.unh.edu (Richard A Messner) (06/15/91)
I have encountered the above error ('Can't execute "J" - Error #000:216')
several times when trying to execute precompiled binaries for OSK. There
is no specific binary that gives this problem. They all seem to do it unless
they have been compiled on my machine (for example, the binary for C-Kermit
on smilodon.cs.wisc.edu causes this error). Does anyone know what the problem
is? I can't find a file named J anywhere in the standard directories.
The system in question is a Motorola MVME-133A-20 running Professional
OS-9/68020 version 2.2. Thanks.kdarling@hobbes.catt.ncsu.edu (Kevin Darling) (06/15/91)
ram@kepler.unh.edu (Richard A Messner) writes: >I have encountered the above error ('Can't execute "J" - Error #000:216') >several times when trying to execute precompiled binaries for OSK. There >is no specific binary that gives this problem. They all seem to do it unless >they have been compiled on my machine [...] This one gets everyone at times :-). As you know, when the shell executes a command line, it looks first in memory for the module... then in your current execution directory (usually /dd/cmds)... then it looks for an ascii shell script in your current data directory. That last scenario is the culprit. When you compile your own binaries, you're probably letting them default to ending up in your execution dir. No problem there. But when you download, you're probably leaving a file in your current data directory and trying to call it by name from there. Thus by the time the shell looks there, it thinks it must be a script. Now, the first bytes in a module header are $4A FC, right? The FC serves as a delimiter, and $4A = "J". So shell tries to execute the command "J" according to the "script file" it just found :-) :-). And since it can't find "J", you get this bogus (not really) error. Solution: set the exec attributes and copy the file to your cmds dir... or, use a full pathname to call it (eg: /dd/downloads/newcmd ). best - kevin <kdarling@catt.ncsu.edu>
jejones@mcrware.UUCP (James Jones) (06/15/91)
In article <1991Jun14.202821.20308@unhd.unh.edu> ram@kepler.unh.edu (Richard A Messner) writes: >I have encountered the above error ('Can't execute "J" - Error #000:216') >several times when trying to execute precompiled binaries for OSK. There >is no specific binary that gives this problem. They all seem to do it unless >they have been compiled on my machine (for example, the binary for C-Kermit >on smilodon.cs.wisc.edu causes this error). Does anyone know what the problem >is? I can't find a file named J anywhere in the standard directories. > >The system in question is a Motorola MVME-133A-20 running Professional >OS-9/68020 version 2.2. Thanks. Check the attributes of the files you're trying to execute. The "can't execute 'J'" message is from the shell, which, after trying other possibil- ities, is trying to run the executable as a shell script! (Dump the file and see what the first byte looks like. :-) You should set the execute attributes of the file and try again. James Jones
balmer@urz.unibas.ch (06/15/91)
In article <1991Jun14.202821.20308@unhd.unh.edu>, ram@kepler.unh.edu (Richard A Messner) writes: > I have encountered the above error ('Can't execute "J" - Error #000:216') > several times when trying to execute precompiled binaries for OSK. There > is no specific binary that gives this problem. They all seem to do it unless > they have been compiled on my machine (for example, the binary for C-Kermit > on smilodon.cs.wisc.edu causes this error). Does anyone know what the problem > is? I can't find a file named J anywhere in the standard directories. > > The system in question is a Motorola MVME-133A-20 running Professional > OS-9/68020 version 2.2. Thanks. You have to place the executable file in your default execution directory (you max change this with the chx command) or set the directory, in which your binary resides, in the environment variable PATH. You could alternally load the file with load -d filename prior to execution. J is the first byte of all OS-9 executables, dump a few and you'll see.. - Marc BTW: Error 216 means "File not found"
ww0n+@andrew.cmu.edu (Walter Lloyd Wimer III) (06/18/91)
kdarling@hobbes.catt.ncsu.edu (Kevin Darling) writes: > And since it can't find "J", you get this bogus (not really) error. Hmmmm. . . . Someone should write a real executable program named "J" which sits in the execution directory and prints out an appropriate error message when invoked. . . . ;-) Walt
manning@halley.tmc.edu (Arthur T. Manning) (06/18/91)
I've also encountered this stupid error when downloading code and forgetting to put ftp in binary mode. -- Arthur T. Manning <manning@halley.est.3m.com> 3M Center 518-1 St Paul MN 55144-1000 \___/______ ph. 612 733-4401 fax 612 736-3122 __ / _ _ _ \ Allin1--> <MANNING @MRGATE @EST780> (_/_/_/ / / /_/ <><
balmer@urz.unibas.ch (06/19/91)
In article <1991Jun18.033225.12476@mmm.serc.3m.com>, manning@halley.tmc.edu (Arthur T. Manning) writes: > I've also encountered this stupid error when downloading code and forgetting > to put ftp in binary mode. > > -- > Arthur T. Manning <manning@halley.est.3m.com> > 3M Center 518-1 St Paul MN 55144-1000 \___/______ > ph. 612 733-4401 fax 612 736-3122 __ / _ _ _ \ > Allin1--> <MANNING @MRGATE @EST780> (_/_/_/ / / /_/ <>< Whenever the u-ware OS-9 shell tries to execute a file (programs are files...) it searches in the current execution directory. If a file is not found in it, the shell then searches every directory in the environment variable PATH for the file. And at last it looks in the current directory for a shell-script (not for a binary, executable file!). The shell tries to execute the "J" because every OS-9 programs begins with it. Someone proposed to write a program called "J" which would be executed in this case. The programm J will actually execute, the problem is that the shell tries to execute the next bytes of the binary file. You then get an error message like "Error 216: can't execute verflow". The best solution is, to put your directory in the environment variable PATH, so all binaries will execute. - Marc
kdarling@hobbes.catt.ncsu.edu (Kevin Darling) (06/19/91)
balmer@urz.unibas.ch writes: >Someone proposed to write a program called "J" which would be executed in >this case. The program J will actually execute, the problem is that the >shell tries to execute the next bytes of the binary file. You then get an >error message like "Error 216: can't execute verflow". Good point. The shell will execute "J", and then try to use the next bytes (after the max readln point, or after a $0D seen as readln delimiter) in the originally named binary file (which shell thought was a script file) as a new script line. This brings up a neat trick with shell scripts tho. The thing to remember is that whenever a script line is executed, the standard input of the called program (assuming no "<" redirection is done) is the file itself... which in this case is the binary module! Thus the program called "J" has a standard input conduit to the binary file. Now all it has to do is to Seek its standard input path (0) to the end of the binary, and voila... when J ends, its parent shell thinks the "script" is at the end of file and exits. In BASIC, such a program would be... PROCEDURE J DIM modsize:INTEGER SEEK #0,4 \ (* seek to module size location in header GET #0,modsize \ (* read in module size SEEK #0,modsize-1 \ (* seek to end of module/"file" PRINT "You are trying to execute a module" PRINT "from within your current data dir " END The J program could even look up the name of the target binary, and perhaps load and/or execute it. This standard input trick also allows you to write commands which loop and do other "goto"-ish moves within a script file... by doing a Seek to wherever you'd like your calling shell to continue from. The simplest example is a program which repeats the script file: PROCEDURE rewind SEEK #0,0 END Put that at the end of your script, and it'll execute over and over. best - kevin <kdarling@catt.ncsu.edu>
pete@wlbr.imsd.contel.com (Pete Lyall) (06/19/91)
Kevin Darling suggest having the 'J' command eat up all of the
standard input... a good suggestion (Kev - where have I seen that
before.. grin)...
Another alternative... If the OSK shell works like the OS9/6809 shell,
when a procedure file is run, a child shell is forked from the
original shell with its standard input redirected from the alleged
script/procedure file. The 'J' command could simply get a copy of its
process descriptor (F$gprdsc, or whatever), determine its parent's
process ID (the secondary shell's ID), and it could send a KILL
signal, terminating the erroneously spawned 'procedure' shell.
Pete
--
Pete Lyall [GTE] Compuserve: 76703,4230 Internet: pete@wlbr.imsd.contel.com
UUCP: {hacgate,jplgodo,voder}!wlbr!pete
"... So I picked up my pride from beneath the pay phone, and combed his breath
right outta my hair. And sometimes, it's not so easy ..." J. Hendrix/My Friendtony@mwuk.UUCP (Tony Mountifield) (06/19/91)
In article <1991Jun18.184533.1648@urz.unibas.ch> balmer@urz.unibas.ch writes: > Someone proposed to write a program called "J" which would be executed in > this case. The programm J will actually execute, the problem is that the > shell tries to execute the next bytes of the binary file. You then get an > error message like "Error 216: can't execute verflow". This wouldn't happen if the program called "J" returned a non-zero exit status (e.g. 1). That would cause the shell to stop reading the "script". -- Tony Mountifield. | Microware Systems (UK) Ltd. MAIL: tony@mwuk.uucp | Leylands Farm, Nobs Crook, INET: tony%mwuk.uucp@ukc.ac.uk | Colden Common, WINCHESTER, SO21 1TH. UUCP: ...!mcsun!ukc!mwuk!tony | Tel: 0703 601990 Fax: 0703 601991 **** OS-9, OS-9000 Real Time Systems **** MS-DOS - just say "No!" ****
blarson@blars (06/20/91)
In article <1991Jun19.063541.16459@wlbr.imsd.contel.com> pete@wlbr.imsd.contel.com (Pete Lyall) writes: >Kevin Darling suggest having the 'J' command eat up all of the >standard input... >send a KILL >signal [to the parent], terminating the erroneously spawned 'procedure' shell. Why not just exit with a status of 1? (See previous discussion about how this terminates the shell procedure with no message.) -- blarson@usc.edu C news and rn for os9/68k! -- Bob Larson (blars) blarson@usc.edu usc!blarson Hiding differences does not make them go away. Accepting differences makes them unimportant.
kdarling@hobbes.catt.ncsu.edu (Kevin Darling) (06/20/91)
blarson@blars writes: > >Why not just exit with a status of 1? (See previous discussion about how this >terminates the shell procedure with no message.) But...but...but, Bob! That's too easy! :-) :-) Jeeeez. And you don't learn any neat tricks that way, either. <grinning> regards - kev <kdarling@catt.ncsu.edu>
balmer@urz.unibas.ch (06/20/91)
In article <1991Jun19.063541.16459@wlbr.imsd.contel.com>, pete@wlbr.imsd.contel.com (Pete Lyall) writes: > Kevin Darling suggest having the 'J' command eat up all of the > standard input... a good suggestion (Kev - where have I seen that > before.. grin)... > > Another alternative... If the OSK shell works like the OS9/6809 shell, > when a procedure file is run, a child shell is forked from the > original shell with its standard input redirected from the alleged > script/procedure file. The 'J' command could simply get a copy of its > process descriptor (F$gprdsc, or whatever), determine its parent's > process ID (the secondary shell's ID), and it could send a KILL > signal, terminating the erroneously spawned 'procedure' shell. > > Pete > > -- > Pete Lyall [GTE] Compuserve: 76703,4230 Internet: pete@wlbr.imsd.contel.com > UUCP: {hacgate,jplgodo,voder}!wlbr!pete > "... So I picked up my pride from beneath the pay phone, and combed his breath > right outta my hair. And sometimes, it's not so easy ..." J. Hendrix/My Friend I suggest the following: The program J seeks to the beginning of its standard input, then loads his standard input to a module (or saves it to temporary file) and tries to execute the module or the temp. file. I did not try it, but I'm sure we could get this running. - Marc
pete@wlbr.imsd.contel.com (Pete Lyall) (06/21/91)
Exiting with a '1' status is probably easier. I was thinking that the
shell can be told to ignore an errant process and continue (-x in 6809
land), but in this one case, the 'procedure' shell was invoked
accidentally, and wouldn't have been told to ignore errors.
Pete
--
Pete Lyall [GTE] Compuserve: 76703,4230 Internet: pete@wlbr.imsd.contel.com
UUCP: {hacgate,jplgodo,voder}!wlbr!pete
"... So I picked up my pride from beneath the pay phone, and combed his breath
right outta my hair. And sometimes, it's not so easy ..." J. Hendrix/My Friendignatz@wam.umd.edu (Mark J. Sienkiewicz) (06/21/91)
In article <YcLJfnq00WCpEQLFMd@andrew.cmu.edu> ww0n+@andrew.cmu.edu (Walter Lloyd Wimer III) writes: >Hmmmm. . . . Someone should write a real executable program named "J" >which sits in the execution directory and prints out an appropriate >error message when invoked. . . . ;-) Actually, this usually happens because the OS9 shell didn't want load the executable in the first place. (Usually, it is not executable or something like that.) You should have the "J\374" (the real name it was looking for) figure out what file it was invoked from and EXECUTE the file as an object module. I figure this is possible, but I don't have time to work on it. Anyone care to try this? Mark.