portuesi@tweezers.esd.sgi.com (Michael Portuesi) (08/02/89)
In article <1331@osupyr.mps.ohio-state.edu> vkr@osupyr.mps.ohio-state.edu (Vidhyanath K. Rao) writes: In article <26872@agate.BERKELEY.EDU> mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) writes: >I've heard rumors that something similar to ARP, only better designed >(not cramming everything into one library) is on 1.4. I am not sure that not cramming everything in one library will save space: [speculations on storage costs of 1.4 libraries deleted] I think that when Mike said "better designed", he was referring to design philosophy rather than storage requirements. I.E. by putting only related functionality into each library, you get more efficient library usage -- you're not loading a bunch of excess baggage when you open a library to do something, but loading a bunch of related functions you probably needed to use anyway. Currently, the ARP library is sort of a hodge-podge of unrelated functions. It gets away with it because it's not very large, but it is not good from the standpoint of future expansion. In Mike's earlier message, he said that the 12K savings from using ARP commands over AmigaDOS commands was "insignificant." Well, I haven't had my hard disk long enough to forget what using a floppy-based system was like, and 12K is very significant when you only have an 880K disk to boot from and half of it is taken up by necessary things like libraries and devices. In fact, that was the major reason why I bought a hard disk -- I wanted a huge environment with every command I could think of available to me at all times. --M -- Michael Portuesi Silicon Graphics Computer Systems, Inc. portuesi@SGI.COM
vkr@osupyr.mps.ohio-state.edu (Vidhyanath K. Rao) (08/03/89)
In article <26872@agate.BERKELEY.EDU> mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) writes: >Pre 1.3 versions broke a _very_ important piece of AmigaDOS syntax. Hmm... I don't remember this. >Note that taking out ARP is much harder than putting >it in. Not really: If you have a big, i.e. less than 80% full, hard disk, (as I do) put the ARP commands in a directory by themselves, say "ac", and put it in your path. To take out arp, just remove it from your path. It worked for me during the 1.2->1.3 switch. If you have floppies only, make whole new boot disks. Didn't take long for me:-^ I don't remeber having trouble with the standard run in c:. With ARP shell the difference between c:run and ac/run is supposed to be immeterial. >I've heard rumors that something similar to ARP, only better designed >(not cramming everything into one library) is on 1.4. I am not sure that not cramming everything in one library will save space: Assuming that 1.4 puts lots of things into shared libraries [note the plural] I will expect every shareware/commercial programs to use AmigaDOS style wildcards and templates for commands (rather than downloading programs from #?x and ??-dos). Keeping just GADS, FindFirst/FindNext, PreParse/PatternMatch and the necessary resource management routines used by these from arp.library is likely to save may be 20% of memory used by arp.library. In fact, if one is not careful in designing the hierarchy of the libraries one may end up using more ram than arp.library, even if the seperate libraries are each about 20-30%. Incidentatly, are there any estimates on how long it will take for a significant proportion of Amiga owners (especially 500 owners) to upgrade to 1.4? After all, I am supposed to be able include the arp.library with my programs for free. CBM is not likely to allow one to do that with the new 1.4 libraries. What happens with this scenario? -- It is the man, not the method, that Nath solves the problem. vkr@osupyr.mps.ohio-state.edu -Poincare. (614)-366-9341
mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) (08/03/89)
< In article <26872@agate.BERKELEY.EDU>
< mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) writes:
< >I've heard rumors that something similar to ARP, only better designed
< >(not cramming everything into one library) is on 1.4.
< I am not sure that not cramming everything in one library will save space:
< [speculations on storage costs of 1.4 libraries deleted]
<
<
<I think that when Mike said "better designed", he was referring to
<design philosophy rather than storage requirements. I.E. by putting
<only related functionality into each library, you get more efficient
<library usage -- you're not loading a bunch of excess baggage when you
<open a library to do something, but loading a bunch of related
<functions you probably needed to use anyway.
This is indeed what I meant. It probably does mean that with everything
loaded, you're using up more memory. On the other hand, if you've got
a large application and are tight for memory, you may be able to ditch
one or more libraries. If everything is in one monster library, this
just doesn't work.
<In Mike's earlier message, he said that the 12K savings from using ARP
<commands over AmigaDOS commands was "insignificant." Well, I haven't
<had my hard disk long enough to forget what using a floppy-based
<system was like, and 12K is very significant when you only have an
<880K disk to boot from and half of it is taken up by necessary things
<like libraries and devices.
Like to point out that I said it was insignificant on my hard drive,
and that if I were using a less resource-rich Amiga, I'd seriously
consider looking at ARP1.3. However, given that 1) it only changes
useage of resources I have more than enough of; 2) I've got "fixed"
variations of the AmigaDOS commands whose limits really bother me; and
3) 1.4 is liable to have something similar in it, I don't see a lot of
reason to look at arp. If either of the first two were false, it'd be
high on the list; if the third were false, it'd be somewhere on the
list. As things stand, I have more important things to do (like finish
mg3a...).
<>Pre 1.3 versions broke a _very_ important piece of AmigaDOS syntax.
<Hmm... I don't remember this.
Question: what's the fastest editor for writing short programs on
AmigaDOS?
If you didn't say "copy *" or something similar, you're wrong. I tend
to create short programs by saying "copy * testit.c" or some such.
About the third time I did that and ARP copy stated copying every file
onto testit.c one at a time, I blew it away. Continued interference
with the standard meaning of "*" made me back the rest of the mess
out. I've been told that 1.3 fixes this.
<>Note that taking out ARP is much harder than putting
<>it in.
<Not really: If you have a big, i.e. less than 80% full, hard disk, (as I do)
<put the ARP commands in a directory by themselves,
Except that this requires _not_ doing the installation the way it was
suggested with the distribution I got. I did, of course, back up all
the stuff it was going to replace. That still left me stumbling over
commands every once in a whlie that I hadn't restored correctly.
<I don't remeber having trouble with the standard run in c:. With ARP shell
<the difference between c:run and ac/run is supposed to be immeterial.
Since we're on the topic: Does the ARP shell support ARexx macros
properly? Most importantly, can I build a pair of macros "cd" &
"back", where cd records the current directory, and back goes back to
the last saved directory (I find this much more useful than any
directory stack implementation I've ever used).
<mike
Note to AmigaDOS bashers: "*" is another one of the things that
AmigaDOS does right that Unix does wrong. With this, you don't have to
hack every program to understand some magic token to mean "read from
standard input instead of opening the file." Good Unix systems (like
the 4BSD ones I run :-) have something similar but more powerful in
/dev/fd.
--
Il brilgue: les toves lubricilleux Mike Meyer
Se gyrent en vrillant dans le guave, mwm@berkeley.edu
Enmimes sont les gougebosqueux, ucbvax!mwm
Et le momerade horsgrave. mwm@ucbjade.BITNETrokicki@polya.Stanford.EDU (Tomas G. Rokicki) (08/04/89)
> Note to AmigaDOS bashers: "*" is another one of the things that > AmigaDOS does right that Unix does wrong. With this, you don't have to > hack every program to understand some magic token to mean "read from > standard input instead of opening the file." Good Unix systems (like > the 4BSD ones I run :-) have something similar but more powerful in > /dev/fd. Hi, Mike! I've always wanted to be able to fopen("|lpr", "w"), for instance, to spool things automatically, or anything else with pipes. Why hasn't any operating system (that I know of) allowed file names to also specify new processes? I mean, I can open `par:' or `ser:' or even `speak:'. Just a thought. > Il brilgue: les toves lubricilleux > Se gyrent en vrillant dans le guave, > Enmimes sont les gougebosqueux, > Et le momerade horsgrave. Clever; I like this. -tom
schemers@egrunix.UUCP (Roland Schemers) (08/04/89)
> I've always wanted to be able to fopen("|lpr", "w"), for instance, to > spool things automatically, or anything else with pipes. Why hasn't > any operating system (that I know of) allowed file names to also specify > new processes? I mean, I can open `par:' or `ser:' or even `speak:'. > Just a thought. Since no one else has posted an answer (I'm sure they will), I guess I'll do the honers. Unix has EXACTLY what you want. The system call is called popen! (Stands for Pipe? Process? open). Is has the following syntax: FILE *lpr_file; lpr_file = popen("lpr","w"); Then you can do all the normal file commands with it (fprint, etc...), and when you are do, just issue the pclose(lpr_file) call. I remember seeing a posting on swan.ulowell.edu, which has the popen call as written for the Amiga, although I do beleive you need Arp and a PIP: device to use it. roland (no cute sig) schemers
rokicki@polya.Stanford.EDU (Tomas G. Rokicki) (08/05/89)
> > I've always wanted to be able to fopen("|lpr", "w"), for instance, to > Since no one else has posted an answer (I'm sure they will), I guess > I'll do the honers. Unix has EXACTLY what you want. The system call is called > popen! (Stands for Pipe? Process? open). Is has the following syntax: You missed my point. I know it's possible like that. I want it to be part of the file system semantics, so when I'm typing to a file requestor or asked to supply a path, I can type |lpr. I don't want to change every program to look at the first character, if it's a pipe symbol turn it into a popen call. -tom
shadow@pawl.rpi.edu (Deven T. Corzine) (08/06/89)
On 3 Aug 89 11:13:56 GMT, mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) said: Mike> Note to AmigaDOS bashers: "*" is another one of the things that Mike> AmigaDOS does right that Unix does wrong. With this, you don't Mike> have to hack every program to understand some magic token to Mike> mean "read from standard input instead of opening the file." Mike> Good Unix systems (like the 4BSD ones I run :-) have something Mike> similar but more powerful in /dev/fd. AmigaDOS's "*" is _exactly_ analogous to Unix's "/dev/tty". "*" is NOT synonymous with stdin. You can do "cp /dev/tty file" under Unix and get exactly the same effect as "copy * file" under AmigaDOS. /dev/fd is something completely different which AmigaDOS has no equivalent to. Also, most Unix programs were not "hacked to understand some magic token" -- the traditional approach is to accept a file argument, or a number of them, or to use stdin if no files are specified. True, often "-" is interpreted as "use stdin", but you CAN'T do the same thing with AmigaDOS. For example, "ls -l | cat file1 - file2 > file3" will not work under AmigaDOS. Apart from not having pipes available, "list | join file1 * file2 >file3" would not take stdin for the second file. Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2214 12th Street, Troy, NY 12180 Phone: (518) 271-0750 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.
shadow@pawl.rpi.edu (Deven T. Corzine) (08/06/89)
On 4 Aug 89 06:55:23 GMT,
rokicki@polya.Stanford.EDU (Tomas G. Rokicki) said:
Rokicki> I've always wanted to be able to fopen("|lpr", "w"), for
Rokicki> instance, to spool things automatically, or anything else
Rokicki> with pipes. Why hasn't any operating system (that I know of)
Rokicki> allowed file names to also specify new processes? I mean, I
Rokicki> can open `par:' or `ser:' or even `speak:'. Just a thought.
par:, ser: and speak: are devices, as in /dev/* under Unix. What if
you wanted to open a file named "|lpr"? Besides, there's popen()...
Deven
--
Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu
Snail: 2214 12th Street, Troy, NY 12180 Phone: (518) 271-0750
Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven
Simple things should be simple and complex things should be possible.cosell@bbn.com (Bernie Cosell) (08/06/89)
In article <SHADOW.89Aug5174731@pawl.rpi.edu> shadow@pawl.rpi.edu (Deven T. Corzine) writes: } }On 4 Aug 89 06:55:23 GMT, }rokicki@polya.Stanford.EDU (Tomas G. Rokicki) said: } }Rokicki> I've always wanted to be able to fopen("|lpr", "w"), for }Rokicki> instance, to spool things automatically, or anything else }Rokicki> with pipes. Why hasn't any operating system (that I know of) }Rokicki> allowed file names to also specify new processes? I mean, I }Rokicki> can open `par:' or `ser:' or even `speak:'. Just a thought. } }par:, ser: and speak: are devices, as in /dev/* under Unix. What if }you wanted to open a file named "|lpr"? Besides, there's popen()... On the other hand, if yo'd like to try it to see if you like it, you could check out 'perl' (available for most all Unixes and the Amiga)... it does *exactly* that it has just one 'open' call, but that one includes in the syntax of the file name the usual shell operation-control chars, so you don't do "r" to read, you do "<filename".. similarly, to do the equivalent of "popen(xxx, "w")", you just do "open ("|xxx")". The fact is (a) it works out to be very nice, and very convenient, indeed, and (b) the collision with filenames with '|' as their first char and the like turns out not to be a problem. Unix would be better to have fopen() work that way. On the other hand, there is *absolutely* no reason why Tom or Deven or me could't just write a sexyopen() that does just that. The underlying machinery (in Unix, at least) is all trivially there, and so sexyopen would be a piece of cake to write. Not so easy in AmigaDOS, I suspect... /Bernie\
DMasterson@cup.portal.com (David Scott Masterson) (08/07/89)
In message <11119@polya.Stanford.EDU>, rokicki@polya.Stanford.EDU writes: >> > I've always wanted to be able to fopen("|lpr", "w"), for instance, to > >> Since no one else has posted an answer (I'm sure they will), I guess >> I'll do the honers. Unix has EXACTLY what you want. The system call is called >> popen! (Stands for Pipe? Process? open). Is has the following syntax: > >You missed my point. I know it's possible like that. I want it to be part >of the file system semantics, so when I'm typing to a file requestor or >asked to supply a path, I can type |lpr. I don't want to change every >program to look at the first character, if it's a pipe symbol turn it >into a popen call. > Hmmm, I think I missed something also... If you want it to be apart of "your" filesystem semantics, you could always roll your own rapping function (which you can then make available so it might become a defacto standard ;-). However, I can't see making this a part of the file system because it can't be completely compatible. Using fopen("|lpr", "w") makes good sense, but fopen("|lpr", "r") does not. Also, extending the idea, fopen("sort|", "r") makes sense, but fopen("sort|", "w") does not. Therefore, making this capability part of the filesystem semantics would lead to certain things being semantically correct and other things not being semantically correct. David Masterson DMasterson@cup.portal.com
hopp@agnes.uucp (Eric D. Hopp) (08/07/89)
>On 4 Aug 89 06:55:23 GMT, >rokicki@polya.Stanford.EDU (Tomas G. Rokicki) said: > >Rokicki> I've always wanted to be able to fopen("|lpr", "w"), for >Rokicki> instance, to spool things automatically, or anything else >Rokicki> with pipes. Why hasn't any operating system (that I know of) >Rokicki> allowed file names to also specify new processes? I mean, I >Rokicki> can open `par:' or `ser:' or even `speak:'. Just a thought. As I read this thread, I couldn't help but think of UNIX version 9. Since version 7 was released to the world, the people at Bell Labs who originally developed UNIX have kept on tinkering, with some really nice results. I was only able to take a short look at the version 9 manual, but it looks like version 9 is very well designed. One nice feature is the ability to mount nearly *anything* in the file system. This includes pipes and processes. (I. E., run your debugger on /proc/8973.) I take this to mean that one could have a "| lpr" whose input end was "/pipe/lpr". Version 9 has a lot of other neat things, but this is probably the wrong place to discuss them. I've said all I know, so if you'd like to know more, find a copy of the version nine manual, the proper issues of AT&T's "Bell Labs technical journal" (Is that name right?), or ask in the proper news groups. If you appreciate beautiful system architecture, I think it's worth looking at. -eric hopp hopp@stolaf.edu (St. Olaf College)
lee@sed170.HAC.COM (John Lee) (08/08/89)
In article <11107@polya.Stanford.EDU> rokicki@polya.Stanford.EDU (Tomas G. Rokicki) writes: [...] >I've always wanted to be able to fopen("|lpr", "w"), for instance, to >spool things automatically, or anything else with pipes. Why hasn't >any operating system (that I know of) allowed file names to also specify >new processes? I mean, I can open `par:' or `ser:' or even `speak:'. >Just a thought. [...] Well, I can think of several reasons, not all real justifications, but they're better than "because the system designers/programmers were lazy." :-) First of all, "|lpr" is a legal filename in many filesystems, include UNIX and AmigaDOS. I've used filesnames like that on occasion, or used other funny characters (e.g., "~" or "$") for filenames. Not everybody names their files the same way or for the same reasons. Secondly, redirection operators/symbols are usually in the domain of the shell/user interface, since usually they define the semantics of operation rather than the operating system. Redirection can mean different things depending on the source and/or destination. This is best left up to the shell, although the operating system must have the capabilities or generality to implement various piping/redirection schemes. Remember, even UNIX doesn't have redirection built-in, just a mechanism ("pipes") that shells use to implement redirection. Thirdly, it depends on the design and meaning of "a filename" and the "filespace". In some operating systems, a filename can indeed mean a process. Opening such a "file" actually creates a pipe to and/or from the process like you want. AmigaDos even has little flavor of this, since the filename "CON:100/100/20/50/Test" means open a CON: window of a certain size named "Test". Usually, however, a "filename" is the name of a file on a mass-storage device, and then "|lpr" is inappropriate for a function designed to open a file. It's whatever was decided upon by the designer. Fourthly, there is nothing preventing one from writing a smartopen() which does what you want, depending on the operating system. The resultant code would probably be very similar to that written if it were built into the operating system. Like I said, not exactly concrete reasons. It's more of a stylistic judgement made by the system designers of whether or not the operating system should support redirection directly or to just provide a general mechanism. Personally, I don't think fopen() should support it. --John Lee ------------------------------------------------------------------------------- Raining CATS and DOGS? Join the RATS: Remote Amiga Teleconferencing System +--------+ John Lee | HUGHES | +--------+ ARPAnet: jhlee@hac2arpa.hac.com Hughes Aircraft Company The above opinions are those of the user and not of those of this machine.
peter@sugar.hackercorp.com (Peter da Silva) (08/27/89)
> >You missed my point. I know it's possible like that. I want it to be part > >of the file system semantics, so when I'm typing to a file requestor or > >asked to supply a path, I can type |lpr. I don't want to change every > >program to look at the first character, if it's a pipe symbol turn it > >into a popen call. fopen("PIPE:print", "w"); (switch to another CLI) lpr PIPE:print I think I suggested that a "CLI:" handler would be a useful addition last year some time, with the semantics you suggested. The nice thing about the Amiga is that you can relatively easily create a new handler with whatever semantics you want... > Therefore, making this capability part of > the filesystem semantics would lead to certain things being semantically > correct and other things not being semantically correct. Now this I don't understand. After all, that's already the case: fopen(non-existant-file, anything) Is syntactically correct and semantically incorrect. -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U` "before making up your mind, please read the book." -- sherry.mann "This is contrary to the spirit of rec.arts.sf-lovers" -- Jim Winer