jeff@contex.contex.com (Jeff Carey) (05/23/91)
(Please let me know if you have seen this already, we are having trouble with our news posting mechanisms.) I don't know if this is the correct newsgroup for this question, but anyhow... I have recently bought a A3000, and have acquired the PD source to CShell 5.10 (I think). Being a Unix programmer by profession, I thought this might be useful. Well, when I tried to compile said source I discovered that I also needed arp. So, I got the arp 1.3 distribution. Well, the CShell still doesn't compile. There are a series of structures that are defined in both arp's include files as well as in asl.h or dosasl.h. I am running Lattice/SAS C compiler 5.10a. This is during the compilation of "Shell.syms"!!! The CShell documentation claims that it will compile under (atleast) Lattice 5.00. What gives? So, what I am mostly interested in is: Is arp (1.3) supposed to be compatible with WB2.0? Is arp NEEDED with WB2.0? Is the CShell I am referring to supposed to be compatible with WB2.0? Is there any other csh-like shells out there that: 1. do NOT need arp? 2. are WB2.0 compatible? 3. I can get? I am mostly interested in a shell with Unix-like wildcards, command-line editing, and file name completion capabilities. I use a shell called 'tcsh' at work which has these. Please give me any thoughts that occur to you. Thanks... Oh, on another note. I use JOVE (Jonathon's Own Version of Emacs) at work, also. I don't imagine anyone has heard of such a beast that is ported to the Amiga, have you? If not, I'll continue with my currently time-consuming port. If anyone has any suggestions to this port's requirements, please let me know about that also...I currently need to work out the details of: 1. putting the controlling terminal in raw mode 2. working in a public-domain release of termcap that I found 3. implementing the equivalent of such functions as sleep(), execl(), execv(), fork(), pipe(), etc., etc. 4. etc., etc. Thanks again, jeff ------ Jeff Carey jeff@contex.com
kudla@jec313.its.rpi.edu (Robert J. Kudla) (05/24/91)
jeff@contex.contex.com (Jeff Carey) writes: >Oh, on another note. I use JOVE (Jonathon's Own Version of Emacs) at work, >also. I don't imagine anyone has heard of such a beast that is ported to >the Amiga, have you? There's MicroGnuEmacs on the Extras: disk, but that kind of sucks.... I highly recommend "mg" (not sure what version; last year a friend was betatesting v3a, while I have 2b installed in my system) which is free software and much less finicky and more Emacs-like than Jove. -- Robert Jude Kudla <kudla@rpi.edu> You cannot go against nature, because when you do Going 'gainst nature is part of nature too....
mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) (05/24/91)
In article <+4fh=ab@rpi.edu> kudla@jec313.its.rpi.edu (Robert J. Kudla) writes: jeff@contex.contex.com (Jeff Carey) writes: >Oh, on another note. I use JOVE (Jonathon's Own Version of Emacs) at work, >also. I don't imagine anyone has heard of such a beast that is ported to >the Amiga, have you? There's MicroGnuEmacs on the Extras: disk, but that kind of sucks.... Um, the thing on the Extra's disk is "memacs"; it's unrelated to MicroGNUEmacs, except for a probable common ancestor. I highly recommend "mg" (not sure what version; last year a friend was betatesting v3a, while I have 2b installed in my system) which is free software and much less finicky and more Emacs-like than Jove. MicroGNUEmacs was built to closely match GNU; it turned into mg after the FSF asked us to drop the GNU from the name. If you like Jove, you'll probably hate mg (and anything else that looks like GNU). However, there are _lots_ of micro-emacs for the Amiga; find a fish index and look for "emacs" in the descriptions. mg2b is the latest "release" version of mg. mg3a was released in Beta, to get the ARexx interface out. The editor seems stable (I don't get lots of reports of crashes or lost text), but the documentation hasn't been properly updated. <mike -- I know the world is flat. Mike Meyer Don't try tell me that it's round. mwm@pa.dec.com I know the world stands still. decwrl!mwm Don't try to make it turn around.
jap@convex.cl.msu.edu (Joe Porkka) (05/24/91)
jeff@contex.contex.com (Jeff Carey) writes: >(Please let me know if you have seen this already, we are having > trouble with our news posting mechanisms.) >I don't know if this is the correct newsgroup for this question, >but anyhow... >I have recently bought a A3000, and have acquired the PD source to >CShell 5.10 (I think). >Being a Unix programmer by profession, I thought this might be useful. >Well, when I tried to compile said source I discovered that I also >needed arp. >So, I got the arp 1.3 distribution. >Well, the CShell still doesn't compile. There are a series of structures >that are defined in both arp's include files as well as in asl.h or dosasl.h. >I am running Lattice/SAS C compiler 5.10a. Try installing the 1.3 includes. The 2.0 includes define a bunch of stuff which looks an awfull lot like the Arp includes. So instead of fighting with it the easiest thing to do is to use the 1.3 includes. The only problem then is that you lose out on access to the 2.0 features which require stuff from the 2.0 includes. Since your'e trying to get a pre2.0 program to compile this will not be a problem.
umueller@iiic.ethz.ch (Urban Dominik Mueller) (05/24/91)
Author of csh speaking... In article <1845@contex.contex.com> jeff@contex.contex.com (Jeff Carey) writes: >I have recently bought a A3000, and have acquired the PD source to >CShell 5.10 (I think). Binary is available, too. Man, AmigaDOS isn't UNIX! So if you only want to use it, get the binary at ab20. By the way, 5.10 is outdated. 5.14 is the most recent version (uploaded today). >Being a Unix programmer by profession, I thought this might be useful. Hope so :-) >Well, when I tried to compile said source I discovered that I also >needed arp. >So, I got the arp 1.3 distribution. The source for 5.14 has the right arp files included. Many people have reported problems finding them, and furthermore, there's a bug or two in the originals that are corrected in my version. >Well, the CShell still doesn't compile. There are a series of structures >that are defined in both arp's include files as well as in asl.h or dosasl.h. >I am running Lattice/SAS C compiler 5.10a. Try using kickstart 1.3 include files. I have imported all needed 2.0 structures into shell.h. >The CShell documentation claims that it will compile under (atleast) Lattice >5.00. What gives? Partially wrong. I've heard of people who successfully compiled it with Lattice 5.0x, but for correct operation, you need 5.10. >Is arp (1.3) supposed to be compatible with WB2.0? Yes. The library (or at least all functions I use) works fine under 2.0. Some of the CLI commands break, as I've heard. >Is arp NEEDED with WB2.0? No. In fact, WB2.0 replaces arp in many respects. The main reason why I still use arp is that I want to be kickstart 1.3 compatible. And because WB2.0 has given me no replacement for SyncRun() (I need a function that uses the current process). >Is the CShell I am referring to supposed to be compatible with WB2.0? Yes. WB2.0 is my personal environment. >Is there any other csh-like shells out there that: > 1. do NOT need arp? > 2. are WB2.0 compatible? > 3. I can get? >I am mostly interested in a shell with Unix-like wildcards, command-line >editing, and file name completion capabilities. There's only one additional UNIX-like shell: sksh. It's compatible to UNIX ksh. It also needs arp, the latest version should be WB2.0 compatible, and it's PD, too (no source). Both csh and sksh have the three features you mention plus many more. >I use a shell called 'tcsh' at work which has these. Somebody's working on a tcsh compatible editing keyboard for csh; you can also do it yourself. Will be part of csh 5.15. [burp] >know about that also...I currently need to work out the details of: > 1. putting the controlling terminal in raw mode CShell sources, module rawcon.c, function setrawcon(). Can't help much about the rest. But I'm confident somebody else can. >Jeff Carey >jeff@contex.com U. Dominik Mueller, umueller@iiic.ethz.ch
jesup@cbmvax.commodore.com (Randell Jesup) (05/25/91)
In article <28943@neptune.inf.ethz.ch> umueller@iiic.ethz.ch (Urban Dominik Mueller) writes: >>Is arp NEEDED with WB2.0? >No. In fact, WB2.0 replaces arp in many respects. The main reason why >I still use arp is that I want to be kickstart 1.3 compatible. And >because WB2.0 has given me no replacement for SyncRun() (I need a >function that uses the current process). RunCommand(seglist,stacksize,arguments,argument length). This is what is used by the system shell to run commands on your process. -- Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Disclaimer: Nothing I say is anything other than my personal opinion. "No matter where you go, there you are." - Buckaroo Banzai
umueller@iiic.ethz.ch (Urban Dominik Mueller) (05/26/91)
In article <21913@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: >In article <28943@neptune.inf.ethz.ch> umueller@iiic.ethz.ch (Urban Dominik Mueller) writes: >>because WB2.0 has given me no replacement for SyncRun() (I need a >>function that uses the current process). > > RunCommand(seglist,stacksize,arguments,argument length). This is what >is used by the system shell to run commands on your process. Admitted. There are two reasons for still using SyncRun(): It's much more convenient (no LoadSeg needed, no path search, no (arp) resident list search, no setting of cli_CommandName), and it works under 1.3 as well. And it does fine under 2.0, too. Probably I'll switch to RunCommand() in a 2.0 release of CShell. Just curious: Does RunCommand() have any problems with the same commands SyncRun() has, ie. c:Execute and c:Run? In any case it's a vast improvement over Execute() (or CreateProc()). >Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering. -U. Dominik Mueller umueller@iiic.ethz.ch .sig light!
jesup@cbmvax.commodore.com (Randell Jesup) (05/26/91)
In article <28961@neptune.inf.ethz.ch> umueller@iiic.ethz.ch (Urban Dominik Mueller) writes: >Admitted. There are two reasons for still using SyncRun(): It's much more >convenient (no LoadSeg needed, no path search, no (arp) resident list search, >no setting of cli_CommandName), and it works under 1.3 as well. The "more convenient" part are all normally shell functions. It's fairly easy to write a wrapper that does those if you wish. Supposedly Charlie was going to do a very small arp for 2.0 (many things become direct or close to calls to Dos), but he and it seems to have fallen by the wayside recently. >Does RunCommand() have any problems with the same >commands SyncRun() has, ie. c:Execute and c:Run? It should work fine with them. -- Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Disclaimer: Nothing I say is anything other than my personal opinion. "No matter where you go, there you are." - Buckaroo Banzai
koren@hpfcdc.HP.COM (Steve Koren) (05/28/91)
> RunCommand(seglist,stacksize,arguments,argument length). This is what >is used by the system shell to run commands on your process. Well, I admit I don't have the docs for RunCommand, but from the arguments to it listed above, it appears there is no way to redirect input and output to the command. If true, that would make it unusable for a shell. - steve
dillon@overload.Berkeley.CA.US (Matthew Dillon) (05/30/91)
In article <37100008@hpfcdc.HP.COM> koren@hpfcdc.HP.COM (Steve Koren) writes: > >> RunCommand(seglist,stacksize,arguments,argument length). This is what >>is used by the system shell to run commands on your process. > >Well, I admit I don't have the docs for RunCommand, but from the arguments >to it listed above, it appears there is no way to redirect input and >output to the command. If true, that would make it unusable for a shell. > > - steve There are THREE main 2.0 calls associated with running programs: (1) RunCommand() RunCommand() runs a seglist under THE CALLERS CONTEXT, using the caller's task. THIS IS THE COMMAND A SHELL WRITER WOULD USE TO RUN COMMANDS. The caller must LoadSeg() or FindResident() (and bump the resident tag count as appropriate) to get a segment which may be used in a call to RunCommand(). The argument line must be terminated with \n\0 instead of just \0 to be compatible with resident C: commands. All other setup is up to the calling program (in terms of setting up input, output, etc...) Since no new process is created and the seglist may be pre-cached or found in a resident list, this call can be made to run VERY quickly. (2) System() System() will start up a shell, executable your command (like Execute()), then return the exit code. It has options similar to CreateNewProc() below in terms of directing input and output and choosing between the system shell or a custom shell. Commands run under System() run in a separate shell context, meaning that ^C-^F will not be propogated. However, full shell command lines are allowed, including redirection on the command line, and use of internal shell commands. Running a command via System() is slower than RunCommand() since a separate process will be created, a shell/cli run, and the command then interpreted by the shell/cli. (3) CreateNewProc() Create a new process specifying either an entry point or seglist, with options to set input, output, current dir, stack, name, priority, console task, windowptr, CLI, etc etc etc.... This call is faster than System() but slower than RunCommand(). However, it is an excellent method to start up asynchronous processes or tasks (such as servers, handlers, co-processes...) -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
andy@cbmvax.commodore.com (Andy Finkel) (05/30/91)
In article <37100008@hpfcdc.HP.COM> koren@hpfcdc.HP.COM (Steve Koren) writes: > >> RunCommand(seglist,stacksize,arguments,argument length). This is what >>is used by the system shell to run commands on your process. > >Well, I admit I don't have the docs for RunCommand, but from the arguments >to it listed above, it appears there is no way to redirect input and >output to the command. If true, that would make it unusable for a shell. > > - steve Nonsense. It's perfect for a shell. In fact, its what our shell uses. :-) I parse the redirection arguments from the command line first, set the process inputs and outputs from the redirection, then call RunCommand with the reduced command line. When you call something like System("dir >ram:qwe") a shell process is fired up, the parsing takes place, and RunCommand eventually gets called. There's nothing wrong this that approach; but having direct access to RunCommand makes it possible for user shells to have the same abilities as the built in shell. andy -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "The best way to do video effects on a Mac is to use an Amiga." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
koren@hpfcdc.HP.COM (Steve Koren) (05/30/91)
> > RunCommand(seglist,stacksize,arguments,argument length). This is what > to it listed above, it appears there is no way to redirect input and > output I've been informed that you can change the stdio streams of your current process manually (by changing pr_CIS and pr_COS or whatever they're called). This will then affect the next thing you run with RunCommand(). - steve
andy@cbmvax.commodore.com (Andy Finkel) (05/31/91)
In article <dillon.8133@overload.Berkeley.CA.US> dillon@overload.Berkeley.CA.US (Matthew Dillon) writes: > the resident tag count as appropriate) to get a segment which may > be used in a call to RunCommand(). The argument line must be > terminated with \n\0 instead of just \0 to be compatible with > resident C: commands. Actually, Matt, the reason for the \n is to make any programs that call ReadArgs happy. ReadArgs uses the command line provided by the Shell via CurrentInput, and it requires that the line be terminated by a \n. andy -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "The best way to do video effects on a Mac is to use an Amiga." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
jdickson@jato.jpl.nasa.gov (Jeff Dickson) (06/01/91)
How could you prevent a C compiler from including a heap for memory allocation purposes? Specifically, I have the Manx Aztec C compiler V3.6. Also, I'm not to crazy about dumping my compiler, because it's library knows nothing of the new V2.0 functions. Do I have a recourse ? Could I write my own stubs in assembler? thanks, jeff
dillon@overload.Berkeley.CA.US (Matthew Dillon) (06/02/91)
In article <22070@cbmvax.commodore.com> andy@cbmvax.commodore.com (Andy Finkel) writes: >In article <dillon.8133@overload.Berkeley.CA.US> dillon@overload.Berkeley.CA.US (Matthew Dillon) writes: >> the resident tag count as appropriate) to get a segment which may >> be used in a call to RunCommand(). The argument line must be >> terminated with \n\0 instead of just \0 to be compatible with >> resident C: commands. > > >Actually, Matt, the reason for the \n is to make any programs that >call ReadArgs happy. ReadArgs uses the command line provided by >the Shell via CurrentInput, and it requires that the line be >terminated by a \n. > > andy Exactly. It's braindamaged. You shouldn't have to terminate your argument line with a \n. :-) >-- >andy finkel {uunet|rutgers|amiga}!cbmvax!andy >Commodore-Amiga, Inc. > > "The best way to do video effects on a Mac is to use an Amiga." > >Any expressed opinions are mine; but feel free to share. >I disclaim all responsibilities, all shapes, all sizes, all colors. -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
andy@cbmvax.commodore.com (Andy Finkel) (06/03/91)
In article <dillon.8279@overload.Berkeley.CA.US> dillon@overload.Berkeley.CA.US (Matthew Dillon) writes: >In article <22070@cbmvax.commodore.com> andy@cbmvax.commodore.com (Andy Finkel) writes: >>In article <dillon.8133@overload.Berkeley.CA.US> dillon@overload.Berkeley.CA.US (Matthew Dillon) writes: >>Actually, Matt, the reason for the \n is to make any programs that >>call ReadArgs happy. ReadArgs uses the command line provided by >>the Shell via CurrentInput, and it requires that the line be >>terminated by a \n. >> >> andy > > Exactly. It's braindamaged. You shouldn't have to terminate your > argument line with a \n. :-) I agree. The reason is important, though, as most people won't run into it except when writing a shell, when they have to remember to set up the command line 'properly' before calling runcommand. They should know why and what will be affected. andy -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "If all you have is a hammer, everything looks like a popsicle." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.