numb@cs.qmw.ac.uk (Matt Newman) (05/24/91)
Flame On: I'm getting more and more fed up of trying to bring software from usenet up on our A/UX machines. So few things compile without considerable massaging I type `uname -a` and get :- A/UX pinkruby 2.0 SVR2 mc68030 ^^^^ Help! When are Apple going to make a serious comitment to Unix and bring their OS upto date, alot of vendors are now shipping SVR4 and Apple is very proud to manage to ship SRV2 :-(. Users find systems far more "open" if they can take sources and compile and run them on a number of Unix/Posix/XPRG etc etc (insert favorite Unix std. OSF/1 !) without to many problems. So, what do you say Apple, are you serious about Unix or is it a filler until System 7 is fully underway. Flame Off: We have ~172 machines runnignn A/UX 2.0. Personnally A/UX 1.1.1 was better :-) -- Matt Newman
tony@tui.marcam.dsir.govt.nz (Tony Cooper) (05/25/91)
In article <numb.675098076@el_greco>, numb@cs.qmw.ac.uk (Matt Newman) writes: |> I'm getting more and more fed up of trying to bring software from usenet |> up on our A/UX machines. So few things compile without considerable massaging The correct spelling is 'archaic' (even in the UK). I think your statement is so obvious (is the Pope Catholic?) that we can safely assume that Apple is working on SVR4 right this minute. I'm sure that Apple are aware that anyone who is going to buy unix is going to buy eg SunOS for which there are thousands of programs available, rather than A/UX for which the number is (guessing) in single figures. |> Personnally A/UX 1.1.1 was better :-) True. There are more third party programs written for 1.1.1 than 2.0. That's because third party people thought that A/UX was going to be a better seller than it turned out to be. When 2.0 came along they were wiser. I think 2.0 is better if you know how to use it. 2.0 has three unix environments SVR?, BSD, and POSIX. There are compiler options for using them easily. The skill is in knowing which ones to use (and using combinations of them). I don't know what the ? is but it's sort of 2 and sort of 3, but A/UX definitely is not solely SVR?. It has the good bits of several unixes plus a bit of MacOS in it. Porting is a pain but most bits are there if you can find them (except BSD tty stuff, for example). Have you noticed that with time, A/UX is looking more like MacOS and MacOS is looking like A/UX? I would like to see this continue till they converge and A/UX is dropped. Then MacOS will be unix compatible and buyers will not buy SunOS when for the same price they can get MacOS on superior hardware. Then it will be a kind of MacOS/Motif/OpenLook war where MacOS clearly wins since it has everything the others have plus thousands of MacOS programs. Imagine adding devices to the kernel by dropping them into the Extensions folder and adding daemons to the startup folder and adding a uucp module to the communications folder or POSIX, BSD, or whatever tty modules you want etc. Tony Cooper sramtrc@albert.dsir.govt.nz
d88-jwa@cyklop.nada.kth.se (Jon W{tte) (05/25/91)
In article <numb.675098076@el_greco> numb@cs.qmw.ac.uk (Matt Newman) writes:
I'm getting more and more fed up of trying to bring software from usenet
up on our A/UX machines. So few things compile without considerable
massaging
Just adding -D_SYSV_SOURCE -D_BSD_SOURCE to the CFLAGS in the make files
seems to help a lot. I have many packages (gnu c, g++, gnu emacs,
tvtwm, xchomp to name a few) and they weren't hard to compile (GNU much
thanx to the extensive porting job that's already been done, thanx !)
I type `uname -a` and get :-
A/UX pinkruby 2.0 SVR2 mc68030
Help! When are Apple going to make a serious comitment to Unix and
bring their OS upto date, alot of vendors are now shipping SVR4 and
Apple is very proud to manage to ship SRV2 :-(.
So what's so good about SYSV.4 ? The kernel panics ?
A/UX offers almost all the BSD stuff (except the tty driver, but we
can do without that) AND full POSIX AND SVR2 which still is a solid
base. Of course I hope to see SVR4 within a year, but methinks the
direction it's heading is towards Mach, maybe even on a new CPU...
Users find systems far more "open" if they can take sources and
compile and run them on a number of Unix/Posix/XPRG etc etc (insert
favorite Unix std. OSF/1 !) without to many problems.
Just define the right things. Use gcc if you need ANSI headers.
It's NOT hard to move stuff to A/UX (hey, nethack is plain USG
and works great with posix job control !)
--
Jon W{tte
h+@nada.kth.se
- Power !gilbertd@cricket.bio.indiana.edu (Don Gilbert) (05/25/91)
In article <1991May25.052820.27220@am.dsir.govt.nz> sramtrc@albert.dsir.govt.nz writes: >Have you noticed that with time, A/UX is looking more like MacOS and MacOS is >looking like A/UX? I would like to see this continue till they converge >and A/UX is dropped. Then MacOS will be unix compatible and buyers will not >buy SunOS when for the same price they can get MacOS on superior hardware. >Then it will be a kind of MacOS/Motif/OpenLook war where MacOS clearly wins >since it has everything the others have plus thousands of MacOS programs. Yes -- I think this is where Apple could make another big impact in the system software/user interface area. Perhaps the quote in MacWeek that Apple hopes to be one of the top 2 *Unix* vendors in the next few years is a clue that Apple thinks so also (System 8 == A/UX 3 on a few million macs would have an impact). -- Don -- Don Gilbert gilbert@bio.indiana.edu biocomputing office, biology dept., indiana univ., bloomington, in 47405
ron@afsg.apple.com (Ron Flax) (05/25/91)
In article <numb.675098076@el_greco> numb@cs.qmw.ac.uk writes: >I'm getting more and more fed up of trying to bring software from usenet >up on our A/UX machines. So few things compile without considerable massaging Matt, I'd like to hear what software you are trying to port. I have quite easily ported many things that have been posted/available on USENET to A/UX. A/UX provides most everything you need to port BSD, SYSV, and even POSIX apps. All of the relevent USENET news software, less, emacs, gcc, gdb, gas, rn, tcsh, ntp, nntp, etc, etc, etc... So what's the problem. >Help! When are Apple going to make a serious comitment to Unix and bring their >OS upto date, alot of vendors are now shipping SVR4 and Apple is very proud >to manage to ship SRV2 :-(. Granted SVR2 by it self is a rather old version of UNIX, A/UX includes most of the feature set in todays SVR4. What features would you like to see. Have you actually used a SVR4 system, have you tried porting USENET software to it? Ever try porting a character based device driver to SVR4 streams? >Users find systems far more "open" if they can take sources and compile and run >them on a number of Unix/Posix/XPRG etc etc (insert favorite Unix std. OSF/1 !) >without to many problems. Actually OSF/1 is only XPG2 compliant, with the hopes that the next release will be XPG3 compliant. That's about equivalent to SVID 2. >So, what do you say Apple, are you serious about Unix or is it a filler until >System 7 is fully underway. We are very serious about UNIX, our development staff has more than doubled in the past 6-12 months and we are continuing to improve A/UX as we go. >We have ~172 machines runnignn A/UX 2.0. Yes I know, I was at QMW in April of this year... You really should be running A/UX 2.0.1 which is the current release now. -- Ron Flax ron@afsg.apple.com Apple Federal Systems Group
steveg@melmac.umd.edu (Steve Green) (05/26/91)
In article <573@afsg.apple.com> ron@afsg.apple.com (Ron Flax) writes: >In article <numb.675098076@el_greco> numb@cs.qmw.ac.uk writes: >>I'm getting more and more fed up of trying to bring software from usenet >>up on our A/UX machines. So few things compile without considerable massaging > >Matt, > >I'd like to hear what software you are trying to port. I have quite >easily ported many things that have been posted/available on USENET to >A/UX. A/UX provides most everything you need to port BSD, SYSV, and >even POSIX apps. All of the relevent USENET news software, less, emacs, >gcc, gdb, gas, rn, tcsh, ntp, nntp, etc, etc, etc... So what's the problem. > >[deleted stuff about the Apple's commitment to AUX] Ditto. If you (Matt) expect stuff from USENET to just compile "out of the box" then you are mislead. Most of the stuff from USENET works great on the most popular platforms.. of course.. thats what people are using. (Sun, Dec, etc..) Many other UNIX platforms suffer from the same problem that AUX does.. its not vanilla this or vanilla that. Things are no different for many of the other SysV based machines with BSD extensions. (I have had many of the same problems with IRIX and Unicos that I originally had with AUX) A program with any degree of complexity is going to have #ifdefs for different platforms. The problem as I see it is that too many assumptions are made if you #define SYSV. Programs that have #ifdefs based on system calls, include files, libraries, etc.. usually port without any trouble to AUX. (Larry Wall's stuff is great) AUX is actually a very good platform to port stuff to. Just remember, it could have been 172 386s that you have... Seriously though, if you port something to AUX, send the patches back to the original author so they can get worked in. As well, send it to one of the archives so we all can benifit. -- Silica gel -- Do not eat. steveg@melmac.umd.edu Disclaimer: If anything I said above is incorrect, never mind.
ksand@apple.com (Kent Sandvik) (05/27/91)
In article <numb.675098076@el_greco>, numb@cs.qmw.ac.uk (Matt Newman) writes: > > Flame On: > > I'm getting more and more fed up of trying to bring software from usenet > up on our A/UX machines. So few things compile without considerable massaging > I type `uname -a` and get :- > A/UX pinkruby 2.0 SVR2 mc68030 > Help! When are Apple going to make a serious comitment to Unix and bring their > OS upto date, alot of vendors are now shipping SVR4 and Apple is very proud > to manage to ship SRV2 :-(. Hehe, I remember when I was a young engineer and always complained that the vendor did not ship the latest, flashy version. Little did I know. If you check the features and compare with SysV.4 you will notice that there are things missing, but not that many as you would expect... As for porting, you need to sweat in the UNIX world; the quality of the public domain code is usually the main issue concerning porting activities, and I don't think many are writing POSIX compliant PD code yet. As for SunOS, I remember one nice sunny day in Sydney, when we found out that the SysV emulation libraries were badly broken in SunOS, and we had to rewrite the i/o parts of our app in front of the customer for the port... Kent Sandvik, DTS Platforms Group, Apple
liam@cs.qmw.ac.uk (William Roberts;) (05/28/91)
In <numb.675098076@el_greco> numb@cs.qmw.ac.uk (Matt Newman) writes: >I'm getting more and more fed up of trying to bring software from usenet >up on our A/UX machines. I think he's complaining about "mush" amongst other things. We don't run our A/UX machines in anything like a standard configuration, we don't use the Apple C compilers, we are mostly interested in language systems which do tend to get a bit machine specific, COFF files are something of a mystery to "Suns and VAXes" code.... We also have obselete systems to cooperate with, for example a Sequent Balance which doesn't believe in lockd. >We have ~172 machines running A/UX 2.0. Actually it is only about 110, but we'll get the other 40+ eventually. 2.0.1 when we get the CD (which will presumably not happen until after I've ordered the CD). >Personally A/UX 1.1.1 was better :-) It wasn't significantly different for the kinds of things Matt is complaining about. On a more positive note, ask yourself which manufacturer who has released an operating system upgrade in the last 6 months has actually cleaned up their include files for ANSI C? Not SunOS 4.1.1B. Yes, it's A/UX 2.0.1. Will we be seeing a similar tirade on comp.sys.sun - they aren't planning to ship SVR4 anytime soon... -- William Roberts Internet: liam@dcs.qmw.ac.uk Queen Mary & Westfield College UUCP: liam@qmw-dcs.UUCP Mile End Road AppleLink: UK0087 LONDON, E1 4NS, UK Tel: +44 71-975 5234 (Fax: +44 81-980 6533)
gene@segue.segue.com (Gene Hightower) (05/28/91)
In article <1991May25.052820.27220@am.dsir.govt.nz> sramtrc@albert.dsir.govt.nz writes: >I think your statement is >so obvious (is the Pope Catholic?) that we can safely assume that Apple is >working on SVR4 right this minute. Assume whatever you will. Apple is not known as a progressive company. Shipping a system that calls itself S5R2 at this point in time tells me that Unix and open systems take a back seat to the very closed MacOS that is the bread and butter of Apple. In article <1991May25.052820.27220@am.dsir.govt.nz> sramtrc@albert.dsir.govt.nz writes: >Have you noticed that with time, A/UX is looking more like MacOS and MacOS is >looking like A/UX? I would like to see this continue till they converge >and A/UX is dropped. Then MacOS will be unix compatible and buyers will not >buy SunOS when for the same price they can get MacOS on superior hardware. Since when has Apple ever produced "superior hardware" at the "same price" as Sun, or anyone else for that matter. Macintosh systems are simple 68k boxes with no special or interesting features at all. Apple is always behind on clock speed and CPU type. Right now, I think, Apple's high end system is a 68030 at 40MHz where other vendors (i.e. HP and NeXT) are shipping 50MHz '030 systems and 25MHz '040 systems. Other vendors (Sun included) give you ethernet and much better video systems as standard features not requiring extra cards. Apple is not in the business of offering "bang for the buck." >Then it will be a kind of MacOS/Motif/OpenLook war where MacOS clearly wins >since it has everything the others have plus thousands of MacOS programs. Try not to mix up user interface with operating systems. Apple likes you to do this because all they have to offer over other 68k boxes is some user interface code written some years ago and a base of shrink-wrapped applications that use it. Operating systems are to provide things like process scheduling, memory management, filesystems/disk management and networking. MacOS can't do those kinds of things like most current Unix systems can. Window systems and (more correctly) GUI toolkits and guidelines provide support for user interaction. I think that no clear winner has been chosen in the GUI war. -- ++ Gene Hightower gene@segue.com aero!segue!gene
d88-jwa@byse.nada.kth.se (Jon W{tte) (05/28/91)
In article <7661@segue.segue.com> gene@segue.segue.com (Gene Hightower) writes:
company. Shipping a system that calls itself S5R2 at this point in
time tells me that Unix and open systems take a back seat to the very
closed MacOS that is the bread and butter of Apple.
Hmm.. There's this thing called MacMach that we've been hearing
about now & then...
Since when has Apple ever produced "superior hardware" at the "same
price" as Sun, or anyone else for that matter. Macintosh systems are
simple 68k boxes with no special or interesting features at all.
Except maybe competetive third-party disks & other peripherals,
plus EXTENDED video support. I know of NO other system that so
seamlessly integrates several screens of different depth on one
machine (yes, windows across a 24bit screen and a b/w work very well)
Apple is always behind on clock speed and CPU type. Right now, I
think, Apple's high end system is a 68030 at 40MHz where other vendors
(i.e. HP and NeXT) are shipping 50MHz '030 systems and 25MHz '040
They had that '30 with 40MHz 1.5 years ago, too. I firmly believe
a '40 machine is a matter of months. (or is that hope ?)
Other vendors (Sun included) give you ethernet and much better video
systems as standard features not requiring extra cards.
Well, there's always the price... And Sun video software stinks
when compared to Mac OS. Compare Mac third party video hardware
while you're at it...
Apple is not in the business of offering "bang for the buck."
No, "ability for the buck," or maybe "experience for the buck"
is closer. What matters ?
Try not to mix up user interface with operating systems. Apple likes
you to do this because all they have to offer over other 68k boxes is
some user interface code written some years ago and a base of
shrink-wrapped applications that use it.
Have you seen the latest release of OS software, aka system 7 ?
That's not written "some years ago."
Operating systems are to provide things like process scheduling,
memory management, filesystems/disk management and networking. MacOS
can't do those kinds of things like most current Unix systems can.
No, it provides them unlike the UNIX way. With A/UX you have both.
The NBP and ZIP of AppleTalk are good services, for instance...
All of this is in the mac os, only differently from UNIX.
Window systems and (more correctly) GUI toolkits and guidelines
provide support for user interaction.
So where's the consistency ?
I think that no clear winner has been chosen in the GUI war.
Well, I've used X11R4 with twm, tvtwm, Motif, ...
I've used Windows 3
I've even used some other esoteric GUIs now and then.
And I've used a Mac. I know what I like. If you don't, nobody's
forcing you to use it.
--
Jon W{tte
h+@nada.kth.se
- Speed !tony@tui.marcam.dsir.govt.nz (Tony Cooper) (05/28/91)
In article <7661@segue.segue.com>, gene@segue.segue.com (Gene Hightower) writes: |> Since when has Apple ever produced "superior hardware" at the "same |> price" as Sun, or anyone else for that matter. Macintosh systems are I was speaking in the future wishfully. I was setting out some aims for Apple. One aim should be to produce competitive hardware. The success of the cheap Macs has proved that price makes a difference. |> Try not to mix up user interface with operating systems. Apple likes |> |> Operating systems are to provide things like process scheduling, |> memory management, filesystems/disk management and networking. MacOS |> can't do those kinds of things like most current Unix systems can. |> Good point. MacOS has a great user interface but only a "fair" operating system. |> I think that no clear winner has been chosen in the GUI war. I think that the MacOS GUI is a clear leader for the time being. But let's not debate that point. What I would like to say in this posting is that I think Apple's claims regarding the MacOS interface for UNIX are misleading. I once looked at an Apple ad in Unixworld for A/UX and nearly every claim they made was not true. I don't have the ad handy so I can't pull it to bits right now. But basically, A/UX does not provide a graphical interface to Unix. All that it does is to provide windows within which the usual command line interface gets used. I can provide the same "graphical interface" by taking a terminal to some Unix box and a can of paint and painting a title bar and scroll bars etc on the terminal. Sure, A/UX does give you multiple windows but they act no differently from having multiple terminals. The only advantage is cut and paste between windows, which cannot be done with terminals. Where I am wrong is in the Finder interface to file manipulation. This truely is a graphical interface. But all it does is let you move, rename, delete, and copy files graphically. But these are nothing really to do with Unix. These operations are common to any operating system, are simple, and hardly help at all in hiding the unfriendly parts of Unix from the user. The user still has to deal with things like file potections, pipes, the man pages, the syntax of commands, blah blah blah - all the horrible bits of Unix. In fact, some of these things have been further complicated by the interface. For example, there are now two sets of file protections; the Unix set, and the MacOS set. You can lock a file using the get info box but Unix still thinks it is unlocked and can happily delete it, not knowing that it is locked. Where Apple have improved the interface to Unix is in the use of Commando and in providing a MacOS style editor (TextEdit). It seems that Apple spend most of their time providing MacOS compatibility under A/UX. For all the work involved, it does not provide much to the user. It only provides emulation of an operating system that the user has already. When you think about it, that is the dumbest thing anybody could do. People must have better things to do with their money than to buy a package that emulates an operating system that they already have. Why would anyone want to run a program under A/UX+MacOS rather than under MacOS? I could understand it if A/UX made MacOS better in some way, but it doesn't. the emulation will always be inferior to the real thing. And that will never change. Unix software houses will write Unix software because they will have a bigger market that way than if they write just for A/UX. And MacOS software houses will write MacOS software using MacOS features, not Unix features because more people will have pure MacOS than A/UX. The only reason to have MacOS running under A/UX is to avoid the convenience of rebooting to run MacOS programs. And this is only an advantage when one has only one computer. If you have two machines or more and want MacOS and Unix then the sensible thing to do is buy a MacOS machine and a common Unix machine. Then you get the advantages of being able to use lots of MacOS software and lots of Unix software. But if you buy two Macs you get to run lots of MacOS software and a little bit of Unix software (and probably pay more for the hardware than if you bought a pure Unix machine). In short, A/UX provides an "inferior" Unix and an inferior MacOS. I love it because I like having both. (I put the word in quotes because I mean in the limited sense of "inferior number of commercial software packages available". Cheers, Tony Cooper sramtrc@albert.dsir.govt.nz
rmtodd@servalan.uucp (Richard Todd) (05/29/91)
liam@cs.qmw.ac.uk (William Roberts;) writes: >In <numb.675098076@el_greco> numb@cs.qmw.ac.uk (Matt Newman) writes: >>I'm getting more and more fed up of trying to bring software from usenet >>up on our A/UX machines. >I think he's complaining about "mush" amongst other things. We don't run our Mush? Shoulda told us that long ago. See end of posting for shar file containing hacked Makefile, config.h, and diffs for Mush (alas, only for v7.1, I haven't gotten around to getting v7.2.x of Mush yet). Give it a whirl. I think it even compiles with standard A/UX cc.... >about. On a more positive note, ask yourself which manufacturer who has >released an operating system upgrade in the last 6 months has actually cleaned >up their include files for ANSI C? Not SunOS 4.1.1B. Yes, it's A/UX 2.0.1. I seem to recall a good many complaints on this very newsgroup about the new "improved" include files breaking things left and right. Sigh. (IMHO, if they were going to do massive wholesale ANSI-fying of include files, they shoulda put the new ones in some other directory (say, "/usr/local/lib/gcc- include"), where they'll only be seen by C compilers running in ANSI mode, (e.g. gcc without "-traditional") and left the "standard" .h files in /usr/include. Just think, it'd mean we could all say goodbye to "fixincludes" forever....) Anyway, here be the mush patches. Enjoy. #--------------------------------CUT HERE------------------------------------- #! /bin/sh # # This is a shell archive. Save this into a file, edit it # and delete all lines above this comment. Then give this # file to sh by executing the command "sh file". The files # will be extracted into the current directory owned by # you with default permissions. # # The files contained herein are: # # -rw-r--r-- 1 rmtodd root 1199 Nov 3 00:59 mush.aux.diffs # -rw-r--r-- 1 rmtodd root 5383 Jun 10 01:34 config.h # -rw-r--r-- 1 rmtodd root 1615 Nov 2 20:06 Makefile # echo 'x - mush.aux.diffs' if test -f mush.aux.diffs; then echo 'shar: not overwriting mush.aux.diffs'; else sed 's/^X//' << '________This_Is_The_END________' > mush.aux.diffs X*** /tmp/,RCSt1a29697 Sat Nov 3 00:56:35 1990 X--- mail.c Sat Nov 3 00:55:10 1990 X*************** X*** 1234,1240 **** X--- 1234,1244 ---- X switch (fork()) { X case 0: /* the child will send the letter. ignore signals */ X #ifdef SYSV X+ #ifndef AUX X if (setpgrp() == -1) X+ #else X+ if (setpgrp(0, getpid()) == -1) X+ #endif /* AUX */ X #else /* SYSV */ X if (setpgrp(0, getpid()) == -1) X #endif /* SYSV */ X*** /tmp/,RCSt1a29702 Sat Nov 3 00:56:39 1990 X--- main.c Sat Nov 3 00:55:11 1990 X*************** X*** 31,41 **** X--- 31,46 ---- X register char *p; X struct mush_flags Flags; X X+ X #ifndef INTERNAL_MALLOC X extern char *stackbottom; /* used by xfree() */ X X stackbottom = (char *) &argc; X #endif /* INTERNAL_MALLOC */ X+ X+ #ifdef AUX X+ set42sig(); X+ #endif X X #ifdef LCKDFLDIR X lckdfldir = LCKDFLDIR; X*** /tmp/,RCSt1a29707 Sat Nov 3 00:56:42 1990 X--- mush.h Sat Nov 3 00:55:13 1990 X*************** X*** 69,74 **** X--- 69,77 ---- X #else X # include <sys/types.h> X # include <signal.h> X+ # ifdef AUX X+ # include <sys/time.h> X+ # endif X # ifndef SYSV X # include <sys/time.h> X # include <sys/ioctl.h> /* for ltchars */ ________This_Is_The_END________ if test `wc -l < mush.aux.diffs` -ne 51; then echo 'shar: mush.aux.diffs was damaged during transit (should have been 51 bytes)' fi fi ; : end of overwriting check echo 'x - config.h' if test -f config.h; then echo 'shar: not overwriting config.h'; else sed 's/^X//' << '________This_Is_The_END________' > config.h X/* config.h 1.1 (c) copyright 1986 (Dan Heller) */ X X/* Default names and locations for files */ X#define MAILRC ".mushrc" X#define ALTERNATE_RC ".mailrc" X#define DEFAULT_RC "/usr/lib/Mushrc" X#define ALT_DEF_RC "/usr/lib/Mail.rc" X#define COMMAND_HELP "/usr/local/lib/cmd_help" X#ifdef SUNTOOL X# define TOOL_HELP "/usr/lib/tool_help" X#endif /* SUNTOOL */ X#define ALTERNATE_HOME "/tmp" /* Path must be read/write to EVERYONE */ X#define EDFILE ".edXXXXXX" /* file/pathname added to user's "home" */ X X/* X * Define INTERNAL_MALLOC and recompile if you have trouble with mush X * core-dumping due to malloc/free errors. Also, if you run a System 5 X * variant, you might notice a performance improvement if you define this X * variable. It uses the malloc distributed by Larry Wall for perl v2. X */ X/* #define INTERNAL_MALLOC /**/ X X/* X * Define TIMEZONE if your system has neither the SysV external variable X * tzname nor the BSD timezone() function. The example below is for X * Gould BSD4.3 systems; others should define it as a string, e.g. "PST" X * If TIMEZONE is defined, DAYLITETZ can also be defined, e.g. "PDT" X */ X/* #define TIMEZONE T->tm_zone /**/ X X/* mail delivery system macros and defines... */ X X/* X * If you are using MMDF, define MMDF here. X */ X/* #define MMDF /**/ X#ifdef MMDF X/* X * If MMDF delivers mail the user's home directory, define HOMEMAIL. X * Also check the definition of the delivery file name MAILFILE, below. X */ X/* #define HOMEMAIL /**/ X#define MAIL_DELIVERY "exec /usr/mmdf/bin/submit -mlnr" X#define VERBOSE_ARG "Ww" X#define MTA_EXIT 9 /* exit status for successful submit */ X#else /* MMDF */ X/* X * If you are not using MMDF, check these definitions. X */ X#define MAIL_DELIVERY "/bin/smail" /* "-i" works like "-oi" */ X#define VERBOSE_ARG "-v" /* undef if none exists */ X/*#define METOO_ARG "-m" /* man sendmail for more info. */ X#define MTA_EXIT 0 /* exit status for successful mail delivery */ X#endif /* MMDF */ X X/* If your mail transfer agent uses something *besides* "From " to separate X * adjacent messages in a folder, define MSG_SEPARATOR to be this string. X * If that string is 4 ^A's, then the string would be "\001\001\001\001". X * With the exception of MMDF, below, you should OMIT a trailing newline X * from the setting of MSG_SEPARATOR. X * If you don't know what any of this means, leave it alone. X */ X/* #define MSG_SEPARATOR "From " /**/ X#ifdef MMDF X/* X * These values should be identical (respectively) to the contents of X * delim1 and delim2 in MMDFSRC/conf/yoursite/conf.c (sans newline). X */ X#define MSG_SEPARATOR "\001\001\001\001\n" X#define END_MSG_SEP "\001\001\001\001\n" X/* X * You only need to define LCKDFLDIR if you have MMDF configured to use the X * locking routines in lib/util/lk_lock.c (ie., link(2)-based locking). X * Most of you WILL NOT need this, since you probably use one of the more X * sophisticated locking modules provided with MMDF. Remember to alter the X * Makefile so as to access the MMDF library at the link step. X */ X/* #define LCKDFLDIR "/usr/spool/mmdf/lockfiles" /* (for example) */ X#else /* !MMDF */ X#ifdef M_XENIX X#define DOT_LOCK /* DOT_LOCK should be used for SCO Xenix */ X#endif /* M_XENIX */ X#endif /* MMDF */ X X/* If your mailer does not understand commas between addresses, you should X * define NO_COMMAS. This includes pre-3.0 smail and default MTAs used on X * xenix, and sys-v systems. X * This does NOT apply to MMDF or sendmail. X */ X#define NO_COMMAS /**/ X X/* X * Most RFC822 compliant mailers (sendmail) will add the headers From: X * and Date: on outgoing mail. If the user or UA sends these headers, X * most MTAs will not append them automatically. However, there are X * certain MTAs which will not allow this -- these "picky mailers" will X * precede such headers with a '>' and make the headers very ugly and X * somewhat redundant or contradictory. It is advisable to set this X * *UNLESS* your MTA is not RFC822 compiant -- therefore you should NOT X * set this (xenix, sys-v). X */ X/* #define PICKY_MAILER /**/ X X/* Headers that will NOT be included when forwarding mail */ X#define IGNORE_ON_FWD "status" /* comma or space separated list */ X X#define MAXMSGS 1000 /* maximum number of messages we can read */ X#define HDRSIZ BUFSIZ /* This should not be < BUFSIZ! (but can be >) */ X X/* If your system supports the vprintf() functions, True for sys-v and X * later sun versions (3.0+ ?). Typically not true for BSD systems, but X * that will probably change in the future. X */ X#if defined(SYSV) || defined(sun) X#define VPRINTF X#endif /* SYSV || sun */ X X#define LS_COMMAND "ls" X#define FORTUNE "/usr/games/fortune" X#define LPR "lpr" X#define SIGNATURE ".signature" X#ifdef HOMEMAIL X#define MAILFILE "Mailbox" /* or whatever */ X#else /* HOMEMAIL */ X#define MAILDIR "/usr/mail" X#endif /* HOMEMAIL */ X X/* default settings for some variable strings */ X#define DEF_PROMPT "Msg %m of %t: " X#define DEF_PAGER "more" /* set to "internal" to use internal pager */ X#define DEF_SHELL "csh" X#define DEF_EDITOR "emacs" X#define DEF_FOLDER "~/Mail" /* default Mail folder */ X#define DEF_MBOX "~/mbox" /* default mbox */ X#define DEF_INDENT_STR "> " /* indent included mail */ X#define DEF_PRINTER "lp" X#define DEF_ESCAPE "~" X#define DEF_HDR_FMT "%25f %7d (%l/%c) \"%s\"" /* default hdr_format */ X#define DEF_CURSES_HELP \ X "display save mail reply next-msg back-msg screen-next screen-back" ________This_Is_The_END________ if test `wc -l < config.h` -ne 140; then echo 'shar: config.h was damaged during transit (should have been 140 bytes)' fi fi ; : end of overwriting check echo 'x - Makefile' if test -f Makefile; then echo 'shar: not overwriting Makefile'; else sed 's/^X//' << '________This_Is_The_END________' > Makefile X# Mush makefile for A/UX. X# XHDRS1= mush.h config.h XHDRS2= strings.h options.h XHDRS3= bindings.h glob.h XHDRS4= version.h XSRCS1= commands.c dates.c execute.c expr.c folders.c \ X hdrs.c init.c loop.c mail.c main.c misc.c msgs.c pick.c \ X print.c setopts.c signals.c sort.c viewopts.c options.c lock.c XSRCS2= bind.c curs_io.c curses.c file.c strings.c macros.c \ X addrs.c malloc.c glob.c X XOBJS1= commands.o dates.o execute.o expr.o folders.o \ X hdrs.o init.o loop.o mail.o main.o misc.o msgs.o pick.o \ X print.o setopts.o signals.o sort.o viewopts.o options.o lock.o XOBJS2= bind.o curs_io.o curses.o file.o strings.o macros.o \ X addrs.o malloc.o glob.o X XHELP_FILES= README README-7.0 README-7.1 mush.1 cmd_help \ X Mushrc Mailrc Gnurc sample.mushrc advanced.mushrc digestify X X XAUXFLAGS= -DSELECT -DDIRECTORY -DAUX XCFLAGS= -O -DSYSV -DUSG -DCURSES -Dvfork=fork -DSIGRET=void -DREGCMP $(AUXFLAGS) XLDFLAGS= XLIBS= -lcurses -lPW XOTHERLIBS= X# Use some variant of this one if you #define MMDF in config.h X#OTHERLIBS=/usr/src/mmdf/lib/libmmdf.a XPROG= mush X X$(PROG): $(OBJS1) $(OBJS2) X @echo loading... X @$(CC) $(LDFLAGS) $(OBJS1) $(OBJS2) -o $(PROG) $(LIBS) $(OTHERLIBS) X X$(OBJS1): $(HDRS1) $(HDRS2) X$(OBJS2): $(HDRS1) $(HDRS2) $(HDRS3) Xloop.o: version.h X XBINDIR= /usr/local/bin XLIBDIR= /usr/local/lib XMRCDIR= /usr/lib XMANDIR= /usr/local/man/man1 XMANEXT= 1 X Xinstall: mush X cp mush $(BINDIR) X strip $(BINDIR)/mush X chmod 0755 $(BINDIR)/mush X cp mush.1 $(MANDIR)/mush.$(MANEXT) X chmod 0644 $(MANDIR)/mush.$(MANEXT) X cp cmd_help $(LIBDIR) X chmod 0644 $(LIBDIR)/cmd_help X cp Mushrc $(MRCDIR)/Mushrc X chmod 0644 $(MRCDIR)/Mushrc ________This_Is_The_END________ if test `wc -l < Makefile` -ne 55; then echo 'shar: Makefile was damaged during transit (should have been 55 bytes)' fi fi ; : end of overwriting check exit 0
akkana@Apple.COM (Akkana Peck) (05/30/91)
>In <numb.675098076@el_greco> numb@cs.qmw.ac.uk (Matt Newman) writes: >>I'm getting more and more fed up of trying to bring software from usenet >>up on our A/UX machines. liam@cs.qmw.ac.uk (William Roberts;) writes: >I think he's complaining about "mush" amongst other things. We don't run our Actually, I've found A/UX to be one of the easier targets for porting public domain software (including mush, which ported with very little effort). Basically, I've found that adding a set42sig() call at the beginning of main() will allow most programs to work with -DBSD. The only exceptions I've found so far are heavily tty-driver-dependant programs like bash and jove (anyone have a jove A/UX port?). I'm biased, since I *am* currently working for Apple in the A/UX group; but as a contractor who has worked with a number of other systems, I was quite pleasantly surprised at the ease of porting outside applications to A/UX. ...Akkana (akkana@apple.com) Contracting at, but not speaking for, Apple
urlichs@smurf.sub.org (Matthias Urlichs) (06/12/91)
In comp.unix.aux, article <9105251839.AA09210@melmac.umd.edu>,
steveg@melmac.umd.edu (Steve Green) writes:
<
< Many other UNIX platforms suffer from the same problem that AUX does.. its
< not vanilla this or vanilla that. Things are no different for many of the
< other SysV based machines with BSD extensions. (I have had many of the same
< problems with IRIX and Unicos that I originally had with AUX)
<
Wrong -- most other "mixed-environment" systems are worse because they
provide different "universes" for the SVID/BSD/POSIX compatibility stuff,
in some cases even using different compilers (with different bugs :-( ).
< The problem as I see it is that too many assumptions
< are made if you #define SYSV. Programs that have #ifdefs based on system
< calls, include files, libraries, etc.. usually port without any trouble to
< AUX. (Larry Wall's stuff is great)
<
Just look into Perl's Configure stuff for a hint at how many _really_ ugly
Unixes are out there. Compared to these, A/UX is OK. Really.
--
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49-721-621127(0700-2330) \o)/