jlc@whuxl.UUCP (CODONA) (09/25/86)
This is my first posting to the net so ... Can anyone tell me how to attach a cli to ser: such that it will actually be usable from a terminal? I know that run newcli ser: almost works, but it requires a line padded out with blanks or something to some ridiculous length before it gives a response and then it doesn't seem to understand. Also, how about such simple things as echoing characters back to the terminal? I know I can write a C program that acts as a go-between for the terminal and a cli via Execute(), but I am hoping for a trivial, "instant solution" of the type I have learned here on the net many times already. Thanks in advance, Johanan L. Codona (...!ihnp4!whuxl!jlc) P.S. My employers know nothing of this, so don't blame them, blame me. Why not, they do! B^)
dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/26/86)
On this, does anyone know the criteria for NEWCLI accepting non-windows for it's window argument? On the ser: device... your outa' luck. The input buffering is a 'feature' of ser:... however, if NEWCLI accepts ser: as an argument, I see no reason for it to screw up the input processing once it *does* get a buffer full... try using LineFeeds (^j) instead of Returns (^m). This is why you usually attach a newcli to a CON: device and not a RAW: device. Also, the CON: device does input buffering and echo. The only solution I see to offering a CLI process on the serial port or on a separate screen is for some brave soul to write a DOS device driver for it. ----- Question: Where does OpenWorkbench() go to get it's Screen parameters? Specifically, the width and height (or am I wishing?)? -Matt Q: What do you get when you hand OpenScreen() a width of 50? A: FireWorks
carolyn@cbmvax.cbm.UUCP (Carolyn Scheppner) (09/27/86)
In article <1262@whuxl.UUCP> jlc@whuxl.UUCP (CODONA) writes: > > Can anyone tell me how to attach a cli to ser: such that it >will actually be usable from a terminal? > I think the Metacomco Toolkit includes an AUX: device which will do what you want. I don't know if the Toolkit is commercially available yet. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Carolyn Scheppner -- CBM >>Amiga Technical Support<< UUCP ...{allegra,caip,ihnp4,seismo}!cbmvax!carolyn PHONE 215-431-9180 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
hamilton@uiucuxc.CSO.UIUC.EDU (09/27/86)
> Can anyone tell me how to attach a cli to ser: such that it >will actually be usable from a terminal? if you don't mind spending $50, metacomco will sell you an AUX: handler that will (supposedly) accomplish what you want. (you also get a bunch of other things, including a pipe handler, a semi-intelligent disassembler, a clone of "more", a librarian...). ask for the "toolbox". otherwise, you can find a copy of the disassembly of port-handler that john toebes did long ago and hack it up so that it does character-at-a-time or possibly line-buffered i/o. wayne hamilton U of Il and US Army Corps of Engineers CERL UUCP: {ihnp4,pur-ee,convex}!uiucdcs!uiucuxc!hamilton ARPA: hamilton%uiucuxc@a.cs.uiuc.edu USMail: Box 476, Urbana, IL 61801 CSNET: hamilton%uiucuxc@uiuc.csnet Phone: (217)333-8703 CIS: [73047,544] PLink: w hamilton
rmariani@watmum.UUCP (Rico Mariani) (09/29/86)
MetaCompco has released an AmigaDOS toolkit disks which among other things includes a device driver called aux: whose misson in life is to allow you to have a CLI out on the serial port. It basically provides "cooked" input w/o buffering. It's real handy, I've already had a friend "log in" to my Amiga over a modem and do stuff. The biggest problem (feature?) is that when the guy on the serial port asks for a volume that isn't mounted, the requestor pops up on the "console", it's distracting to say the least. Also on this disk is the infamous pipe: driver as advertised on Beta 4 (?) of kickstart. That's real handy too. The only other really useful thing on the disk is an object disassembler which works on executables rather than on .o files like "omd". -Rico DISCLAIMER: Nobody at UW has any idea that I'm saying this so leave them alone
cmcmanis@sun.uucp (Chuck McManis) (09/29/86)
Actually, on the Metocomo toolkit disk, there is a device called AUX:
which handles remoter CLI's as you would expect. NewCLI > AUX: does
what you want. (They also have a PIPE: device) It would seem that
it should also be possible to modify one of the shells around here
to open the SER: device and use it for I/O. Maybe it needs a command
line switch rather than the redirection.
--
--Chuck McManis
uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/30/86)
>what you want. (They also have a PIPE: device) It would seem that >it should also be possible to modify one of the shells around here >to open the SER: device and use it for I/O. Maybe it needs a command >line switch rather than the redirection. Can't. SER: buffers its input and is completely useless in that respect. -Matt
toebes@sas.UUCP (John Toebes) (10/01/86)
In article <8609260632.AA26339@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > > On this, does anyone know the criteria for NEWCLI accepting non-windows > for it's window argument? > > On the ser: device... your outa' luck. The input buffering is a > 'feature' of ser:... however, if NEWCLI accepts ser: as an argument, I see > no reason for it to screw up the input processing once it *does* get a > buffer full... try using LineFeeds (^j) instead of Returns (^m). This is > why you usually attach a newcli to a CON: device and not a RAW: device. It is possible to modify the port-handler - unsupported of course - to run a newcli over the ser: device. I have done it several times and have done some work to allow one to say newcli ser:9600,8,n,1,I But at the current point in time I have only got a copy of a version that does not compile. I have not posted this because I have a request in to CBM (now quite an old request) for a definition of what form of AMIGADOS device handlers will be supported. As the frustration factor is getting high on getting this resolved, I am tempted to break the cobwebs off the code and post it. > > Also, the CON: device does input buffering and echo. > > The only solution I see to offering a CLI process on the serial > port or on a separate screen is for some brave soul to write a DOS device > driver for it. The problem we have here is twofold: There is no supported way to write a device driver that will work with 1.1. Second, the documented way of making a driver work under 1.2 has not worked for me yet. Doing the CLI on a separate screen is quite simple. Jack Rouse has already done the major part of the work for it in MAKE. It handles all the I/O to a device other than a CON: window under program control. It needs some polish but could be readily adapted to a number of different attacks on the subject, including adding command line recall to a window. But where's the time for us to do all this work.... > > Q: What do you get when you hand OpenScreen() a width of 50? > A: FireWorks Try a height of 1 and a width of 1. It is also just as unpleasant. I wanted POPCLI to use that size to reduce the amount of memory. I finally went with a nice save number like 120 by 12. John Toebes -- John A. Toebes, VIII usenet:..mcnc!rti-sel!sas!toebes USnail: 235 Trillingham Ln, Cary NC 27511 BBS:(919)471-6436