Re: OpenBSD's strlcpy(3) and strlcat(3)
On Thu, 15 Jul 1999 18:40:17 CST, Warner Losh wrote: > I can see your point. I don't know if I'll like your man pages better > or not, but I'd be willing to give them a spin. Bring on the humble pie. It really isn't practical to try to have these pages match the approach of the existing pages. The best approach would be to add a description of strlcpy() to the strcpy.3 page and a description of strlcat() to the strcat.3 page. The differences between the new functions and those whose manpages they should be described in make for more confusion than we save by including them there. So I withdraw my objection to the style of the strl*() manpages, but only because I have nothing better to offer. ;-) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: problems with the integrated tcp-wrappers.
On Tue, 20 Jul 1999 17:33:24 CST, Greg Skafte wrote: > I've just recently switched from using the tcpwrappers port to the > native tcpwrappers implemention I really shouldn't be answering, since you've mailed the wrong mailing list, but I can't resist. :-) > the following config entries worked on the port but are not working with > the native "Not working" is always best defined by way of syslog messages or some other output, copied verbatim. :-) Nevertheless, I haven't tested the spawn option, so "there's a doubt setting up in my people's mind" [1]. How about this; I'll look into it in a few hours, since I might be able to tickle a bug on my own. In the meantime, you grovel through your syslog messages and see if you can spot any useful error messages. If you can, I'd appreciate private mail. Ciao, Sheldon. [1] Apologies to the Round The Horne crowd. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: problems with the integrated tcp-wrappers.
[ Hijacked from freebsd-hackers ] On Tue, 20 Jul 1999 17:33:24 CST, Greg Skafte wrote: > I've just recently switched from using the tcpwrappers port to the > native tcpwrappers implemention > > the following config entries worked on the port but are not working with > the native I've tested the spawn option using a standalone sshd daemon and both of the following two configurations work as expected (on their own, not in conjunction): sshd: ALL : \ spawn (/usr/bin/mail -s "sshd request from %h" sheldonh
MLINKS for select(2) FD_* macros
Hi folks, Would it be inappropriate to add select.2 MLINKS for FD_SET, FD_CLR, FD_ISSET and FD_ZERO? Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/usr.sbin/inetd inetd.c
[Hi-jacked from cvs-committers and cvs-all] On Wed, 21 Jul 1999 18:15:09 +0200, Poul-Henning Kamp wrote: > There is another one you may want to look at, I have not figured it > out yet: > > I try to start a ntpd from /etc/rc.local this way: > > nohup /usr/local/bin/ntpd -d -d > /usr/ntp/x.ntpd 2>&1 & > >and it invariably ends up dead in a few seconds with: > Jul 17 12:26:39 bogon ntpd[248]: ntpd exiting on signal 1 Can nohup really prevent processes from trapping SIGHUP? I thought it just set the SIGUP handler to discard and hoped for the best. Xntpd in the base system explicitly requests its graceful termination function, called finish(), be loaded as the SIGHUP handler. What is it you'd like? 1) nohup should prevent processes from trapping SIGHUP. 2) xntpd should reconfigure on SIGHUP. 3) xntpd is getting a SIGHUP and you're not sure where from. 4) xntpd is different from the port's ntpd in some way that should change. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: xmms port broken
[Hijacked from freebsd-hackers and freebsd-questions] Hi Chris, You've cross-posted this message to two inappropriate lists. The freebsd-ports mailing list is what you really wanted. A copy of this message (with your original question intact) has been sent to that list on your behalf. Ciao, Sheldon. --- Forwarded Message Message-ID: <3795f2a8.8d2e6...@thedial.com> Date: Wed, 21 Jul 1999 10:17:44 -0600 From: Christopher Taylor To: freebsd-hackers@FreeBSD.ORG, freebsd-questi...@feebsd.org Subject: xmms port broken Yesterday, I updated my ports tree with cvsup...I then attempted to make the audio/xmms port and received the following error... [r...@ezln23 xmms]# make ===> Extracting for xmms-0.9.1 >> Checksum OK for xmms-0.9.1.tar.gz. ===> xmms-0.9.1 depends on executable: libtool - found ===> xmms-0.9.1 depends on shared library: gtk12.2 - not found ===>Verifying install for gtk12.2 in /usr/ports/x11-toolkits/gtk12 ===> Returning to build of xmms-0.9.1 Error: shared library "gtk12.2" does not exist *** Error code 1 gtk12.2 _does_ exist on my system... after symlinking gtk-config and glib-config to gtk12-config and glib12-config, resectively, I was able to compile xmms by hand. However, it still gives me the same error if I try and install the xmms port. A side note...xmms plays audio fine, but the player is slow to respond to mouse clicks... - --Chris - -- Christopher Taylor Technical Director Earth Broadcasting Corporation (EBC) 415 East 200 South Salt Lake City, Utah 84111 phone: (801) 322-3949 cell: (801) 541-8287 email: ch...@thedial.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message --- End of Forwarded Message To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h
[Hijacked from cvs-committers and cvs-all] On Fri, 23 Jul 1999 11:28:12 +0200, Andre Albsmeier wrote: > I observed some kind of denial of service on -STABLE: I was > playing with the new nmap and did a 'nmap -sU printfix'. > inetd was running as "inetd -l" and started sucking all the > CPU time even the nmap had been terminated long ago. What does "sucking all the CPU time" mean? Does it mean that other programs were suffering, or does it mean that it was the only significant user of CPU and so showed up at close to 100% CPU usage? I suspect that the latter is true. > /var/log/messages file showed zillions of the following lines > being added continously: Well, you did ask for them (inetd -l). :-) > Jul 23 11:21:28 printfix inetd[1743]: time from [...] > Jul 23 11:21:28 printfix inetd[1743]: daytime from [...] Usually syslog will give you "last message repeated X times". Unfortunately, the alternation of the messages makes this impossible. David Malone had a few ideas on "clever" handling of UDP. While what he suggests might help reduce the number of messages you receive under legitimate use, it won't help against DoS, since the sender of packets can simply randomize the origin addresses. > Maybe you got an idea... I know exactly why you see what you see when you do what you do. All I can say is "don't do that", because I can't think of a why to cater for what you're doing in a sensible fashion. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.
On Fri, 23 Jul 1999 13:50:45 +0100, David Malone wrote: > You could turn on wrapping and log them at a level at which > syslog will ignore them. I'm not sure how much this would help > with inetd chewing CPU time, but... If, indeed, inetd is really "chewing CPU time". Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h
On Fri, 23 Jul 1999 15:06:02 +0200, Andre Albsmeier wrote: > But when inetd is run without -l it get 100%. Are you avoiding my question on purpose? :-) > On Fri, 23-Jul-1999 at 14:29:19 +0200, Sheldon Hearn wrote: > > > What does "sucking all the CPU time" mean? Does it mean that other > > programs were suffering, or does it mean that it was the only > > significant user of CPU and so showed up at close to 100% CPU usage? I don't care how the usage is split over syslog and inetd. What I want to know is whether their combined usage of the CPU causes a serious problem for other CPU-bound processes. After all, you _have_ asked the inetd+syslog pair to do a lot of work. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.
On Fri, 23 Jul 1999 14:16:19 +0100, David Malone wrote: > > But when inetd is run without -l it get 100%. > > Interesting - does it still answer requests during this time? Yeah. What we really need to know is how many packets inetd actually received. The manpage excerpt that DES showed us indicates that nmap doesn't stop sending packets immediately unless it gets an ICMP message back. We know that inetd doesn't send ICMP messages back. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Mentioning RFC numbers in /etc/services
Hi folks, I plan to mention in the comments for each service in /etc/services, the latest RFC describing the service. I also plan to mention in the manpage for services(5) the e-mail address to which requests for "How do I get the RFCs" should be sent. If anyone is worried that I'll get RFC numbers wrong, I'm happy to pass my diffs by him. I intend to do this next week-end, so let me know before then if you'd like to see what I'll be doing beforehand. Thanks, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Mentioning RFC numbers in /etc/services
On Sat, 24 Jul 1999 08:25:55 EST, Chris Costello wrote: >Are you going to be listing all the RFCs that apply? For > example, DNS is 1033, 1034, and 1035, and NNTP is 0850 and 0977. I doubt I'll be listing obsoleted RFCs. :-) I'll do the best I can. Send me private mail if you'd like to see what that is. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: [Fwd: wd0 DMA errors]
On Sun, 25 Jul 1999 10:59:26 MST, Doug wrote: > No answer on -current, any help appreciated. We're probably all sitting here thinking "I'm sure this was asked and answered recently. He can read his CURRENT mail like the rest of us." For the terminally lazy, this was a bug in the pci code, introduced a week or so ago and fixed in CURRENT and reverted in STABLE some time in the last few days. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: deny ktrace without read permissions?
On Sun, 25 Jul 1999 21:50:55 MST, jko...@freebsd.org wrote: > Yes, but /if/ KTRACE is present, today's code allows you to bypass > the lack of read permissions on an executable. That shouldn't be > allowed. The current behaviour could be regarded as a security > hole actually :). This doesn't look right. If I can execute a binary, I can have the system allocate memory to me and but the binary image in it. It's my memory. :-) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
file(1) Magdir candidate: wintendo
Hi folks, I've had some interesting comments from David Bushong, motivating for inclusion of his Magdir candidate on PR 12554. He makes a strong case for a bloated file(1) Magdir. The only thing we're battling with is a filename for his submission. Just because a bloated file(1) magic database is good, doesn't mean we want a zillion files in the Magdir source, though. So I propose a new file wintendo, for all gaming file formats used on the MS Windows platform. Sensible objections? Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Mentioning RFC numbers in /etc/services
On 26 Jul 1999 12:59:57 +0200, Dag-Erling Smorgrav wrote: > Don't. Instead, put it in a separate rfc(7) man page which you refer > to in the services(5) man page. Cool! :-) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: file(1) Magdir candidate: wintendo
On Mon, 26 Jul 1999 22:17:20 +0200, Mark Murray wrote: > "Wintendo" is a bad name for anything official. Try to find MS's > official name for the format(s). You're hoping for a standard name for file formats of games used on Microsoft platformat? There are two words in that question that one doesn't usually fine together in a sentence that doesn't contain the word "bastardize". :-) I'll try... Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: file(1) Magdir candidate: wintendo
On Mon, 26 Jul 1999 22:46:31 +0200, Sheldon Hearn wrote: > You're hoping for a standard name for file formats of games used on > Microsoft platformat? Duh, I'm being obtuse. Your question indicates that I've phrased my proposal in such a way as to suggest that this is for formats of Microsoft games. That's not what I meant. I meant games used on the Microsoft platforms. However, it occurs to me that this is stupid, since the same game may be available on multiple PC platforms, all using the same file format. So... how about pcgames as the name of the file? Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: file(1) Magdir candidate: wintendo
On Mon, 26 Jul 1999 23:30:08 +0200, Mark Murray wrote: > You could start with "WinEXE". Save game file formats, not game executables. You think WinEXE tops my pcgames suggestion? Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: XFree 3.3.4 not on ftp.freebsd.org?
On Mon, 26 Jul 1999 21:09:50 -0400, Tim Vanderhoek wrote: > I seem to remember that you can get away with a simple "mkdir > /var/db/pkg/xxx" to fake it. Can you think of any ports that test for the existance of XFree86 using the package system? They use USE_X_PREFIX or USE_X_LIB, both of which test for libX11, no? Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
securelevel too course-grained?
On Mon, 26 Jul 1999 20:48:28 MST, Matthew Dillon wrote: > Subject: Re: securelevel and ipfw zero > > However, it does not allow you to do it if you are sitting at secure > level 3. You don't think that this discussion highlights the growing inadequacy of the securelevel mechanism's lack of granularity? I have a feeling it'll be time soon enough for us to make each of the decisions that is normally affected by securelevel dependant on the value of sysctl knobs. Presumeably one or more of them would be "write-once" knobs. :-) How much existing software tests for kern.securelevel? And could we make its value dependant on the new knobs? I can't see it being too big a problem. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: XFree 3.3.4 not on ftp.freebsd.org?
On Mon, 26 Jul 1999 22:41:24 MST, Doug wrote: > However right after 3.2-R came out there was a flurry of -questions > mail about broken pkg dependencies because sysinstall wasn't properly > registering the X install. Is this a different problem from the broken compat22 installation? > If the port depending on the existence of /var/db/pkg/X* is actually > an error I'll report what I find to the -ports list. I'm pretty sure it constitutes "non-conformant" behaviour and I'd be happy to look at it. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: newsyslog owner.group -> owner:group
Hi David, Your commit catalogued in the cvs log for newsyslog.c: revision 1.23 date: 1999/06/28 03:15:02; author: obrien; state: Exp; lines: +2 -2 Syntax for user/group is changed from "user.group" to "user:group" to be consistant with chown(8). This one raised a number of eyebrows and a few people asked you to hold on to legacy support for a single release. It's a reasonable request, given the obscure error message one gets for providing the previously supported syntax: newsyslog: error in config file; bad permissions: /var/log/exim/mainlog exim.mail 640 7 *24Z Is the reason you haven't re-instated legacy support because you are strongly opposed to it, or because you don't have time? If it's the latter, I'll do it. If the former, note that your commit message was broken, since chown(8) supports both periods and colons. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: XFree 3.3.4 not on ftp.freebsd.org?
On Tue, 27 Jul 1999 06:54:32 -0400, Tim Vanderhoek wrote: > It used to be that packages would depend on X, but Sheldon reminded me > (although I think it was accidental :-) that XFree86 was added to > PACKAGE_IGNORE_DEPENDS to prevent this. PKG_IGNORE_DEPENDS is what I had in mind. :-P Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: newsyslog owner.group -> owner:group
On Tue, 27 Jul 1999 06:57:49 -0400, Tim Vanderhoek wrote: > Consider also adding owner:group support to -stable in order to > provide the longest change-over period possible. You have to read the CURRENT newsyslog(8) manpage before you realize that this is a lose-lose situation: COMPATIBILITY Previous versions of the chown utility used the dot (``.'') character to distinguish the group name. Begining with FreeBSD 4.0, this has been changed to be a colon (``:'') character so that user and group names may contain the dot character. If we don't offer backward compatibility, people will whine when they stub their toes. If we do, we break support for usernames which contain the dot (``.'') . I think David's chosen the lesser of two evils and I support his decision. However, I think we could at least introduce consistency with chown(8) by making dot-as-token support a compile-time option, -DSUPPORT_DOT which is turned _on_ by default. Later, -DSUPPORT_DOT can be removed from the Makefiles for chown(8) and newsyslog(8) and documented in src/Makefile.inc1 . Sorry for bringing this up without doing all my homework. Diffs in the pipeline. :-) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
On 27 Jul 1999 13:37:35 +0200, Dag-Erling Smorgrav wrote: > http://www.freebsd.org/~des/software/grep-0.7.tar.gz> > > I move that we replace GNU grep in our source tree with this > implementation, once it's been reviewed by all concerned parties. When I committed the port (textproc/freegrep), Jamie assured me that he'd keep me updated on the progress of his software. That was the last I heard of it, and the port is still sitting at version 0.3 . Version 0.3 broke port-building badly. Does version 0.7 make it through a build of a whole stack of ports? Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
On 27 Jul 1999 13:48:21 +0200, Dag-Erling Smorgrav wrote: > > Version 0.3 broke port-building badly. Does version 0.7 make it through > > a build of a whole stack of ports? > > Yes. Excellent. I'll nuke the port once you've merged the new grep to STABLE. :-) Later, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
On Tue, 27 Jul 1999 08:19:38 -0400, "Brian F. Feldman" wrote: > Getting rid of as much as possible, gradually, is a Very Good Thing; > this is how we get stability and performance improvements. Only if the replacements are as stable and robust as their predecessors. In this case, the implementation we'll be introducing will introduce a performance loss, not a gain. As far as stability goes, there's a loss involved _if_ passing the GNU grep regression tests is important. Don't get me wrong. I'm all for replacing GNU software. Let's just be realistic and keep in mind that being non-GNU doesn't necessarily mean better. In this case, I'm all for the change, since I don't use grep for serious regex work and the readability gain outweighs any loss of performance. you probably feel the same way. Out opinions are those of developers, though. It's always worth remembering that. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
On Tue, 27 Jul 1999 07:49:22 EST, David Scheidt wrote: > Does any have numbers about how much slower the new grep is? Just by the way, if the latest version somehow uses mmap without my having noticed, then I've ontroduced a red herring. ;-) Version 0.3 certainly didn't use mmap. As I understand it, this means that the performance hit, whatever the magnitude, would be noticed with larger files. I've copied the author, who's probably in the best position to give you hard numbers. :-) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: newsyslog owner.group -> owner:group
On Tue, 27 Jul 1999 13:43:33 +0200, Sheldon Hearn wrote:
> Sorry for bringing this up without doing all my homework. Diffs in the
> pipeline. :-)
Ha!
Diffs that produce a win in the midst of an apparent lose-lose. We now
continue to support the dot as a separator without breaking user- and
groupnames which include dots. I took my lead from chown(8).
Ciao,
Sheldon.
Index: Makefile
===
RCS file: /home/ncvs/src/usr.sbin/newsyslog/Makefile,v
retrieving revision 1.6
diff -u -d -r1.6 Makefile
--- Makefile1999/01/22 19:38:39 1.6
+++ Makefile1999/07/27 15:04:37
@@ -1,7 +1,7 @@
# $Id: Makefile,v 1.6 1999/01/22 19:38:39 wollman Exp $
PROG= newsyslog
-
+CFLAGS+=-DSUPPORT_DOT
MAN8= newsyslog.8
.include
Index: newsyslog.8
===
RCS file: /home/ncvs/src/usr.sbin/newsyslog/newsyslog.8,v
retrieving revision 1.19
diff -u -d -r1.19 newsyslog.8
--- newsyslog.8 1999/06/28 03:15:01 1.19
+++ newsyslog.8 1999/07/27 14:18:12
@@ -275,12 +275,12 @@
.Pp
Copyright 1987, Massachusetts Institute of Technology
.Sh COMPATIBILITY
-Previous versions of the chown utility used the dot (``.'') character to
-distinguish the group name.
-Begining with
-.Fx 4.0 ,
-this has been changed to be a colon (``:'') character so that user and group
-names may contain the dot character.
+Previous versions of the
+.Nm
+utility used the dot (``.'') character to distinguish the group name.
+This has been changed to the colon (``:'') character so that user and group
+names may contain the dot character. Future versions may not provide
+backward compatibility.
.Sh "SEE ALSO"
.Xr gzip 1 ,
.Xr syslog 3 ,
Index: newsyslog.c
===
RCS file: /home/ncvs/src/usr.sbin/newsyslog/newsyslog.c,v
retrieving revision 1.23
diff -u -d -r1.23 newsyslog.c
--- newsyslog.c 1999/06/28 03:15:02 1.23
+++ newsyslog.c 1999/07/27 15:06:24
@@ -286,7 +286,13 @@
if (!*parse)
errx(1, "malformed line (missing fields):\n%s", errline);
*parse = '\0';
+#ifdef SUPPORT_DOT
+/* Older configurations used '.' between user and group */
+if ((group = strchr(q, ':')) != NULL ||
+(group = strchr(q, '.')) != NULL) {
+#else
if ((group = strchr(q, ':')) != NULL) {
+#endif
*group++ = '\0';
if (*q) {
if (!(isnumber(*q))) {
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: newsyslog owner.group -> owner:group
Hi Brian, Okay, your mail quoted below came around the same time I sent my diffs. This entire response assumes that you don't like the diffs. On Tue, 27 Jul 1999 08:10:47 MST, "David O'Brien" wrote: > It was a one character fix in -CURRENT and I don't see any reason to ugly > the code with supporting both syntaxes in -CURRENT. All I can offer in response is "because it's not _that_ ugly and there's no reason to leave concrete blocks on the upgrade path, even if you are supposed to walk it in steel-capped boots". :-) > The change will be documented in 4.0-R's release notes. If people > don't read that, then they will be in trouble in many other ways. > > Anyway, it has been only ":" in -CURRENT for a while now, and I > haven't received any death threats, so people must not be tripping > over this on a daily basis. :-) Judging by the number of PRs I've dealt with concerning the built-in tcp_wrappers included in 3.2, I have to say that this argument gives me the willies. There were _no_ complaints about inetd and built-in wrappers -- until it hits STABLE. :-) Jordan once told me that we do as much as (but no more than) we can to make the upgrade path as smooth as possible. I don't think that the extra line of code is more than we can do. :-) I'm acting out of self-preservation here. If a line of code can save me 5 PR's on 4.0-RELEASE, I'll take the line. *snort* > The problem with printing out warnings is ``newsyslog'' is usually run > from cron(8), and anything printed out will often not be seen as I am of > the opinion many do not read root's mail. Oh, I wasn't suggesting that you should do anything about the warnings. I was trying to point out that the wallies who don't read the release notes are _definitely_ going to come crying to us. :-) Later, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
On Tue, 27 Jul 1999 23:18:14 +0900, "Daniel C. Sobral" wrote: > I'm talking about cpdup, which can be found in > http://www.backplane.com/FreeBSD/. Someone posted a port at the > time, but I don't know if anyone ever committed the port. I'll commit a port in the next few days. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: newsyslog owner.group -> owner:group
On Tue, 27 Jul 1999 09:07:34 MST, "David O'Brien" wrote: > To paraphase Bill Paul: > > G that's part of my last name. N! I was chatting to a buddy about this just after I sent you the diffs and actually mentioned to him that I thought I might have made this mistake again. Since the first time, I've been quite careful about obrien and brian. Apologies and stuff. :-) Later, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: file(1) Magdir candidate: wintendo
On Tue, 27 Jul 1999 22:20:40 MST, "David O'Brien" wrote: > My advice would be to submit his PR to Chris Demtrito(sp?), file's > maintainer. Then import NetBSD's file (Chris is a NetBSD guy). Hmmm. So file(1) is a contrib candidate? Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: file(1) Magdir candidate: wintendo
On Wed, 28 Jul 1999 12:03:25 +0100, Andy Doran wrote: > You may want to verify this. I'm pretty sure that Christos Zoulas > (another NetBSD guy) maintains file(1): chris...@zoulas.com. Confirmed. Other than the mistaken name, I think David obsoleted further discussion, since it really is the best approach. :-) Thanks, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: bin/12852: Non-standard behavior of fread(3)
Hi folks, Could someone have a look at the patch proposed on PR 12852? I understand the motivation, since it seems reasonable to me that ferror() should return EBADF after an attempt to read from stdout. At the moment, ferror() returns 0 after an attempt to read from stdout. Thanks, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: bin/12852: Non-standard behavior of fread(3)
On Wed, 28 Jul 1999 20:13:18 +0200, Robert Nordier wrote: > There's no question this needs changing. An ISO example actually > reads along the lines of: The question, though, is whether it needs changing _now_, or whether this'll break a number of critical utilities that rely on the broken behaviour. I can't imagine the latter case being true, but I thought it safe to put to question before folks with more experience. :-) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Mentioning RFC numbers in /etc/services
On Thu, 29 Jul 1999 09:04:20 +0100, Josef Karthauser wrote: > A question that always baffled me (I'm fairly easy to baffle) is why > we've got some numbers defined as both udp and tcp when the service > type is only one or the other. Does anyone know? Probably because this question isn't accompanied by a list of offenders. :-) By the way, I originally said I'd have this done in a week. I can only imagine how many of the die-hards giggled in the background, since it involves quite a bit of reading. And then there are all the useful suggestions I've received. Let's leave this alone until I have diffs to show y'all? Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: file(1) Magdir candidate: wintendo
On Wed, 28 Jul 1999 09:55:24 MST, "David O'Brien" wrote: > My major Duh!! If Christos sees this thread, my apologies. Hehe, now you know how it feels to be the guy who calls you Brian. :-) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: interesting bug in /usr/bin/cmp
On Thu, 29 Jul 1999 00:52:27 -0400, "Brian F. Feldman" wrote: > If noone has any objections, I will commit this and MFC it in a week or so. > > --- src/usr.bin/cmp/regular.c.origThu Jul 29 00:43:50 1999 > +++ src/usr.bin/cmp/regular.c Thu Jul 29 00:44:54 1999 |--- src/usr.bin/cmp/regular.c.orig Thu Jul 29 00:43:50 1999 |+++ src/usr.bin/cmp/regular.c Thu Jul 29 00:44:54 1999 -- Patching file regular.c using Plan A... Hunk #1 succeeded at 57. Hunk #2 failed at 76. 1 out of 2 hunks failed--saving rejects to regular.c.rej Hmm... Ignoring the trailing garbage. done What's up? :-) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
No MAXUID ?
Hi folks, I've come up empty-handed hunting for a constant that defines the maximum UID supported by the system. I'm working on our passwd and pwd_mkdb stuff and want to get rid of the artificial limitation of 65535 (USHRT_MAX) imposed in (at least) pwd_mkdb. Have I missed a useful define, or should I add one? If I should add one, does it go in pwd.h, types.h or syslimits.h? Thanks, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: No MAXUID ?
On Fri, 30 Jul 1999 00:53:56 MST, Mike Smith wrote: > It probably belongs in param.h, and you can probably safely calculate it > as (uid_t)0 - 1; Excellent. Another question I should have asked in my original mail is this: are there magical reasons why we should want pwd_mkdb to bleat for every encountered UID greater that 65535 ? Can you think of anything other than hysterical raisins why I shouldn't bump that artificial limit to the new MAX_UID when that arrives? Thanks, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: No MAXUID ?
On 30 Jul 1999 15:38:30 +0200, Dag-Erling Smorgrav wrote: > How many times do I have to go through this? Until I stuff a comment in the source that explains this. :-) > There is no "artificial limitation in pwd_mkdb". pwd_mkdb warns > against UIDs larger than 65535 because legacy software that uses > unsigned short instead of uid_t will break with large UIDs. Would you be happy with changing things so that only one warning is generated? Something like "9 > max_uid 65535: others may exist"? The current behaviour is quite annoying with large passwd files. :-) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: No MAXUID ?
On Sat, 31 Jul 1999 13:39:16 -0400, Adrian Filipi-Martin wrote: > I'd be in favor of adding a /etc/pwd_mkdb.conf or some similar > file. Eeeuw! :-) I'm not in favour of this idea, but issuing a single warning for one or more UID's encountered isn't behaviour that would make retrofitting your idea impossible if you decided to do it later. While warnings and error messages should give me enough information to address a problem efficiently (something on the wishlist of any Wintendo administrator), once I know there is more than zero potentially problematic entries, I can used cat, awk and sh to find all the culprits if I want to. Ciao, Sheldon. PS: Those two paragraphs have nothing to do with each other, by the way. :-) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Mentioning RFC numbers in /etc/services
On Fri, 30 Jul 1999 15:05:14 MST, Doug wrote: > I still haven't heard anyone answer the two key (IMO) questions. Your questions are easier answered in reverse order: > and how do you justify the additional cost to parse the file for every > single system call that uses it? The information is part of the comments within the file. The cost is in disk space, and it's cheaper than fleabites. > Why is it better to have this in the file than in a man page, Since it costs nothing to have it in /etc/services, why not leave it there along with the information with which it's associated? The alternative is to have a manpage that contains most of the information in /etc/services! > My only concern is that putting it IN the file has more costs than > benefits. What am I missing here, that I don't see a cost? What software scans the lines in /etc/services beyond the comment delimiter, other than null terminator searches? So far, I've had some great advice on this issue (although I think it's time the thread took a long walk off a short pier), so I definitely have my ears open. I'm just having trouble either understanding or believing what I'm hearing. :-) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: No elf(5) man page (docs/7914)
On Fri, 30 Jul 1999 23:46:26 +0200, Jeroen Ruigrok/Asmodai wrote: > If no-one objects I'll submit a manpage per a.out(5) style tomorrow > for review untill it's ready for inclusion. Anyone who objects to your submissions is a woes -- real bastards wait for you to do the work before shooting you down. :-) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
On Fri, 30 Jul 1999 22:07:26 -0400, Tim Vanderhoek wrote: > b$ time ./grep -E '(vt100)|(printer)' longfile > /dev/null > b$ time grep '(vt100)|(printer)' longfile > /dev/null You think that's fair? Surely you can't expect Jamie's extended regex support to outperform GNU's simple regex support? :-) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Mentioning RFC numbers in /etc/services
On Fri, 30 Jul 1999 15:10:18 MST, Doug wrote: > On some of the machines I administer I have some custom entries for > /etc/services that make more sense than the defaults, especially for > the ports > 1023. Would you need these entries if inetd let you specify port numbers instead of service names? That behaviour is a function of laziness, rather than principle. If I'm correct in my suspicion that most people only meddle with /etc/services to appease inetd's harvest of sown laziness, then the effort required to change the current behaviour will be worthwhile. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Mentioning RFC numbers in /etc/services
On 02 Aug 1999 13:05:17 +0200, Dag-Erling Smorgrav wrote: > The correct way to do this is to fix getservbyname() so it accepts > port numbers. Would this not still require modifications to /etc/services for services not already mentioned in that file? Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Mentioning RFC numbers in /etc/services
On 02 Aug 1999 13:19:01 +0200, Dag-Erling Smorgrav wrote: > > Would this not still require modifications to /etc/services for services > > not already mentioned in that file? > > Allow me to re-quote the message I answered: > > > I vote for allowing inetd.conf to specify a port number instead of a > > service name... I think that's exactly what Daniel's getting at. If we fix this in inetd, we get what we want. If we fix this in getservbyport() we may get something that we don't want, namely applications that relay on the existing behaviour of the function stop working as intended. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Mentioning RFC numbers in /etc/services
On Sat, 31 Jul 1999 23:00:15 MST, Doug wrote: > > Would you need these entries if inetd let you specify port numbers > > instead of service names? > > Errr... while that may be of value to someone, it has nothing to > do with the issue Ben and I were discussing. Yes yes. I'm not trying to contribute to the conversation you're having. I'm trying to get your opinion on an issue that came up during your conversation. :-) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Mentioning RFC numbers in /etc/services
On 02 Aug 1999 13:27:44 +0200, Dag-Erling Smorgrav wrote: > I don't see in what way an application could break if getservbyname() > suddenly accepted numeric port specifications. It won't ``stop working > as intended'', it'll keep on working as it always used to, plus a > little more. My application limits the port numbers it'll play with based on what's in /etc/services, since getservbyname() implies this limitation. Administrators rely on the fact that only root can play with /etc/services so that this silly application can't play with ports that aren't in that file. No getservbyname() doesn't work the way it used to, and the administrator is shot in the foot, even though he didn't pull the trigger. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Mentioning RFC numbers in /etc/services
On Mon, 02 Aug 1999 07:30:32 -0400, Daniel Eischen wrote: > Are you also going to allow getservbyport to lookup names? And how are you going to squish a name into an int? :-) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
quad_t and portability
Hi folks, I want to patch wc(1) so that it uses quad_t instead of u_long. This is necessary if wc(1) is to produce sensible results for files containing more than 4GB of data. The changes made to NetBSD to support this are conditional on NO_QUAD being undefined. Do I need to worry about this? Is it likely that FreeBSD will be compiled for a platform that that doesn't offer quad_t? My feeling is that the conditionalization should be left out until then. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: quad_t and portability
On Fri, 06 Aug 1999 15:29:25 +0200, Sheldon Hearn wrote: > I want to patch wc(1) so that it uses quad_t instead of u_long. This is > necessary if wc(1) is to produce sensible results for files containing > more than 4GB of data. Yes yes, before you jump on my head, I meant u_quad_t. :-) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Using legacy sysinstall to upgrade live system
Hi folks, I've just gotten feedback from PR 12777, in which at least 2 people are complaining that sysinstall as installed by 3.1-RELEASE can not be used to upgrade a live machine to 3.2-RELEASE on the fly. I've told both parties that they need to use a boot floppy with the correct version of sysinstall, or build a 3.2-RELEASE sysinstall from source, and one of the chaps I'm speaking to thinks that this is unreasonable. Before I tell him that diffs are welcome, I thought I'd check that I'm not making a mistake here. I lost my confidence when it was pointed out that sysinstall can be given any arbitrary release name to use for Upgrade without issuing any warnings. So? Am I wrong? If you _are_ supposed to be able to upgrade to any arbitrary release using sysinstall as installed by any prior release, perhaps someone could suggest the cause of the problems reported on the PR? Thanks, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Using legacy sysinstall to upgrade live system
On Wed, 11 Aug 1999 00:07:41 MST, "Jordan K. Hubbard" wrote: > Nonetheless, for the expected installation experience one is > encouraged to boot the desired OS release's installation media and > select an upgrade instead of a new install. Gotcha. So you'd be interested in diffs that teach sysinstall to bleat if an Upgrade is requested for a release for which the instance of sysinstall was not designed? Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Using legacy sysinstall to upgrade live system
On Wed, 11 Aug 1999 17:08:10 CST, Wes Peters wrote: > It's OK to let the users shoot their feet off, but they may not know > they're about to shoot their feet off. Giving them an alert would be > polite. I'll feel more comfortable about letting them shoot their feet off if you can point out _any_ way in which it might be beneficial for them to do so. :-) later, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Using legacy sysinstall to upgrade live system
On Wed, 11 Aug 1999 20:34:59 -0400, Tim Vanderhoek wrote: > I suggest that it would be beneficial for you to let them shoot off > their feet... I have used legacy sysinstall to upgrade a live > multiuser system before and will probably do so again. Hair-raising. :-) Anyway, I've snuffled around in the code and I think I'd have to teach sysinstall what release it was built for before producing as comprehensive a warning as Wes was talking about. That'd be easy if I knew how VAR_RELNAME gets initialized. My take on the code made me think it's via kern.osrelease, but that doesn't seem to be the case. I've attached the diff I have on hand, but I'd obviously like to know how to do this properly. > Hmm... "bleet"'s not in esr's hacker dictionary. My original spelling was "bleat". Ciao, Sheldon. Index: options.c === RCS file: /home/ncvs/src/release/sysinstall/options.c,v retrieving revision 1.62 diff -u -d -r1.62 options.c --- options.c 1999/08/05 19:50:26 1.62 +++ options.c 1999/08/12 01:04:16 @@ -95,7 +95,10 @@ #define TAPE_PROMPT"Please enter the tape block size in 512 byte blocks:" #define NEWFS_PROMPT "Please enter newfs(8) parameters:" -#define RELNAME_PROMPT "Please specify the release you wish to load or\n\"none\" for a generic release install:" +#define RELNAME_PROMPT "Please specify the release you wish to load or " \ +"\"none\" for a\ngeneric release install. Using an installed version " \ +"of sysinstall\nto install or upgrade to later releases is not " \ +"recommended." #define BPKG_PROMPT"Please specify the name of the HTML browser package:" #define BBIN_PROMPT"Please specify a full pathname to the HTML browser binary:" #define EDITOR_PROMPT "Please specify the name of the text editor you wish to use:" To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Various Questions
On Thu, 12 Aug 1999 11:29:47 GMT, Niall Smart wrote: > Or is the test for IFF_PROMISC made earlier in the code? You > should only print a disabled message when it has previously > been enabled so that log file watchers can always match up > the up/down pairs. I've been using if.c modified exactly as suggested for a few months now and have experienced the intended results without apparent problems. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: New tests for test(1)
On 12 Aug 1999 11:42:42 +0200, Dag-Erling Smorgrav wrote: > NetBSD's test(1) utility has this (-nt and -ot). We should probably > merge in their changes. Their code isn't useful in this case, since they've merged in a pdksh-derived version of test. How about we do the same? :-) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Various Questions
On Thu, 12 Aug 1999 12:20:35 GMT, Niall Smart wrote: > But what happens if you write a program which does whatever ioctl is > required to unpromiscify an interface and run it on an unpromiscuous > interface, does it print a message to syslog even though promiscuous > mode was never enabled in the first place? Like I said, I seem to get the intended behaviour. vty1 -> start trafshow Aug 12 12:26:41 axl /kernel: xl0: promiscuous mode enabled vty2 -> start trafshow vty1 -> kill trafshow vty2 -> kill trafshow Aug 12 12:27:22 axl /kernel: xl0: promiscuous mode disabled :-) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: New tests for test(1)
On Thu, 12 Aug 1999 12:26:41 GMT, Bob Bishop wrote: > Further, isn't test a builtin for most (all?) shells? Sounds like a can of > worms to me... If your only motivation for saying it's a can of worms is that test is usually a builtin, don't sweat it. Lots of scripts insist on using /bin/test . Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: New tests for test(1)
On Thu, 12 Aug 1999 13:15:52 +0200, Graham Wheeler wrote: > Portability is a Good Thing, but I write a lot of one-off scripts > in which portability isn't an issue. Not to mention that following NetBSD's lead on issues relating to portability probably is seldom a bad idea. :-) Give PR 13091 a bash. Or a sh. Whatever works for you. :-) >Number: 13091 >Synopsis: [PATCH] pdksh-derived replacement for test(1) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: New tests for test(1)
On Thu, 12 Aug 1999 12:22:39 +0200, Sheldon Hearn wrote: > Their code isn't useful in this case, since they've merged in a > pdksh-derived version of test. How about we do the same? :-) By the way, OpenBSD have _also_ incorporated NetBSD's test. *evil.grin* Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: New tests for test(1)
On Thu, 12 Aug 1999 11:41:31 -0400, "Brian F. Feldman" wrote: > > NetBSD's test(1) utility has this (-nt and -ot). We should probably > > merge in their changes. > > Hmm... this is in pdksh too... Don't go there. :-) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: New tests for test(1)
On Fri, 13 Aug 1999 15:36:24 +1000, Peter Jeremy wrote: > It would be nice, but there are portability issues. Hi Peter, I'm only replying to your mail because you're the last person to mention portability as a case againsdt NetBSD's test(1). Just how many other platforms need to support an _extension_ that is _fully_ backward compatible before we'll consider implementing it? With this attitude driving us, we'll end up being the only OS that doesn't support a number of fetures, all in the name of portability. :-) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: New tests for test(1)
Hi folks,
The pdksh-derived test(1) used by NetBSD and OpenBSD has made it through
a ``make world'' and package run on my box. It passes the regression
tests supplied with our own test(1) in exactly the same way as our own
test(1) does, and shows no noticeable performance difference.
I've mentioned several times that portability is a non-issue here
and haven't heard any rebuttals. I have a PR open (PR 13091) for
replacing our test(1) with the one used by {Net,Open}BSD. The
PR contains a diff which you should ignore. Rather look at
http://www.freebsd.org/~sheldonh/test/ :-)
So are there any reasonable ojections to our following the lead of our
sister free-BSD's?
Ciao,
Sheldon.
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: libcompat proposition
On Fri, 13 Aug 1999 09:16:09 -0400, Jamie Howard wrote: > I saw someone say that anything NetBSD did in the name of portability must > be right (in the test thread). :) Close, but what I said was more along the lines that following NetBSD's footsteps on issues relating to portability is _seldom_ a bad idea. :-) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: libcompat proposition
On Fri, 13 Aug 1999 12:52:05 -0400, "Brian F. Feldman" wrote: > Direct veto by core member (Jordan) prevents this. I really think it > should be in libcompat, the more I consider every option. Regardless of what Jordan says, you should do your best to put it where most other folks put it. Otherwise, you'll end up with source that expects it in one library while FreeBSD is a special case for which you need to link against another. Just look at Linux with their libnet. :-) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: New tests for test(1)
On Fri, 13 Aug 1999 12:50:54 -0400, "Brian F. Feldman" wrote: > I fully agree with this. If it can be cleanly added to the current test(1) > (which it can), we should have it, even if it were JUST for the sake of > portability. Ah, but I'm not proposing that we add new functionality to the existing test(1). The code gave me a head-ache. I'm proposing that we replace our test(1) entirely. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Using legacy sysinstall to upgrade live system
On Fri, 13 Aug 1999 17:51:10 MST, dannyman wrote: > Uhmmm, what if we don't have a floppy drive? Then you probably have a CDROM drive or a network interface, both of which can be used to get sysinstall onto your machine. :-) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Whither makefiles for src/crypto/telnet/* ?
On Fri, 13 Aug 1999 23:42:48 MST, "Dave Walton" wrote: > If you really want to work on an encrypted telnet, check out The > Stanford SRP Authentication Project (http://srp.stanford.edu/srp/). > I'd love to see SRP integrated into the FreeBSD telnet/telnetd. Cool, another non-exportable system available to US users only. :-) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: IDE quirk in 3.2-STABLE kernel ?
Hi folks, I didn't see any pointers other than pilot error raised in the recent thread with subject line: Subject: Re: IDE quirk in 3.2-STABLE kernel ? Perhaps those of you who're in support of the pilot error notion could have a look at PR 13174 and comment? The originator claims that his kernel only finds wdc0 when he "auto-detects" his hard drives with his Award BIOS. He doesn't specify whether he has drives connected to that controller, which is why I've cc'd him on this mail. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Using legacy sysinstall to upgrade live system
On Mon, 16 Aug 1999 17:48:22 MST, dannyman wrote: > The point of it is, it's easy enough to download the floppies, but > it's really hard to boot a system off an .flp image. :p Presumably you saw the posted trick about dd'ing the floppy image to your swap partition and booting off _that_? :-) > But, on to my original question, has anybody been looking at a more > "user friendly" "upgrade the darn thing *REAL EASY*" kind of setup? > maybe invoke a networked pkg_add to run the latest sysinstall w > dependencies? Your original question? I started this thread. ;-) The best answer someone who is neither omniscient nor omnipresent can give you is I expect I'd be surprised to find that anybody was working on such a thing. Assume that further silence on the issue confirms that feeling. I've seen lots of people come up with ideas that they felt were good and worthy of lots of argument, but the ideas always seem to be all talk(1) and no diff(1). ;-) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: How much memory (max) will FreeBSD use?
On Mon, 16 Aug 1999 22:45:28 -0400, "Stephen J. Roznowski" wrote: > On a stock system (3.2 and 4.0), how much RAM will a system be able to > use? Will a stock system use all 4GB? I expect that someone else will answer your question. I just want to clear up a possible misunderstanding that could cost you a lot of wasted time later. The word "stock" doesn't apply to 4.0 . That's the development edge of FreeBSD, which is not recommended for use in production environments by people who aren't prepared to bleed graciously. :-) Make sure you're familiar with the information at the following URLs before choosing to run 4.0-CURRENT: http://www.freebsd.org/handbook/cutting-edge.html http://www.freebsd.org/FAQ/FAQ7.html Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Kerberos 5 integration.
On Tue, 17 Aug 1999 00:51:27 -0400, "Matthew N. Dodd" wrote: > Who were the parties that were heading up the Kerberos 5 integration? > > I have questions. Seek Ye first the kingdom of Mark. (markm) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD XFS Port & BSD VFS Rewrite
On Tue, 17 Aug 1999 00:30:02 CST, Warner Losh wrote: > Acutally, the Nintendo 64 uses the Vr4300 series of chips from NEC. !!! I've been dethreading this subject line for a few days now, so I'm quite relieved to see this, the one e-mail message which I happened to check in on to make sure that I'm not missing anything. Has anyone invoked Godwin's Law yet? And is anyone recycling the bottle-rockets? :-P Ciao, Sheldon. PS: Yes, there's a comma missing from that first paragraph, but at least there were no split infinitives. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/bin/test test.c
[Hi-jacked out of cvs-committers & cvs-all] On Tue, 17 Aug 1999 17:18:53 MST, Brian Feldman wrote: > green 1999/08/17 17:18:53 PDT > > Modified files: > bin/test test.c > Log: > The new test(1) did not use access() correctly. I don't know why, since > supposedly it's ksh-derived, and it's not broken in pdksh. I've added > a test for test running as root: if testing for -x, the file must be > mode & 0111 to get "success", rather than just existant. > > Reviewed by:chris What were you actually trying to fix, here? I didn't see any discussion of this on hackers, current or bugs, nor in response to my initial commit message. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Change to /sys/net/if.c & /sys/dev/syscons/syscons.c
On Fri, 20 Aug 1999 15:09:59 +0100, Cillian Sharkey wrote: > + log(LOG_INFO, "%s%d: promiscuous mode disabled\n", > + ifp->if_name, ifp->if_unit); You're the second person other than me to request this. :-) So are there any _objections_ to having the kernel match promiscuous "enabled" messages with "disabled" counterparts? Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Change to /sys/net/if.c & /sys/dev/syscons/syscons.c
On Fri, 20 Aug 1999 15:55:45 +0100, Cillian Sharkey wrote: > Maybe..there was a lot of talk on another mailing list (-current I think?) > about boot messages, level of verbosity etc. etc. so perhaps > we should wait until this has been decided.. ? This has nothing to do with the boot messages, though, surely? Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
ls(1) options affecting -l long format
Hi folks, Chris Costello recently committed (and then backed out at my request) a change to ls(1) that made -n (numeric ID's instead of names) imply -l (long format). The OpenGroup Single UNIX Specification is quite clear on the following issue: -g, -n and -o all imply -l. Of course, the OpenGroup spec uses -g for something we don't offer. Our -g is a backward compatibility option. So my point here relates to -n and -o. As I mentioned on the PR associated with the addition of the -n option, taking it to imply -l does nothing but reduce user-interface flexibility. It prevents me from using this in my .profile alias ls='ls -n' to mean "When I ask for a long listing, show numeric ID's instead of names. If I don't ask for a long listing, don't give me one." As far as I'm concerned, we should _not_ be following the OpenGroup spec's mandate on this issue. I think that -o and -n should continue to operate as they do in FreeBSD's and NetBSD's ls, to allow the kind of flexibility suggested above. Ideally, the OpenGroup spec should change. :-) So what's my question? How hard should we be trying to stick to the OpenGroup spec? Whatever we decide should apply to both -n and -o. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: proposed change for /etc/periodic/* scripts
On Mon, 23 Aug 1999 09:59:29 +0100, Cillian Sharkey wrote: > Ideas / Comments / Suggestions ? Diffs ? :-) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: ls(1) options affecting -l long format
On Mon, 23 Aug 1999 01:00:05 MST, "Brian F. Feldman" wrote: > The reason I say it doesn't make sense is that you shouldn't be asking > for a long listing with ls -l if you want numeric ids, you should be > using ls -n. Instead of your alias, you should just be using ls -n > where you'd otherwise use ls -l. That's good enough for me. :-) If there are no objections (other than the obvious backward issue of compatibility) in the next few days, I'll bring Chris's change in (with a style fix), as well as teaching -o to imply -l. I'm not to phased with backward compatibility on this one, since I think it's always been understood that the output of ls isn't really intended for scripts (that's what find and test are for). The OpenGroup spec actually makes a point of that in its manpage. Thanks for your input. Later, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: proposed change for /etc/periodic/* scripts
On Mon, 23 Aug 1999 10:18:40 +0100, Cillian Sharkey wrote: > I haven't actually done any work on this (yet) > but I might see what I can hack together.. > The reason I suggest that you provide diffs first is that it's difficult to comment on your proposal without seeing _how_ and to _what_ extent you want to change things. Diffs will remedy that. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: ls(1) options affecting -l long format
On Mon, 23 Aug 1999 11:36:00 +0200, Sheldon Hearn wrote: > If there are no objections (other than the obvious backward issue of > compatibility) in the next few days, I'll bring Chris's change in (with > a style fix), as well as teaching -o to imply -l. Eeek, I've been confused. Our -o and the OpenGroup spec's -o are completely different. :-) The -n option will imply -l, but -o will be a no-op unless at least one of -n and -l is specified. Manpage changes will be included in the deal. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: ls(1) options affecting -l long format
On Mon, 23 Aug 1999 13:13:14 +0200, Sheldon Hearn wrote: > The -n option will imply -l, but -o will be a no-op unless at least one > of -n and -l is specified. Manpage changes will be included in the deal. The diff for this change is available from: http://www.freebsd.org/~sheldonh/ls.diff.n_implies_l Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: ls(1) options affecting -l long format
On Mon, 23 Aug 1999 14:23:21 +0200, Sheldon Hearn wrote: > > The -n option will imply -l, but -o will be a no-op unless at least one > > of -n and -l is specified. Manpage changes will be included in the deal. I've been playing with the ls(1) that this patch produces and now that I've had some time with it, I can honestly say I really don't like it. i've had trouble formulating an objection beyond "it doesn't feel like UNIX" which is why this mail was delayed. Our ls(1) can not, for the moment, be completely compliant with the OpenGroup Single UNIX Specification. We have at least two BSD-specific options that conflict with OpenGroup spec options. We also have a precedent for options which affect but do not imply a long listing (-o). I believe we should stick with that precedent and leave -n as it is. I think that the small gain of partial OpenGroup compliance does not weigh in heavily enough against the loss of internal consistency the patch introduces into ls(1). I also believe that the OpenGroup spec offers sufficient warning against relying on ls(1) on one platform to behave the same way as ls(1) on another: " Because systems that conform to the Single UNIX Specification, Version " 2 may have extensions, the file modes field in output produced by ls -l " may vary among conforming systems. In particular, certain file types " and executable bits may vary. Applications can pass the information in " this field directly to a user printout or prompt; but instead of taking " actions based on the file modes field, a portable application should " generally use the test utility instead. " " The output of ls with the -l and related options (such as mode and " time information) contains information that logically could be used " by utilities such as chmod and touch to restore files to a known " state. However, this information is presented in a format that cannot be " used directly by those utilities, or be easily translated into a format " that can be used. I've seen correspondance from Garrett Wollman elsewhere, which seemed to indicate that he supports this view. I'd appreciate feedback because, at this stage, I don't think I'll be bringing in this change. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Struct user
On Tue, 24 Aug 1999 12:59:49 -0400, Dan Seguin wrote: > Can somebody tell me where to find the defintion for struct user that's > contained in struct proc? This is trick question, yes? sys/proc.h struct proc sys/user.h struct user :-) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
mkfifo default creation mode 0777
Hi folks, I'm about to add a flag to mkfifo that allows you to specify creation mode. NetBSD does this already. However, there's a difference in the way our mkfifo and NetBSd's mkfifo create files. We create with permissions 0777 modified by umask. NetBSD creates with permissions 0666 modified by umask. I can't see why we use 0777. Would bad things happened if I changed this to 0666 while I'm in there? Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: HEADS UP Reviewers. VFS changes to be committed.
On Thu, 26 Aug 1999 08:28:29 GMT, Alfred Perlstein wrote: > Am I to take it that silence is accpetance? I'll be committing this > to -current tonight or tomorrow unless I get feedback. Recent discussions with bde and eivind indicate that at least some of the code you're about to touch has one or more maintainers. Kirk McKusick is probably one of them. Make sure you contact the maintainers directly before smacking their code. Also, I'd suggest that it's a bad idea to say "if I get no feedback before tonight, I'm committing". I think this applies even if it's not the first time you've asked for review. Basically, timezones and stuff make for a situation where such an e-mail is useless for many of your readers. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: df and procfs
On Thu, 26 Aug 1999 18:21:43 +0200, Neil Blakey-Milner wrote: > > (The man page seems to be in error, though, when it says that "sysctl > > vfs" tells what kinds of filesystems are available.) > > lsvfs should give a good indication. My dog! You learn something new every day. :-) Thanks, Sheldon. Index: df.1 === RCS file: /home/ncvs/src/bin/df/df.1,v retrieving revision 1.14 diff -u -d -r1.14 df.1 --- df.11999/02/12 02:12:06 1.14 +++ df.11999/08/26 16:40:49 @@ -95,12 +95,9 @@ and .Tn MFS . The -.Xr sysctl 8 +.Xr lsvfs 1 command can be used to find out the types of filesystems -that are available on the system: -.Bd -literal -offset indent -sysctl vfs -.Ed +that are available on the system. .El .Sh ENVIRONMENT .Bl -tag -width BLOCKSIZE @@ -116,6 +113,7 @@ .Fl t flags are ignored if a file or filesystem is specified. .Sh SEE ALSO +.Xr lsvfs 1 , .Xr quota 1 , .Xr fstatfs 2 , .Xr getfsstat 2 , @@ -123,8 +121,7 @@ .Xr getmntinfo 3 , .Xr fstab 5 , .Xr mount 8 , -.Xr quot 8 , -.Xr sysctl 8 +.Xr quot 8 .Sh HISTORY A .Nm To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: HEADS UP Reviewers. VFS changes to be committed.
On Thu, 26 Aug 1999 11:45:47 -0400, Bill Fumerola wrote: > This would be post #3 of the same code and changes that no-one has > reponded to. I hear you, and I was aware of that when I made my comments. Basically, it's a waste of time saying such a thing, so either be prepared to wait longer, or don't say it. :-) Feelings, nothing more than feelings... Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
REQ: Help with apparently impossible error in Makefile.inc1
Hi folks,
While testing out a change I'm proposing for src/Makefile.inc1 (see my
PR 13398, which proposes the addition of a WHICH_GAMES knob), I've hit
my head against something I can't figure out.
Basically, I have the following in Makefile.inc1:
| .if !defined(NOGAMES) && exists(${.CURDIR}/games)
| cd ${DESTDIR}/usr/games
| .if !empty(WHICH_GAMES:Mcaesar)
| cp -p caesar ${DESTDIR}/usr/bin
| .endif
| .if !empty(WHICH_GAMES:Mfortune)
| cp -p strfile ${DESTDIR}/usr/bin
| .endif
| .endif
I get the following error during buildworld:
| cd /usr/obj/usr/src/tmp/usr/games
| cp -p caesar /usr/obj/usr/src/tmp/usr/bin
| cp: caesar: No such file or directory
| *** Error code 1
However, the file caesar definitely exists in the directory
/usr/obj/usr/src/tmp/usr/games and when I go into that directory and
issue the offending command manually, it succeeds!
Help. :-)
Ciao,
Sheldon.
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: REQ: Help with apparently impossible error in Makefile.inc1
On Fri, 27 Aug 1999 08:06:29 -0400, Garance A Drosihn wrote: > Each line that 'make' executes is executed in it's own environment, Forgive me father, I am but a worm. *lick* Thanks, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Please review: rc file changes
Hi folks,
What follows is a diff that presents Doug's changes (which must have
required quite a bit of effort, thanks!) in a slightly different format
which I think the grumpies here might prefer.
Specifically, case statements look more like what a lot of folks are
used to seeing, and conditionals that don't need to be case sensitive
have not been converted to case statements.
I think the effort which Doug has put into this is great and would make
for a better rc. It's a pity that a few cosmetic issues generated so
much pooh-pooh'ing. :-(
Ciao,
Sheldon.
Index: rc
===
RCS file: /home/ncvs/src/etc/rc,v
retrieving revision 1.194
diff -u -d -r1.194 rc
--- rc 1999/08/25 16:01:33 1.194
+++ rc 1999/08/27 12:26:46
@@ -8,24 +8,25 @@
# and the console is the controlling terminal.
# Note that almost all the user-configurable behavior is no longer in
-# this file, but rather in /etc/defaults/rc.conf. Please check this file
+# this file, but rather in /etc/defaults/rc.conf. Please check that file
# first before contemplating any changes here.
stty status '^T'
# Set shell to ignore SIGINT (2), but not children;
# shell catches SIGQUIT (3) and returns to single user after fsck.
+#
trap : 2
trap : 3 # shouldn't be needed
-HOME=/; export HOME
+HOME=/
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin
-export PATH
+export HOME PATH
# BOOTP diskless boot. We have to run the rc file early in order to
# retarget various config files.
#
-if [ -f /etc/rc.diskless1 ]; then
+if [ -r /etc/rc.diskless1 ]; then
dlv=`/sbin/sysctl -n vfs.nfs.diskless_valid 2> /dev/null`
if [ ${dlv:=0} != 0 ]; then
. /etc/rc.diskless1
@@ -34,22 +35,28 @@
# If there is a global system configuration file, suck it in.
#
-if [ -f /etc/defaults/rc.conf ]; then
+if [ -r /etc/defaults/rc.conf ]; then
. /etc/defaults/rc.conf
-elif [ -f /etc/rc.conf ]; then
+elif [ -r /etc/rc.conf ]; then
. /etc/rc.conf
fi
# Configure ccd devices.
-if [ -f /etc/ccd.conf ]; then
+#
+if [ -r /etc/ccd.conf ]; then
ccdconfig -C
fi
-if [ "${start_vinum}" = "YES" ]; then
+case ${start_vinum} in
+[Yy][Ee][Ss])
vinum start
-elif [ -n "${vinum_drives}" ]; then
- vinum read ${vinum_drives}
-fi
+ ;;
+*)
+ if [ -n "${vinum_drives}" ]; then
+ vinum read ${vinum_drives}
+ fi
+ ;;
+esac
swapon -a
@@ -94,35 +101,39 @@
# root normally must be read/write, but if this is a BOOTP NFS
# diskless boot it does not have to be.
#
-
-if [ "${root_rw_mount}" != "NO" ]; then
+case ${root_rw_mount} in
+[Nn][Oo])
+ ;;
+*)
mount -u -o rw /
-fi
+ ;;
+esac
if [ $? != 0 ]; then
echo "Filesystem mount failed, startup aborted"
+ echo "Mounting root filesystem rw failed, startup aborted"
exit 1
fi
umount -a >/dev/null 2>&1
-if [ "${early_nfs_mounts}" != "YES" ]; then
- mount -a -t nonfs
-else
+case ${early_nfs_mounts} in
+[Yy][Ee][Ss])
mount -a
-fi
+ ;;
+*)
+ mount -a -t nonfs
+ ;;
+esac
if [ $? != 0 ]; then
- echo "Filesystem mount failed, startup aborted"
+ echo "Mounting /etc/fstab filesystems failed, startup aborted"
exit 1
fi
# Run custom disk mounting function here
#
-
-if [ -n "${diskless_mount}" ]; then
- if [ -f "${diskless_mount}" ]; then
- sh ${diskless_mount}
- fi
+if [ -n "${diskless_mount}" -a -r "${diskless_mount}" ]; then
+ sh ${diskless_mount}
fi
adjkerntz -i
@@ -148,46 +159,64 @@
fi
# Add additional swapfile, if configured.
-if [ "${swapfile}" != "NO" -a -w "${swapfile}" -a -b /dev/vn0b ]; then
- echo "Adding ${swapfile} as additional swap."
- vnconfig /dev/vn0b ${swapfile} && swapon /dev/vn0b
-fi
+#
+case ${swapfile} in
+[Nn][Oo])
+ ;;
+*)
+ if [ -w "${swapfile}" -a -b /dev/vn0b ]; then
+ echo "Adding ${swapfile} as additional swap."
+ vnconfig /dev/vn0b ${swapfile} && swapon /dev/vn0b
+ fi
+ ;;
+esac
-# set sysctl variables early as we can
-if [ -f /etc/rc.sysctl ]; then
+# Set sysctl variables as early as we can
+#
+if [ -r /etc/rc.sysctl ]; then
. /etc/rc.sysctl
fi
-# configure serial devices
-if [ -f /etc/rc.serial ]; then
+# Configure serial devices
+#
+if [ -r /etc/rc.serial ]; then
. /etc/rc.serial
fi
-# start up PC-card configuration
-if [ -f /etc/rc.pccard ]; then
+# Start up PC-card configuration
+#
+if [ -r /etc/rc.pccard ]; then
. /etc/rc.pccard
fi
-# start up the initial network configuration.
-if [ -f /etc/rc.network ]; then
+# Start up the initial network configuration.
+#
+if [ -r /etc/rc.network ]; then
. /etc/rc.network # We only need to do this once.
network_pass1
fi
-echo -n "Mounting NFS file systems"
-mount -a -t nfs
-echo .
+case ${early_nfs_mounts} in
+[Yy][Ee][Ss])
+ ;
Re: Please review: rc file changes
On Sun, 29 Aug 1999 12:40:20 +0200, Leif Neland wrote:
> if isyes ${thisvariable}
>
> case $1 of
> [Yy][Ee][Ss])
> exit 0
> ;;
> *)
> exit 1
> ;;
> esac
I hope you mean "in" instead of "of" and "return" instead of "exit". :-)
I like this. One of the reasons I like it so much is because it will
make Doug's changes more friendly towards a future migration to a new
case-insensitive test(1) comparison (or even better, new case-handling
sh(1) variable expansions) easier.
Ciao,
Sheldon.
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: Please review: rc file changes
On Sat, 28 Aug 1999 16:46:11 MST, Doug wrote:
> Hoping I'm running out of nits,
:-)
Hi Doug,
I've had a week-end away from a keyboard to think about this. The only
reason we have to use case statements for case-insensitive variable
testing is because sh(1) doesn't offer any upper/lower case handling
parameter expansions (something like ${foo~lower} for example).
When sh(1) _does_ offer something like this, a lot more work will be
involved in using it once your proposed changes have gone in.
Therefore, I propose that we create functions isyes() and isno() to wrap
up the case-handling logic. This means we end up using
if isyes(${foo}); then
...
fi
Later, when upper/lower case handling is available, we could either
change the internals of the isyes() and isno() functions, or replace
their invocations with
case ${foo~lower} in
yes)
...
;;
*)
...
;;
esac
Wotchathink?
Ciao,
Sheldon.
PS: I just finished off rc.network; what a bitch. :-)
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: More than 32 signals. Thought?
On Mon, 30 Aug 1999 15:55:56 +0200, Marcel Moolenaar wrote: > The Linux trick I like to add is to have sigset_t always be the last > field in structures so that the impact of enlarging sigset_t is > minimal. On LITTLE_ENDIAN machines? Cia, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: More than 32 signals. Thought?
On Mon, 30 Aug 1999 12:26:06 CST, Warner Losh wrote: > : On LITTLE_ENDIAN machines? > > Endian shouldn't matter. Yup, it was the kind of stupid comment someone who doesn't actually know what's going on would make. ;-) I hadn't cottoned on to the notion of using an array. Thanks, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
