john13@garfield.MUN.EDU (John Russell) (11/29/88)
Just as an addendum to my earlier posting re: the speak device losing the last character in most write requests, there's also strangeness involving punctuation; I haven't been able to make speak: recognize punctuation marks for inflection unless the mark is immediately followed by a "pronounceable" character, ie. not another punctuation mark or whitespace. This seems to be related, as if the very last character of each sentence is being dis- regarded. I am still very interested in seeing what sort of devices could be constructed and integrated into the general environment. 14 (the number assign shows as being mounted now) is only a start :-). One which comes immediately to mind is a spooling daemon, spool:. Although I know of a number of spooling programs and facilities, the ones I've seen all require you to either know the filenames in advance, or go through extensive physical interaction to print new files. A spool device would allow this process to be automated, and remove the need to wait for DPaint to finish printing before sending that Pagesetter document. The device would simply need to stash the data in memory, wait for the printer to become free, then take control and send the next available job. Another which appeals to me is a Tek emulation device, which might be opened with a filename that specified the size, colours, scaling etc. for the drawing screen. This would allow any terminal program to become a Tektronix emulator, as long as it had the ability to do an ASCII capture. This sort of device would lend itself to more built-in intelligence, perhaps featuring the ability to pan, zoom, and dump data to disk based on requests passed to it. John -- "Media is Ignorent, Researchers Say" -- either this is an incredibly sarcastic headline-writer, or...
dat01@teorix.liu.se (Dat) (12/01/88)
In article <5015@garfield.MUN.EDU> john13@garfield.MUN.EDU (John Russell) writes: >I am still very interested in seeing what sort of devices could be >constructed and integrated into the general environment. 14 (the number >assign shows as being mounted now) is only a start :-). > >One which comes immediately to mind is a spooling daemon, spool:. ... [ stuff deleted ] >John >-- What I would like to do is use the devices as some kind of pipes. For example: saveas CRYPT:ZOO:MSDOS:file This should encrypt the file, send it along to ZOO for packing and then save it on an MSDOS disk. Another examples: copy from ARC:MSDOS:file.arc to ZOO:DH0:file.zoo read a file from an MSDOS disk, un-arc it, pack it with ZOO and save it on my hard disk. _____________ /// WWWWW Mikael Karlsson, Lovsattersvagen 10, S-585 98 LINKOPING, SWEDEN /// {@v@} "I may be artificial, but I'm not stupid." \\\/// \w/ "Give me a fixed address, and I will move the World" \XX/
peter@sugar.uu.net (Peter da Silva) (12/04/88)
In article <1086@teorix.liu.se>, dat01@teorix.liu.se (Dat) writes: > What I would like to do is use the devices as some kind of pipes. Better would be some real pipes and better tools. Some things make sense as devices, and some things make more sense as tools. Relatively large programs like arc and zoo fit into the latter category. I want a good korn shell for the Amiga. csh is a crummy programming language. > saveas CRYPT:ZOO:MSDOS:file crypt file | zoo create MSDOS:file.zoo input "file" Or if you can't fix zoo: crypt file >PIPE:file & zoo -add MSDOS:file.zoo PIPE:file > copy from ARC:MSDOS:file.arc to ZOO:DH0:file.zoo for i in `arc t MSDOS:file.arc` do arc p MSDOS:file.arc $i >PIPE:file & zoo -add DH0:file.zoo PIPE:file done I routinely do stuff like this in UNIX. It's a pity the Amiga pipe devices don't work quite right for this application. -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today? Disclaimer: My typos are my own damn busines#!rne
thad@cup.portal.com (Thad P Floryan) (12/05/88)
Re: Peter da Silva's comments about piping and the Amiga and UNIX ... I agree. Consider how easy and simple it is to unpack the GNU EMACS: cat emacs-18.52.?? | zcat | tar xvf - The EMACS compressed "tar" distribution is 4.5Megabytes; the uncompressed file is 11.4 Megabytes; the number of source files is approx. 784. The above operation took about 2 minutes (wall clock time) on my 3B1 and I didn't have enough disk space to hold the separate stages; pipes and piping *ARE* extremely important! One general question, though: is the Amiga UNIX "stuck" with the brain-damaged SysV 14-character filename size limit? If so, FIX IT BEFORE RELEASE. 14-character filenames sucks dead bunnies through a straw. (NO smiley face) Thad Floryan [thad@cup.portal.com (OR) ...!sun!portal!cup.portal.com!thad]
gay%elde.epfl.ch@cunyvm.cuny.edu (David Gay) (12/06/88)
In article <3046@sugar.uu.net>, peter@sugar.uu.net (Peter da Silva) writes: >In article <1086@teorix.liu.se>, dat01@teorix.liu.se (Dat) writes: >> What I would like to do is use the devices as some kind of pipes. > >Better would be some real pipes and better tools. Some things make sense >as devices, and some things make more sense as tools. Relatively large >programs like arc and zoo fit into the latter category. > >I want a good korn shell for the Amiga. csh is a crummy programming language. > >> saveas CRYPT:ZOO:MSDOS:file > >crypt file | zoo create MSDOS:file.zoo input "file" Yes, but you can't do this from your favourite editor(or whatever) ... I routinely use the capture mode of VT100 to download text files from which I must remove some nuls added along the way. It's very convenient to be able to: In VT100 : Capture -> pipe:file In the CLI : run nonul <pipe:file >df1:save Thus avoiding the use of a temporary file. >for i in `arc t MSDOS:file.arc` >do > arc p MSDOS:file.arc $i >PIPE:file & > zoo -add DH0:file.zoo PIPE:file >done > >I routinely do stuff like this in UNIX. It's a pity the Amiga pipe >devices don't work quite right for this application. You can always use WShell (for the pipes). I haven't actually tried this yet because my Amiga isn't working :-( (I recently got WShell & AREXX). >-- > Peter da Silva `-_-' peter@sugar.uu.net > Have you hugged U your wolf today? > > Disclaimer: My typos are my own damn busines#!rne David Gay GAY@ELDE.EPFL.CH, or GAY%ELDE.EPFL.CH@CLSEPF51.bitnet
ranjit@eniac.seas.upenn.edu (Ranjit Bhatnagar) (12/06/88)
A suggested device that would make certain things very convenient:
SHELL:<string> invokes your favorite shell (named in an
environment variable?), attaches its input and output, and gives
it the <string> as the command line. Actually, rather than an
arbitrary shell, it should probably just do a CLI, to conserve
memory and give a predictable environment.
kermit download to "shell:uncompress >ram:foo"
save file as "shell:csh -c 'detab|indent|format>ram:foo'"
Nothing that couldn't be done with pipes, but you wouldn't have
to flip back and forth between the application and the shell to
get the thing done.
- Ranjit
"Trespassers w" ranjit@eniac.seas.upenn.edu mailrus!eecae!netnews!eniac!...
-- I'm not a drug enforcement agent, but I play one for TV --
Giant SDI lasers burn 1,000 points of light in Willie Horton - Dave Barrypeter@sugar.uu.net (Peter da Silva) (12/06/88)
In article <5816@louie.udel.EDU>, gay%elde.epfl.ch@cunyvm.cuny.edu (David Gay) writes: > In article <3046@sugar.uu.net>, peter@sugar.uu.net (Peter da Silva) writes: > >In article <1086@teorix.liu.se>, dat01@teorix.liu.se (Dat) writes: > >> What I would like to do is use the devices as some kind of pipes. > >Better would be some real pipes and better tools... > >I want a good korn shell for the Amiga. csh is a crummy programming language. > >> saveas CRYPT:ZOO:MSDOS:file > >crypt file | zoo create MSDOS:file.zoo input "file" > Yes, but you can't do this from your favourite editor(or whatever) ... Then what you want is another device I dreamed up, "CLI:". The theory here would be "CLI:command" would open a pipe to command and pass back the file handle... sort of the equivalent of the UNIX 'popen'. [ I lamented the unfortunate state of the AmigaDOS PIPE: devices ] > You can always use WShell (for the pipes). Unfortunately too many commands (zoo, for example) are written by pc-brain bozos who don't understand the concept of a 'filter'. The WShell pipe device won't help with Zoo because it's got no name. -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today? Disclaimer: My typos are my own damn busines#!rne
dhesi@bsu-cs.UUCP (Rahul Dhesi) (12/07/88)
In article <3061@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes:
[some name-calling because zoo won't write its archives to standard output]
The reason zoo archives aren't written to standard output is because
doing so requires sequential writes. If they were, updating an
archive would require copying the entire archives. This would mean
that you could not manipulate large archives in limited disk space.
Database handling programs in general don't write purely sequentially.
--
Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesidillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (12/07/88)
:In article <3046@sugar.uu.net>, peter@sugar.uu.net (Peter da Silva) writes: :>In article <1086@teorix.liu.se>, dat01@teorix.liu.se (Dat) writes: :>> What I would like to do is use the devices as some kind of pipes. :> :>Better would be some real pipes and better tools. Some things make sense :>as devices, and some things make more sense as tools. Relatively large :>programs like arc and zoo fit into the latter category. :> :>I want a good korn shell for the Amiga. csh is a crummy programming language. :> :>> saveas CRYPT:ZOO:MSDOS:file :> :>crypt file | zoo create MSDOS:file.zoo input "file" : :Yes, but you can't do this from your favourite editor(or whatever) ... I It is possible to do this, but you would need to write a core device that would figure out the path and setup multiple pipes to handle it, like this: saveas CORE:CRYPT/key=charlie/ZOO:MSDOS:file Where CORE: would parse the rest of the path, set up a pipe to CRYPT/key=charlie, from there to ZOO:, from there to MSDOS:file . -Matt
peter@sugar.uu.net (Peter da Silva) (12/07/88)
In article <4972@bsu-cs.UUCP>, dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: > In article <3061@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: > [some name-calling because zoo won't write its archives to standard output] ...and won't read files or archives from standard input, etc... > The reason zoo archives aren't written to standard output is because > doing so requires sequential writes. If they were, updating an archive > would require copying the entire archives. This would mean that you > could not manipulate large archives in limited disk space. > Database handling programs in general don't write purely sequentially. This is a bit of a straw man. Consider... You can maintain the archive any way you like it, but having an option to write it out as a stream may well save on disk space. Just ask anyone who's used cpio. How about: 1> run zoo -stream files >PIPE:x [switch windows] Kermit> send pipe:x Yes, when you just want to add a file to an archive, it's more efficient to do it in place. On the other hand, the most common mode of using zoo is all-or-nothing. It's more often used as an archiver than a database. Finally, since zoo is mainly a PC product... calling it pc-ware is accurate. I apologise for the word "bozo", though. It was uncalled-for. PS: is there a program that'll generate a list of filenames suitable for input to 'zoo I'? This is a very cpio-ish option, you know. -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today? Disclaimer: My typos are my own damn busines#!rne
blgardne@esunix.UUCP (Blaine Gardner) (12/09/88)
From article <3066@sugar.uu.net>, by peter@sugar.uu.net (Peter da Silva): > PS: is there a program that'll generate a list of filenames suitable for > input to 'zoo I'? This is a very cpio-ish option, you know. There's a program called FNAMS (that's not a typo) that will read a directory structure to stdout. This makes Zooing an entire disk as easy as : Fnams >NeatDisk df0: Zoo <NeatDisk aI ND.zoo Though it would be nicer if Zoo could handle the directory structure itself, rather than requiring an external program. The Zoo x// option is one I've come to love, but I would like to see it handle the volume name too. That would make shipping around software that relies on the volume name to run (for example, the Walker demo) eaiser. The way it works now, I have to include a readme file telling the receiver that he has to rename the floppy. I believe that Fnams is on (all together on the chorus!) a recent Fish Disk. If not, I can e-mail it to you, or send it to Bob Page. -- Blaine Gardner @ Evans & Sutherland 580 Arapeen Drive, SLC, Utah 84108 Here: utah-cs!esunix!blgardne {ucbvax,allegra,decvax}!decwrl!esunix!blgardne There: uunet!iconsys!caeco!pedro!worsel!blaine "Nobody will ever need more than 64K." "Nobody needs multitasking on a PC."
mavanamm@pttesac.UUCP (Marnix van Ammers) (12/12/88)
In article <1150@esunix.UUCP> blgardne@esunix.UUCP (Blaine Gardner) writes: >From article <3066@sugar.uu.net>, by peter@sugar.uu.net (Peter da Silva): >> PS: is there a program that'll generate a list of filenames suitable for >There's a program called FNAMS (that's not a typo) that will read a >directory structure to stdout. This makes Zooing an entire disk as >easy as : > >Fnams >NeatDisk df0: There's also a program called FIND (by Rodney Lewis) which is a clone of the UNIX find command. Much handier in case you only want files of a specific type or with specific attributes. I got the sources off the net so don't know which fish disk it's on (if it's on one). Marnix
jbh@mibte.UUCP (James Harvey) (12/19/88)
In article <958@pttesac.UUCP>, mavanamm@pttesac.UUCP (Marnix van Ammers) writes: > In article <1150@esunix.UUCP> blgardne@esunix.UUCP (Blaine Gardner) writes: > >From article <3066@sugar.uu.net>, by peter@sugar.uu.net (Peter da Silva): > >> PS: is there a program that'll generate a list of filenames suitable for > > >There's a program called FNAMS (that's not a typo) that will read a > >directory structure to stdout. This makes Zooing an entire disk as > >easy as : > > > >Fnams >NeatDisk df0: > > There's also a program called FIND (by Rodney Lewis) which is a clone > of the UNIX find command. Much handier in case you only want files > of a specific type or with specific attributes. > > I got the sources off the net so don't know which fish disk it's on > (if it's on one). > > Marnix Perhaps the new LFORMAT option in the 1.3 LIST command would do what you need. I've used it several times to manipulate directorys into command files. -- Jim Harvey | "Ask not for whom the bell Michigan Bell Telephone | tolls and you will only pay 29777 Telegraph | Station-to-Station rates." Southfield, Mich. 48034 | ulysses!gamma!mibte!jbh