terry@thekeep.UUCP (Terry D. West) (02/08/90)
I figured it was about time to upgrade from Matt's Csh 3.02 to Steve's SKsh 1.2 --- and a look at the manual to SKsh 1.2 (all bizzillion of them) convinced me right away... BUT. Two strange problems. I installed it and tried to run some of my favorite software, dmail and matt's UUCP stuff to be exact. Guru'd the machine right away. Postnews worked, but most other UUCP utils blew the machine away. The utils that DID work, didn't seem to inherit the command path of the shell. Even stranger, if I ran Matt's shell under steve's, then ran dmail et. al. - no guru. Everything went fine. Second problem: some software, like setenv, required an EXTRA <return> to make the command complete, and they rarely thought they had the right number of args. What gives? Terry. ------------------------------------------------------------------------- Terry West ...watmath!mks!thekeep!terry 309-400 Parkside Dr. Waterloo, ON, Canada. N2L 6E5 "thekeep" is an Amiga! -------------------------------------------------------------------------
ahh@glyph.UUCP (Andy Heffernan) (02/12/90)
In article <02152.AA02152@thekeep.UUCP> terry@thekeep.UUCP (Terry D. West) writes: >Two strange problems. I've had both. They look like startup problems. o I get Guru #3's when I start up certain C programs without any arguments (Lattice Make Utility, for example). o I get the double-return, no args problem with certain (all?) BCPL programs. I suppose when I get finished setting it up I should report these to Steve. -- ------------------------------------------------------------------------- Andy Heffernan uunet!glyph!ahh "'Iodine!' shrieked Clavius the Mage. 'I must have iodine!'"
koren@hpfelg.HP.COM (Steve Koren) (02/13/90)
> >I figured it was about time to upgrade from Matt's Csh 3.02 > >to Steve's SKsh 1.2 --- and a look at the manual to SKsh 1.2 ~~~ First off, try 1.3 (which is the newest, and will continue to be for another month or two yet). > >dmail and matt's UUCP stuff to be exact. Guru'd the machine > >right away. Postnews worked, but most other UUCP utils blew > >the machine away. The utils that DID work, didn't seem to inherit Make sure you have the latest arp.library (mine is 17100 bytes). If you have an old arp, there are several known problems with command invocation. Also, try giving it boatloads of stack. > >the command path of the shell. Use c:path to set whatever path you want external binaries to see. > >Second problem: some software, like setenv, required an EXTRA <return> > >to make the command complete, and they rarely thought they had the > o I get Guru #3's when I start up certain C programs without any > arguments (Lattice Make Utility, for example). Hmmm. Lets see if I can manage to explain this in a way that makes sense. Way back in the early days of SKsh (which used to be called Ash), I had planned to use the "normal" AmigaDos method of executing applications. Well, it turned out that there *is* no normal method. The supplied Execute() function has many problems the prevented me from using it *at all*. One day I stumbled across Arp, and Arp provided a clean interface to command invocation (you pass it a string to execute and some input and output handles). Since that was the only procedural interface available, it is what I used - SKsh builds the string to execute, and simply gives the string to Arp. The problems you report are all caused by the arp SyncRun function, since SKsh doesn't deal with command invocation itself. Of course, they are not Arp's fault, really - one has to go through incredible gymnastics to execute a program on the Amiga, and there are many special cases to consider (BCPL vs Lattice vs Manx vs programs compiled on Tuesdays after 3pm, etc). Arp did a great job (considering what they had to work with), but there are a few cases that it doesn't handle. If and when Commodore supplies a clean *procedural interface* to a command execution function, I will glady remove the arp mechanism from SKsh and use the supported Commodore solution. In the meantime, there is unfortunately not much I can do, since the problems lie outside of SKsh's little world. In other words, its not my fault! really! :-) > I suppose when I get finished setting it up I should report these to Steve. He knows :-) (but feel free to report them anyhow; I keep counts of which problems are reported (directly to me) how often, and assign priorities accordingly). Brief note to Commodore, if they're listening: I think that we need something like this: result_code = ExecProgram( char *command_line, struct FileHandle *input_fh, struct FileHandle *output_fh, int stack, int priority, int background_flag, whatever_else_is_needed ); It should work with *all* programs, and not require the programmer to mess around loading stuff into registers and dealing with segment lists and different program types. Pleeeeese??? And while we're discussing wish lists, can I have a fork() command (the real thing, not the Lattice forkv() stuff) so I can say: if (fork() == 0) { /* here's the child process */ } else { /* here's the parent process */ } Those two things would keep me happy for a long time :-) - steve
peter@sugar.hackercorp.com (Peter da Silva) (02/14/90)
In article <13920046@hpfelg.HP.COM> koren@hpfelg.HP.COM (Steve Koren) writes: > Brief note to Commodore, if they're listening: > I think that we need something like this: > result_code = ExecProgram( char *command_line, > struct FileHandle *input_fh, > struct FileHandle *output_fh, > int stack, > int priority, > int background_flag, > whatever_else_is_needed > ); [yes, I know "give" isn't the operative word... but while inventing stuff that's not going to happen why not do it right?] No, don't give them a background flag. that will give them an excuse to keep the kludge of running the program in the current process. Make it: token = Spawn( int sigbit, char *program, char *cmdline, BPTR infh, BPTR outfh, BPTR currentdir, ULONG stack, int prio); Wait(1<<sigbit); result = Status(token); If sigbit is -1, then I'm not going to wait on the program. > while we're discussing wish lists, can I have a fork() command (the > real thing, not the Lattice forkv() stuff) Not under AmigaOS you can't. -- _--_|\ Peter da Silva <peter@sugar.hackercorp.com>. / \ \_.--._/ I haven't lost my mind, it's backed up on tape somewhere! v "Have you hugged your wolf today?" `-_-'
koren@hpfelg.HP.COM (Steve Koren) (02/14/90)
Yesterday, I wrote this: > Brief note to Commodore, if they're listening: > I think that we need something like this: > result_code = ExecProgram( char *command_line, (etc) > It should work with *all* programs, and not require the programmer Also, it would be nice if it transparently dealt with resident programs. That is, if one executes copy, and copy is resident, the ExecProgram call should use the resident one. - steve
deven@rpi.edu (Deven T. Corzine) (02/23/90)
On 14 Feb 90 14:30:08 GMT, peter@sugar.hackercorp.com (Peter da Silva) said: Steve> while we're discussing wish lists, can I have a fork() command Steve> (the real thing, not the Lattice forkv() stuff) Peter> Not under AmigaOS you can't. Don't count on that, Peter, m'boy... Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2151 12th St. Apt. 4, Troy, NY 12180 Phone: (518) 274-0327 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.
peter@sugar.hackercorp.com (Peter da Silva) (02/24/90)
(I said, re: fork()): Not under AmigaOS you can't. In article <DEVEN.90Feb22134329@netserv2.rpi.edu> deven@rpi.edu (Deven T. Corzine) writes: > Don't count on that, Peter, m'boy... > Deven That's the best news I've heard in a long time! Where have you been? -- _--_|\ Peter da Silva <peter@sugar.hackercorp.com>. / \ \_.--._/ I haven't lost my mind, it's backed up on tape somewhere! v "Have you hugged your wolf today?" `-_-'