carllp@diku.dk (Carl-Lykke Pedersen) (05/03/91)
We are considering switching partly over to HPUX. Until now we have
managed to stay in the BSD/SunOS-world, but we may be forced to
reconsider our objections to the sysV-world.
I like many things about HPUX. It has some of the best facilities from
BSD, and its not that hard to make a HPUX feel *almost* like a
BSD-system. But why, Oh why, doesn't HPUX go more of the way?
I would be much happier with HPUX if
- chmod had an -R option
- man used the PAGER and MANPATH environment-variable
- diff could make context-diffs!
- I could include <strings.h> as well as <string.h>
- checklist was called fstab
- ls -g showed the group
- sam could use fully qualified domainnames
- libBSD included some more functions (Why can't they be in libc?)
- /usr/include/arpa contained some more files
- quota existed on HPUX-filesystems
- remsh was called rsh
- SIGWINDOW was called SIGWINCH (and some program used it)
-
- ...
Most of these are just minor annoyances, but when they come in these
great numbers, they become a nuisance. I have bumped into all of the
above misfeatures without really digging into HPUX, so I'm concerned
with what I am going to discover if we convert to HPUX.
Are HPUX going to be better? Is HPUX 8.0? Will OSF/1 be?
Worse than nearly all the above is the different versions of HPUX for
the 300- and the 800-series. The "One disk -- One partion (Section?)"
for the 300-series are terrible. Will this ever change?
BTW: Is it possible to get a bug-list of known bugs in HPUX? I know
Sun provides such a list, but then again, they need to do it with
that code :-)
BTNW: Is it possible to get sources to HPUX, and if so, will I get
them in my lifetime?
Regards
Carl-Lykke
PS: Thanks to all the HP-folks who helps us in this newsgroup, and to
those people who have ported usefull software (like emacs, top,
tcsh, perl ...) to HPUX.Kimmo.Suominen@lut.fi (Kimmo Suominen) (05/03/91)
>>>>> On 2 May 91 20:27:10 GMT, carllp@diku.dk (Carl-Lykke Pedersen) said:
Carl-Lykke> I would be much happier with HPUX if
[... stuff deleted ...]
Well, many of these things you'd like are BSD specific. I like the
idea of having a System V environment. Of course HP could provide
another set of commands with the BSD style, like for instance SunOS
has /usr/5bin and Dell's System V Release 4 has separate /sbin and
/usr/ucb. But then, is there really a need?
I have been using HP-UX for about 3-4 years now, and I have been more
than comfourtable with it. Of course the fact that it is the first
Unix I got to use may bias my opininions.
I have used SunOS quite a lot, too (about 2-3 years). I use a couple
of the 5bin utilities to make myself at home. Basically I can find
everything I need on both HP-UX and SunOS.
I have also gained some experience on HP Apollo's Domain base SysV
environment. On release 9.7 it was plain terrible. I didn't know
SysV could be so unfriendly. I really had got too used on HP-UX's
adaptions from the BSD world. But then, I didn't like to switch over
to the BSD 4.2 environment either. Now that SR10.2 is running on our
Apollos I'm getting along much better. DomainOS has some really nice
things in it, like environment variables in symbolic links. That
would be something to have in BSD and HP-UX too.
Finally I might write a couple of words on IBM's AIX. It has quite
many BSD features in it, too. Somehow it still doesn't work really
painlessly for me. For instance completion in C-shell is a mess, and
some important things like cron and printer spooler have been combined
in the most weird way (you use "print" instead of all the three
commands lp, at and batch). They are all queues, you see... ;-)
Of course I have made HP-UX really my home by compiling PD software to
implement the things I seemed to miss on HP-UX. Many of these things
were missing on SunOS (and others) also, like Perl, Elm (now HP has
it, but it is not the same), GNU Emacs, diff, C-News, nn, irc less and
many others. Supporting these tools on both HP-UX and SunOS is after
all really easy. Of course, sometimes you run into code that simply
won't run on BSD, but the HP-UX is System V. On the other hand, the
easiest "port" I've ever made was telling the software, that it was
being installed on a BSD 4.2 platform ;-)
That's my two pennies worth. Regards
--
Kim / Internet: Kimmo.Suominen@lut.fi
"That's what I think." / Bitnet: KIM@FINFILESsystem@alchemy.chem.utoronto.ca (System Admin (Mike Peterson)) (05/03/91)
We too are considering switching to a 720/730, coming from the Apollo
BSD environment. I have been using a 720 for the past few days, and
these items are of concern. Any pointers/responses appreciated.
Major problems with f77 compiler using -O:
I found 2 routines which give incorrect numerical results with
-O (but no compiler complaints). This is not good news, although I
understand from other sources (Apollo users meeting last week and the HP
product intro a month ago) that the compiler actually running on the 7x0
is not the greatest (i.e. benchmarks were actually compiled on other HP
systems and then run on the 720/730).
Other problems in no particular order:
- no 'renice' command.
- BSD f77 libraries missing, though the f77 man page implies that these
libraries are provided (they are not in /usr/lib, and there are no
man pages, so I assume these will not be provided). This is a royal
pain since "etime", "dtime", "itime", "getenv", "system", "lnblnk"
and "rindex" (to name a few popular f77 routines) are not available,
nor do there seem to be any replacements.
- my script which runs all my test jobs sequentially just died in the middle
with "Missing name for redirect", yet rerunning it worked fine
(looks like a flaky 'csh' to me).
- unit 7 output is mixed with unit 6 output in f77; unit 7 can be
opened as a real file (which works properly) but can't be opened
as a scratch file. It appears that units 5, 6 and 7 are mapped to
stdin, stdout and stderr, and can't be reopened under some
circumstances.
- vi doesn't redraw the screen properly in rlogin sessions from
xterms (xterm is not recognized as a valid terminal type,
so I was using vt100 on the 720). Working from a real vt100 does
work properly, so it might be just a matter of supplying a terminfo
file for an xterm.
- core dumps hang the shell ('csh') producing the dump for 1-2 minutes.
- rlogin does not handle flow control properly (an issue for rlogins
from a terminal server where you can have multiple sessions).
- default stty settings are retarded (most default 'csh' keys are not set!).
Easily fixed in the login files, but shouldn't be needed. "Features"
like this are worrisome in that if basic things like this are screwed
up, who knows what else is.
- no BSD printing!
Already mentioned in this group:
- limited user licenses (we regulary have more than 16 users logged in
to our central mail/compute server); I didn't know anyone sold such
restricted UNIXs these days.
Mike.
--
Mike Peterson, System Administrator, U/Toronto Department of Chemistry
E-mail: system@alchemy.chem.utoronto.ca
Tel: (416) 978-7094 Fax: (416) 978-8775rdm@cernapo (Alphonse Rademakers) (05/03/91)
I am a new (Snake) HP-UX user, coming from Domain_Os (BSD version). I must
admit that I was pleasantly surprised that on first sight HP-UX looked
a lot like BSD. So to comfort Carl-Lykke a bit I'll check his list...
>>>>> On 2 May 91 20:27:10 GMT, carllp@diku.dk (Carl-Lykke Pedersen) said:
Carl-Lykke> I would be much happier with HPUX if
Carl-Lykke> - chmod had an -R option
is has
Carl-Lykke> - man used the PAGER and MANPATH environment-variable
it uses both of them
Carl-Lykke> - diff could make context-diffs!
it can
Carl-Lykke> - I could include <strings.h> as well as <string.h>
are both included
Carl-Lykke> - checklist was called fstab
not yet
Carl-Lykke> - ls -g showed the group
it does
Carl-Lykke> - sam could use fully qualified domainnames
I don't know
Carl-Lykke> - libBSD included some more functions (Why can't they be in libc?)
Carl-Lykke> - /usr/include/arpa contained some more files
Carl-Lykke> - quota existed on HPUX-filesystems
it exists
Carl-Lykke> - remsh was called rsh
it is
Carl-Lykke> - SIGWINDOW was called SIGWINCH (and some program used it)
it is not
Carl-Lykke> -
Carl-Lykke> Are HPUX going to be better? Is HPUX 8.0? Will OSF/1 be?
HP-UX 8.0 is definitely better.
Cheers, Fons Rademakers.
--
Org: CERN, European Organization for Nuclear Research.
Mail: 1123 Geneve, Switzerland Fax: +22 7677155
Phone: +22 7674886 or 7675049
UUCP: rdm@cernapo.cern.ch BITNET: rdm@cernvm.bitnetpaul@prcrs.prc.com (Paul Hite) (05/04/91)
In article <1991May2.202710.5152@odin.diku.dk>, carllp@diku.dk (Carl-Lykke Pedersen) writes: > We are considering switching partly over to HPUX. Until now we have > managed to stay in the BSD/SunOS-world, but we may be forced to > reconsider our objections to the sysV-world. Isn't SunOS basicly SysV.4 these days? Anyway, I can help with some of your complaints. I have re-ordered them. > I would be much happier with HPUX if > - chmod had an -R option > - quota existed on HPUX-filesystems > - /usr/include/arpa contained some more files This stuff is weeks away in HP-UX 8.0. > - I could include <strings.h> as well as <string.h> > - checklist was called fstab > - remsh was called rsh So "rm rsh" and create a few links. I do agree that the System V rsh should be purged from our existence. It provides no real protection. > - man used the PAGER and MANPATH environment-variable man only uses its built-in pager if stdout is a tty. man cat | pg works. I use an alias: alias man 'man \!* |ssp|pg' > BTW: Is it possible to get a bug-list of known bugs in HPUX? I know > Sun provides such a list, but then again, they need to do it with > that code :-) Well, HP does publish a SSB (Software Status Bulletin). It's hard to read. If you buy HP's LaserROM product, you can have it on-line, which is much better. > BTNW: Is it possible to get sources to HPUX, and if so, will I get > them in my lifetime? Well, if you have an AT&T System V.3 source license, it can be done. We paid $25,000 (I think) and got them. The source for each product is priced separately. So you might want LANLINK, ARPA, and NFS as well. HP will not release the source for their C compiler under any circumstances. (Or so we were told.) Instead of simply looking at software, may I suggest that you include hardware in your evaluation? We didn't switch from another vendor to HP because we wanted HP-UX over some other port of unix. Paul Hite PRC Realty Systems McLean,Va paul@prcrs.prc.com (703) 556-2243 You can't tell which way the train went by studying its tracks.
Steinar.Haug@delab.sintef.no (Steinar Haug) (05/04/91)
We're running 7.03 on 400t and 400s machines here... What follows is some general comments & questions from one who is a rather experienced SunOS system administrator, but new to HP-UX. > I would be much happier with HPUX if > - chmod had an -R option I miss that one a lot, yes. Also wish HP would adopt the 'chown owner.group' syntax that SunOS has. > - sam could use fully qualified domainnames sam's behavior today in the presence of DNS is rather weird. I like to allocate names and IP addresses for diskless machines *before* I bring them up. What happens when using sam is the following: - I enter the 'add cluster clients' screen and type the name of the new client, say 'xyzzy'. sam obligingly looks up 'xyzzy.er.sintef.no' in DNS and inserts the IP address when I press TAB. Then I press TAB again to move to the Ethernet address field, and *then* sam complains that the IP address it just looked up is already in use by the client called 'xyzzy.er.sintef.no'. I *really really* wish I could tell sam 'yes, exactly!'. As it is, I have to either turn off the use of DNS on the HP server *or* remove xyzzy from DNS before I can add it as a diskless client. Pain in the a**... Other minor annoyances: We use ctrl-U to kill line and DEL to delete a char here. This is different from HP's default, but easy to switch. *Except* for the login program. Is there any way to convince login to use ctrl-U/DEL in place of @ and #? I absolutely detest @/# myself and it's very confusing to our users also (they're all used to SunOS :-) 68040 question: We have received a number of 25 MHz 68040 upgrades for our 400t's.Can anybody tell me if this upgrade is worth the work (upgrade to 7.05 on servers). I would expect better floating point performance, but does a 25 MHz 68040 really have any better integer performance than a 50 MHz 68030? Will 'gnus' run any faster? :-) Backup question: We perform backup via the net, using 'dump' from the HP machines to Exabytes connected to Suns. When performing a level 0 dump, we want to exclude all users. On our Suns, we can create /etc/nologin with a suitable message, and users will not be allowed to login. How can we do this on our HPs? Remember we want to keep them our from both the HP servers and the diskless clients. Is there a suitable inittab entry which will exclude users but allow rsh commands from the Sun machines with the Exabyte? Steinar Haug, system/networks administrator SINTEF DELAB, University of Trondheim, NORWAY Email: Steinar.Haug@delab.sintef.no, sthaug@idt.unit.no, steinar@tosca.er.sintef.no
milburn@me10.lbl.gov (John Milburn) (05/05/91)
In his article Mike Peterson writes: >We too are considering switching to a 720/730, coming from the Apollo >BSD environment. I have been using a 720 for the past few days, and >these items are of concern. Any pointers/responses appreciated. I can help some on a couple of these. I've deleted the questions I will not comment on. >Major problems with f77 compiler using -O: >I found 2 routines which give incorrect numerical results with >-O (but no compiler complaints). This is not good news, although I Please post code fragments so that the hp folks can look into it. >Other problems in no particular order: >- no 'renice' command. Yes. Appended to this message is the source to a program called 'setnice' which was posted here last year. You might have to make some minor definition changes for the s700. The header of that message is also attached. >- my script which runs all my test jobs sequentially just died in the middle > with "Missing name for redirect", yet rerunning it worked fine > (looks like a flaky 'csh' to me). Bad variable definition? Please send the script with the problem. I have never seen this on s300. >- vi doesn't redraw the screen properly in rlogin sessions from > xterms (xterm is not recognized as a valid terminal type, > so I was using vt100 on the 720). Working from a real vt100 does > work properly, so it might be just a matter of supplying a terminfo > file for an xterm. Perhaps you didn't install the fileset with all the terminfo definitions. If not, creating a custom description is simple. Just use tic(1M). Here is my xterm def. I think it is unmodified from the one hp supplies. You can rename it, changing the lines and columns definitions, to get a variety of definitions. (Or, just use resize to change the environment variables.) xterm|vs100|xterm terminal emulator, am, xenl, km, cols#80, it#8, lines#65, bel=^G, cr=\r, csr=\E[%i%p1%d;%p2%dr, tbc=\E[3g, clear=\E[H\E[2J, el=\E[K, ed=\E[J, cup=\E[%i%p1%d;%p2%dH, cud1=\n, home=\E[H, cub1=\b, cuf1=\E[C, cuu1=\E[A, dch1=\E[P, dl1=\E[M, blink=@, bold=\E[1m, rev=\E[7m, smso=\E[7m, sgr0=\E[m, rmso=\E[m, ich1=\E[@, il1=\E[L, kbs=\b, kcud1=\EOB, kf2=\EOQ, kf3=\EOR, kf4=\EOS, kcub1=\EOD, kcuf1=\EOC, kcuu1=\EOA, rmkx=\E[?1l\E>, smkx=\E[?1h\E=, dch=\E[%p1%dP, dl=\E[%p1%dM, cud=\E[%p1%dB, ich=\E[%p1%d@, il=\E[%p1%dL, cub=\E[%p1%dD, cuf=\E[%p1%dC, cuu=\E[%p1%dA, rs1=\E>\E[1;3;4;5;6l\E[?7h\E[m\E[r\E[2J\E[H, rs2=@kf1=\EOP, rc=\E8, sc=\E7, ind=\n, ri=\EM, sgr=\E[%?%p1%t;7%;%?%p2%t;4%;%?%p3%t;7%;%?%p4%t;5%;%?%p6%t;1%;m, hts=\EH, ht=\t, >- rlogin does not handle flow control properly (an issue for rlogins > from a terminal server where you can have multiple sessions). Please describe this problem in more detail. >- no BSD printing! Sure there is. HP just tries to make it work in their own environment. You can easily print to a remote printer by creating a remote device using lpadmin. For instance, to create an entry to allow printing to an imagen served by dp3.lbl.gov, I issue the following: /usr/lib/lpadmin -pip11 -mrmodel -v/dev/null -orc -ocmrcmodel -osmrsmodel \ -ormdp4 -orpip11 -ob3 The /usr/bin/lpr script hp provides is completely brain damaged, so we wrote our own. Also, the supplied model script is incomplete, and has been modified. None of this takes much work. Setting up a local server can also be done using rlpdaemon. Basically, the mechanism has been changed, but the functionality is there. >- limited user licenses (we regulary have more than 16 users logged in > to our central mail/compute server); I didn't know anyone sold such > restricted UNIXs these days. Agreed. This can be a real pain in the ass. Hope some of this helps, -jem The setnice stuff: ---------------------------- #From: mck@hpcuhc.HP.COM (Doug McKenzie) Newsgroups: comp.sys.hp Subject: Re: Any "renice" type function for HP-UX Date: 18 Apr 90 17:31:56 GMT Organization: Hewlett Packard, Cupertino >A bit of warning: the posted version seems to be specific to the series 800 >machines. Doug, maybe you want to post the series 300 version also? Yes, I sure would, I've gotten some email asking for it. I don't have a S300 version of renice, but I have another S800 source ("setnice.c") that does essentially the same thing as renice, and seemed easier to modify for the S300. (The reason the S300 and S800 versions are different, is that they access /dev/kmem, which has machine (and release) dependent idiosyncracies.) Anyway here is setnice.c. No makefile, no Series [38]00 dependencies, just cc setnice.c -o setnice and "chmod 4755 setnice" (as root). Standard warning: this isn't an official HP posting. Global warning: Beware of the "open house" effect (i.e. setuid programs). Doug McKenzie HP-UX Support mck@hpcugsya.hp.com ---------------------------- /* setnice nice -pid: set nice value of a process that is running */ #include <sys/types.h> #include <sys/param.h> #include <sys/time.h> #include <sys/resource.h> #include <sys/proc.h> #include <nlist.h> #include <stdio.h> #include <fcntl.h> int kmem, nproc; /* kmem descriptor, size of proc table */ struct proc *proc; /* pointer to proc structure */ struct nlist nl[] = { /* name list entry */ #ifdef hp9000s300 { "_proc" } , { "_nproc"} , #else hp9000s800 { "proc" } , { "nproc" } , #endif { NULL } }; main( argc,argv ) int argc; char **argv; { struct proc proc_entry; register int i, pid; char nice; if (argc != 3 || argv[2][0] != '-'){ fprintf (stderr, "usage: %s nice_value -pid\n", argv[0]); exit (1); } nice = atoi (argv[1]); if (nice < 0 || nice > 40){ fprintf (stderr, "nice_value must be between 0 and 40\n"); exit (1); } argv[2]++; pid = atoi(argv[2]); init_stuff(); readkmem (nl[1].n_value, &nproc, sizeof(nproc)); readkmem (nl[0].n_value, &proc, sizeof (proc)); for ( i=0; i < nproc; i++ ) { readkmem( &proc[i], (char *) &proc_entry, sizeof(proc_entry)); if (proc_entry.p_stat != 0 && proc_entry.p_pid == pid){ writekmem (&proc[i].p_nice, &nice, sizeof (nice)); break; } } if (i == nproc){ fprintf (stderr, "%d: No such process\n", pid); exit (1); } } init_stuff() { if (( kmem = open ("/dev/kmem",O_RDWR)) == -1 ) { perror ("couldn't open /dev/kmem"); exit (-1); } if ( nlist ("/hp-ux",nl) == -1 ) { perror("nlist"); exit (-1); } if ( nl[0].n_type == 0 ) { fprintf( stderr,"nlist[0] failed\n"); exit (-1); } if ( nl[1].n_type == 0 ) { fprintf( stderr,"nlist[1] failed\n"); exit (-1); } } readkmem (offset, buf, size ) long offset; char *buf; int size; { if ( lseek (kmem, offset, 0) == -1 ) { perror ( "lseek" ); exit (-1); } if ( read( kmem,buf,size) != size ) { perror ("can't read from kmem\n"); exit( -1 ); } } writekmem (offset, buf, size) long offset; char *buf; int size; { if (lseek (kmem, offset, 0) == -1){ perror ("lseek"); exit (1); } if (write (kmem, buf, size) != size){ perror ("can't write to kmem\n"); exit (1); } } ----------------Cut Here--------------- -- John Milburn milburn@me10.lbl.gov (415) 486-6969 "Work FOR? I don't work FOR anybody... I'm just having fun." - The Doctor
mike@hpfcso.FC.HP.COM (Mike McNelly) (05/08/91)
Only commenting on the things I can check easily or that I have some knowledge about: > ... > > I like many things about HPUX. It has some of the best facilities from > BSD, and its not that hard to make a HPUX feel *almost* like a > BSD-system. But why, Oh why, doesn't HPUX go more of the way? > > I would be much happier with HPUX if > - chmod had an -R option The 8.0 manpage shows a -R option now. Lots of these types of commands have a recursive option as of this release. > - man used the PAGER and MANPATH environment-variable The 8.0 manpage shows that both of these environment variables are supported. S300/400 had it as of release 7.4 at least but I don't think it was documented. > - diff could make context-diffs! The 8.0 manpage shows that diff -c (context diff) is now supported. > - I could include <strings.h> as well as <string.h> > - checklist was called fstab > - ls -g showed the group On both S700/S800 release 8.0 it does. It also does on S300/S400 release 7.4. I haven't tried it on earlier systems. > - sam could use fully qualified domainnames > - libBSD included some more functions (Why can't they be in libc?) An ongoing problem. In some cases BSD semantics conflict with SYSV, particularly with signals. > - /usr/include/arpa contained some more files > - quota existed on HPUX-filesystems > - remsh was called rsh The name rsh was already used for "restricted shell" by ATT, I believe. > - SIGWINDOW was called SIGWINCH (and some program used it) > - > - ... > > Most of these are just minor annoyances, but when they come in these > great numbers, they become a nuisance. I have bumped into all of the > above misfeatures without really digging into HPUX, so I'm concerned > with what I am going to discover if we convert to HPUX. > > Are HPUX going to be better? Is HPUX 8.0? Will OSF/1 be? We hope so. I like it now (but I'm not impartial). > > Worse than nearly all the above is the different versions of HPUX for > the 300- and the 800-series. The "One disk -- One partion (Section?)" > for the 300-series are terrible. Will this ever change? > > BTW: Is it possible to get a bug-list of known bugs in HPUX? I know > Sun provides such a list, but then again, they need to do it with > that code :-) Ask your sales rep for a Software Status Bulletin. It's published quarterly, I believe. Gory details are shown there. It's a pamphlet so the cost shouldn't be much. > > BTNW: Is it possible to get sources to HPUX, and if so, will I get > them in my lifetime? Yes, but a source license is more expensive than a binary license. > > Regards > Carl-Lykke > > PS: Thanks to all the HP-folks who helps us in this newsgroup, and to > those people who have ported usefull software (like emacs, top, > tcsh, perl ...) to HPUX. Mike McNelly mike@fc.hp.com (An employee, but not a spokesperson for HP)
jenings@hpfcbig.SDE.HP.COM (Byron Jenings) (05/08/91)
Carl-Lykke Pedersen <carllp@diku.dk> writes: |Worse than nearly all the above is the different versions of HPUX for |the 300- and the 800-series. The "One disk -- One partion (Section?)" |for the 300-series are terrible. Will this ever change? I'm curious, why do you want partitions? I don't have anything to do with such decisions here, but I've personally always been glad that the s300 didn't support them. Is there some application for them that I haven't encountered yet?
rodean@hpfcdc.HP.COM (Bruce Rodean) (05/08/91)
In article <1991May2.202710.5152@odin.diku.dk> carllp@diku.dk (Carl-Lykke Pedersen) writes: > I like many things about HPUX. It has some of the best facilities from > BSD, and its not that hard to make a HPUX feel *almost* like a > BSD-system. But why, Oh why, doesn't HPUX go more of the way? I have rearranged some of Carl-Lykke's comments so that I can group them better. > I would be much happier with HPUX if > - chmod had an -R option > - man used the PAGER and MANPATH environment-variable > - I could include <strings.h> as well as <string.h> > - quota existed on HPUX-filesystems All these are coming out in 8.0. > - ls -g showed the group This was in 7.0. > - libBSD included some more functions (Why can't they be in libc?) A lot of stuff from libBSD.a was moved into libc.a for 8.0. Plus some new ones as well. Among them were: bcmp, bcopy, bzero, ffs, getusershell, index, mkstemp, rindex, strcasecmp, and strncasecmp. > - diff could make context-diffs! Sorry I don't know about this. > - checklist was called fstab I think checklist is mandated by Sys V. > - remsh was called rsh The name rsh is used to denote the restricted Bourne shell. > - sam could use fully qualified domainnames > - /usr/include/arpa contained some more files > - SIGWINDOW was called SIGWINCH (and some program used it) Can't help you here. These are out of my area. Sorry. Bruce Rodean rodean@hpfclg.fc.hp.com
dlj@hpfcdc.HP.COM (David Jobusch) (05/08/91)
>I have rearranged some of Carl-Lykke's comments so that I can >group them better. > And I'll try and answer the ones Bruce didn't... > >> - diff could make context-diffs! > Looking at the 8.0 man page, diff has lots of new goodies, including context diff (diff -c, -Cn). >> - sam could use fully qualified domainnames Fixed in 8.0. >> - SIGWINDOW was called SIGWINCH (and some program used it) Not in 8.0. :-( Under, umm, discussion internally. What other pieces/features (beyond naming conflicts) would comp.sys.hp readers be interested in seeing added to HP-UX that are currently in your favorite UN*X? It is almost investigation time in my group... Please send email if you have constructive suggestions. Try to tell me _why_ you'd like to have those features, too. ___ / / Dave Jobusch HEWLETT/hp/PACKARD Open Systems Software Division /__/ UDL Workstation Kernel Fort Collins, CO dlj@hpfcls.fc.hp.com
cedman@golem.ps.uci.edu (Carl Edman) (05/09/91)
In article <5570626@hpfcdc.HP.COM> rodean@hpfcdc.HP.COM (Bruce Rodean) writes: In article <1991May2.202710.5152@odin.diku.dk> carllp@diku.dk (Carl-Lykke Pedersen) writes: A lot of stuff from libBSD.a was moved into libc.a for 8.0. Plus some new ones as well. Among them were: bcmp, bcopy, bzero, ffs, getusershell, index, mkstemp, rindex, strcasecmp, and strncasecmp. What about getdtablesize ? A tiny little routine in libc.a using sysconf could save quite a few people quite a lot of trouble. (And it never even was in the standard libBSD.a) Carl Edman -- "We hold that what one man cannot morally do, a million men cannot morally do, and government, representing many millions of men, cannot do." -- Auberon Herbert Send mail to Carl Edman <cedman@golem.ps.uci.edu>
christos@theory.tn.cornell.edu (Christos S. Zoulas) (05/09/91)
In article <7540068@hpfcbig.SDE.HP.COM> jenings@hpfcbig.SDE.HP.COM (Byron Jenings) writes: > >I'm curious, why do you want partitions? I don't have anything to do >with such decisions here, but I've personally always been glad that >the s300 didn't support them. Is there some application for them that >I haven't encountered yet? 1. Fsck takes forever on large disks. 2. Any user can fill up the whole disk. It is nice to be able have a small partition for / so that it is checked fast in case you need to reboot many times. When I was installing amd, I needed to reboot several times cause I would get stuck and the mean time between reboots was 40 minutes! Having a separate /tmp (/var) partition, stops user programs from filling /. My guess is that the search algorithms on fsck are either n**2 or n log n, (where n is the size of the disk) so it pays off having small partitions and running fsck -p. christos -- Christos Zoulas | 389 Theory Center, Electrical Engineering, christos@ee.cornell.edu | Cornell University, Ithaca NY 14853. christos@crnlee.bitnet | Phone: (607) 255 0302, Fax: (607) 255 9072
wehr@fmsrl7.UUCP (Bruce Wehr ) (05/10/91)
jenings@hpfcbig.SDE.HP.COM (Byron Jenings) writes: > > I'm curious, why do you want partitions? When I first started running news several years ago, it was on a 9000/350 with just one disk. I was still getting used to administering news (and realizing how much space it could take) and I was constantly being greeted with "write failed: / file system full" messages in the morning on particularly heavy days. If I could have created a separate partition for /usr/spool/news, news may have crashed, but the rest of the system would have been OK. -- Bruce Wehr (wehr%dptc.decnet@srlvx0.srl.ford.com) (..!uunet!srlvx0.srl.ford.com!wehr%dptc.decnet) Ford Motor Company - Engineering Technology Services P.O. Box 2053, Room 1153, Dearborn, Michigan 48121-2053 (313)337-5304
tml@tik.vtt.fi (Tor Lillqvist) (05/10/91)
A lot of stuff from libBSD.a was moved into libc.a for 8.0. Plus some
new ones as well. Among them were: bcmp, bcopy, bzero, ffs,
getusershell, index, mkstemp, rindex, strcasecmp, and strncasecmp.
I don't know if this is entirely good news... Doesn't this mean that
now also on HP-UX you can get away with sloppy programming style
(using the b* and index functions even if ANSI C and POSIX mandate
mem* and strchr)?
--
Tor Lillqvist,
working, but not speaking, for the Technical Research Centre of Finlandjason@hpcndjdz.CND.HP.COM (Jason Zions) (05/13/91)
68040 question: We have received a number of 25 MHz 68040 upgrades for our 400t's.Can anybody tell me if this upgrade is worth the work (upgrade to 7.05 on servers). I would expect better floating point performance, but does a 25 MHz 68040 really have any better integer performance than a 50 MHz 68030? Will 'gnus' run any faster? :-) The 040 upgrade feels faster even on non-floating stuff, but that may be just my imagination; I personally have no benchmarks other than that I dont wait for compiles as long as I used to. Rolling to 7.05 buys some other advantages, though; the limit on the NBUFS kernel parameter (768) was removed, meaning your servers with lots of memory can now use more than 3 meg of it for file buffer cache. -- This is not an official statement of The Hewlett-Packard Company. No warranty is expressed or implied. The information included herein is not to be construed as a committment on HP's part. The devil made me do it. This won't save me from the lawyers' wrath, but it can't hurt. Jason Zions The Hewlett-Packard Company Colorado Networks Division 3404 E. Harmony Road Mail Stop 102 Ft. Collins, CO 80525 USA jason@cnd.hp.com (303) 229-3800
rml@hpfcdc.HP.COM (Bob Lenk) (05/15/91)
> - diff could make context-diffs!
As several folks have replied, this is in 8.0. For those with older
releases, try /usr/lib/rdiff (the RCS diff command).
Bob Lenk
rml@fc.hp.com
{uunet,hplabs}!fc.hp.com!rmlrer@hpfcdc.HP.COM (Rob Robason) (05/15/91)
steinar> Other minor annoyances: We use ctrl-U to kill line and DEL to steinar> delete a char here. This is different from HP's default, but steinar> easy to switch. *Except* for the login program. Is there any steinar> way to convince login to use ctrl-U/DEL in place of @ and #? steinar> I absolutely detest @/# myself and it's very confusing to our steinar> users also (they're all used to SunOS :-) Check out gettydefs(4) in the HP-UX reference. It explains how to use /etc/gettydefs to make the changes you need. Rob
randyc@hpfcdc.HP.COM (Randy Campbell) (05/16/91)
>I would be much happier with HPUX if > - chmod had an -R option > - man used the PAGER and MANPATH environment-variable > - diff could make context-diffs! These three requests are in HP-UX 8.0. The remaining items are outside my area. Randy Campbell, UDL/Commands, Fort Collins
decot@hpcupt1.cup.hp.com (Dave Decot) (05/16/91)
> A lot of stuff from libBSD.a was moved into libc.a for 8.0. Plus some > new ones as well. Among them were: bcmp, bcopy, bzero, ffs, > getusershell, index, mkstemp, rindex, strcasecmp, and strncasecmp. > > I don't know if this is entirely good news... Doesn't this mean that > now also on HP-UX you can get away with sloppy programming style > (using the b* and index functions even if ANSI C and POSIX mandate > mem* and strchr)? People intent on "sloppy programming style" will succeed regardless of what is provided where. Anyway, use of BSD functions doesn't imply "sloppy programming style", just "BSD programming style". We're trying to minimize the pain required for importing BSD and Sun applications. The only things we want to force -lBSD for is when conflicting functions are used, such as setpgrp() and signal(). In 8.0, lint(1) can be used with the -Aa, -D_POSIX_SOURCE, and -D_XOPEN_SOURCE options to detect calls to functions that aren't in the corresponding standards. Dave Decot DISCLAIMER: My opinions only, not HP's.
jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) (05/19/91)
In an article decot@hpcupt1.cup.hp.com (Dave Decot) wrote: >Anyway, use of BSD functions doesn't imply "sloppy programming style", >just "BSD programming style". We're trying to minimize the pain required >for importing BSD and Sun applications. The only things we want to force >-lBSD for is when conflicting functions are used, such as setpgrp() and >signal(). I don't understand. I just wasted many tens of hours trying to port a large package (the PP X.400 system) to HP/UX, which broke signal() because I was trying to use -lBSD in order to get the b*() functions. I finally had to take out -lBSD and use macros for the b* stuff. Admittedly the package was not totally BSD-ish, in that it had a compile option for SYS5, which only addressed part of the BSD-SYS5 issues. Why would you want to force -lBSD when it breaks SYS5 code? -- John Dudeck "You can only push jdudeck@Polyslo.CalPoly.Edu simplicity so far." ESL: 62013975 Tel: 805-545-9549 -- AT&T promotional brochure
s900387@minyos.xx.rmit.oz.au (Craig Macbride) (05/20/91)
jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) writes: >I don't understand. I just wasted many tens of hours trying to port a >large package (the PP X.400 system) to HP/UX, which broke signal() >because I was trying to use -lBSD in order to get the b*() functions. Join the club. I love the way the on-line docs say how signal() works and how the BSD sigset() (etc) commands work, and then HP slips a BSD signal() into the same library as bzero(), etc, so that you can't use these routines without breaking (or rewriting) all your signal-handling. >I finally had to take out -lBSD and use macros for the b* stuff. Ditto. >Why would you want to force -lBSD when it breaks SYS5 code? You wouldn't. If HP had had any brains, they would have kept the utility funtions (bzero, etc) separate from functions which break existing code. But then, if HP were really into doing things properly, they'd have ported NCS in its entirety, too, or at least not kludged it by having servers send themselves signals every second. (!) They also haven't bothered to include usleep(), so BSD programs which want that routine can't be compiled without a bit of work either. -- _--_|\ Craig Macbride <uni: s900387@minyos.xx.rmit.oz.au> / \ <work: craig@bacchus.esa.oz.au> \_.--.*/ v
jco@crane.cis.ufl.edu (John C. Orthoefer) (05/20/91)
Speaking of usleep, I need one and got desperate enough to write one, for my
program that blinks the leds on the front panel of the 9k/400's. (If you
want my new led blinking program send me some e-mail.)
later
jco
ps. I'm looking for a job.
/* Program: usleep.c
** Author: John C. Orthoefer <jco@ufl.edu>
** Last edited: Wed May 15 09:09:43 1991 by jco (Dumpmaster John) on crane
**
** Works like but in no way is usleep() from SunOS.
*/
#include <time.h>
#include <signal.h>
extern int usleep_rtn();
usleep(useconds)
long useconds;
{
struct itimerval rttimer;
struct itimerval old_rttimer;
rttimer.it_value.tv_sec = 0;
rttimer.it_value.tv_usec = useconds;
rttimer.it_interval.tv_sec = 0;
rttimer.it_interval.tv_usec = 0;
signal(SIGALRM, usleep_rtn);
if (setitimer (ITIMER_REAL, &rttimer, &old_rttimer)) {
perror("usleep");
exit(1);
}
pause();
}
usleep_rtn()
{
}
--
"BSD the strongest Operating System avaible today without a prescription."
John C. Orthoefer Internet: jco@smuggler.cis.ufl.edu
University of Florida Floyd Mailing List: eclipse-request@reef.cis.ufl.edu
CIS Department >>>>>>New Address<<<<<<-------------^^^^tai@aspen.IAG.HP.COM (Tai Jin) (05/21/91)
In comp.sys.hp, s900387@minyos.xx.rmit.oz.au (Craig Macbride) writes: jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) writes: >I don't understand. I just wasted many tens of hours trying to port a >large package (the PP X.400 system) to HP/UX, which broke signal() >because I was trying to use -lBSD in order to get the b*() functions. Join the club. I love the way the on-line docs say how signal() works and how the BSD sigset() (etc) commands work, and then HP slips a BSD signal() into the same library as bzero(), etc, so that you can't use these routines without breaking (or rewriting) all your signal-handling. The way to make this work is to link the libraries in the correct order ie. cc ... -lc -lBSD This finds signal in libc.a and also finds the b* routines in libBSD.a. ...tai
sherman@unx.sas.com (Chris Sherman) (05/21/91)
Here is another usleep I found somewhere for HP/UX:
#include <sys/types.h>
#include <sys/time.h>
usleep(d)
int d;
{
struct timeval tv;
tv.tv_usec = d;
tv.tv_sec = 0;
select(1,0,0,0,&tv);
}
--
Chris Sherman .................... sherman@unx.sas.com |
,-----------------------------------------'
/ Q: How many IBM CPU's does it take to execute a job?
| A: Four; three to hold it down, and one to rip its head off.chan@hpfcmgw.HP.COM (Chan Benson) (05/21/91)
>>>Anyway, use of BSD functions doesn't imply "sloppy programming style", >>>just "BSD programming style". We're trying to minimize the pain required >>>for importing BSD and Sun applications. The only things we want to force >>>-lBSD for is when conflicting functions are used, such as setpgrp() and >>>signal(). >> >>I don't understand. I just wasted many tens of hours trying to port a >>large package (the PP X.400 system) to HP/UX, which broke signal() >>because I was trying to use -lBSD in order to get the b*() functions. >>I finally had to take out -lBSD and use macros for the b* stuff. >>Admittedly the package was not totally BSD-ish, in that it had a compile >>option for SYS5, which only addressed part of the BSD-SYS5 issues. >> >>Why would you want to force -lBSD when it breaks SYS5 code? > >You wouldn't. If HP had had any brains, they would have kept the utility >funtions (bzero, etc) separate from functions which break existing code. Yes, that's what the original poster said: With the new setup, you only link in libBSD to get Berkeley things that conflict with System V. All the other stuff (like the b* routines) are available without -lBSD. > They also haven't bothered to include usleep(), so BSD programs which want that > routine can't be compiled without a bit of work either. Sure they can, they just can't be linked. (Sorry, I'm just trying to live up to my snide reputation.) Here's a version of usleep I use: #include <time.h> usleep (usecs) long usecs; { struct timeval timeout; timeout.tv_sec = 0; /* should be usecs / 1000000 */ timeout.tv_usec = usecs; /* should be usecs % 1000000 */ select(0, 0, 0, 0, &timeout); } -- Chan Benson HP Fort Collins
mike@hpwin052.HP.COM (Mike Croom) (05/22/91)
nap from curses is also popular ------------------------------------------------------------------------------- | Mike Croom mike@hpwin052.uksr.hp.com - | Financial Services AEO - | London UK -------------------------------------------- | +44-71-583-6565 No catchy motto thought of yet - | VoiceMail +44-344-367538 ---------------------------------------------------
ken@hpcupt3.cup.hp.com (Kenneth M. Sumrall) (05/23/91)
>Sure they can, they just can't be linked. (Sorry, I'm just trying to >live up to my snide reputation.) Here's a version of usleep I use: > >#include <time.h> > >usleep (usecs) >long usecs; >{ > struct timeval timeout; > > timeout.tv_sec = 0; /* should be usecs / 1000000 */ ^^^^^^^^^^^^^^^^^^^^^^^^^ > timeout.tv_usec = usecs; /* should be usecs % 1000000 */ ^^^^^^^^^^^^^^^^^^^^^^^^^ > select(0, 0, 0, 0, &timeout); >} > Believe the two comments above. If tv_usec is more than 1,000,000, and tv_sec is zero, their is no delay at all. This is the behaviour I noticed two releases ago when I was porting some code. Of course, things could have changed, but why risk it? Hope this helps. > -- Chan Benson > HP Fort Collins | Ken Sumrall | Internet: ken%hpda@hplabs.hp.com | | HP California Language Labs | UUCP: ...!hplabs!hpda!ken | | "I'd stomp desert dope heads for some gas in my moped!" - Bill the Cat | | "What a stupid world" -Calvin (speaking to Hobbes) |
frank@grep.co.uk (Frank Wales) (05/24/91)
In article <2130012@aspen.IAG.HP.COM> tai@aspen.IAG.HP.COM (Tai Jin) writes: >In comp.sys.hp, s900387@minyos.xx.rmit.oz.au (Craig Macbride) writes: > Join the club. I love the way the on-line docs say how signal() works and how > the BSD sigset() (etc) commands work, and then HP slips a BSD signal() > into the same library as bzero(), etc, so that you can't use these routines > without breaking (or rewriting) all your signal-handling. > >The way to make this work is to link the libraries in the correct order >ie. cc ... -lc -lBSD >This finds signal in libc.a and also finds the b* routines in libBSD.a. One could also build new libraries with the disparate parts separated out by using ar(1), as HP could have done, then link with those instead. -- Frank Wales, Grep Limited, [frank@grep.co.uk<->uunet!grep!frank] Kirkfields Business Centre, Kirk Lane, LEEDS, UK, LS19 7LX. (+44) 532 500303
jbw@bigbird.bu.edu (Joe Wells) (05/25/91)
tml@tik.vtt.fi (Tor Lillqvist) writes:
I don't know if this is entirely good news... Doesn't this mean that
now also on HP-UX you can get away with sloppy programming style
(using the b* and index functions even if ANSI C and POSIX mandate
mem* and strchr)?
bcopy guarantees correct overlapping moves. memcpy does not. When ANSI C
or POSIX provide us with a function that is guaranteed to handle
overlapping moves correctly, then you can justify your position. Until
then, please don't get rid of bcopy. (On the other hand, bzero and bcmp
can probably be safely #defined away right now.)
--
Enjoy,
Joe Wells <jbw@cs.bu.edu>