Re: new certificate stuff
I'm trying to make sure this will provide a seamless fresh install and upgrade path so that if you were already managing /etc/openssl/certs, it stays that way, but if you weren't, certctl(8) takes over and makes the Mozilla trust anchors available. And I'd like to get this into 10 ASAP. Sounds good. Just one last question: If I migrate to this new world order (ie, I delete existing package and clean out the /etc/openssl/certs directory), what happens to any packages that currently depend on mozilla-rootcerts? Will they somehow magically not need to install the mozilla-rootcerts package? ++--+------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
new certificate stuff
OK, I tried to read and understand the thread, but not really sure I succeeded with the understanding part. (In fact, i'm pretty sure I failed that part, miserably.) I've got a simple set-up here, running postfix and pine for Email, and of course f-fox for browsing. I've never done anything (at least, not deliberately) with certificates; reading and writing Email just works, as does most browsing. Will I need to do anything new (or differently) as a result of these recent changes? ++--+------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
Re: Proposed chown(8)/chgrp(1) enhancement
On Sat, 29 Apr 2023, ?? wrote:
On Fri, Apr 28, 2023 at 11:25:03PM +, RVP wrote:
On Fri, 28 Apr 2023, Paul Goyette wrote:
I propose the attached enhancement to chown/chgrp to avoid setting
a new user/group value if the desired values are already set. The
change is pretty simple.
I don't think we need a flag for this. I think what you're proposing
should just be the default behaviour.
It probably shouldn't, since chown/chgrp clear SUID/SGID;
this change, as written, both (a) violates POSIX by no longer behaving
as-if XCU chown ran XSH chown(), and hence (b) changes existing behaviour.
OTOH if you add a
&& !(p->fts_statp->st_mode & 07000)
then that's probably fine.
Yeah, although it would be better to do the mode check only if chown
is NOT being executed by super-user (the SxID bits are not modified if
running as root). Unfortunately the program doesn't (currently) know
if it is running as root or as some other user.
I've update my local copy of the to be
...
if (dflag &&
( -1 == uid || p->fts_statp->st_uid == uid ) &&
( -1 == gid || p->fts_statp->st_gid == gid ) &&
( p->fts_statp->st_mode && 07000 ) == 0))
continue;
...
++--+--+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:|
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com|
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
| & Network Engineer | | pgoyett...@gmail.com |
++--+--+
Proposed chown(8)/chgrp(1) enhancement
Seems to me that a recursive chown/chgrp, in a large directory with
_most_but_not_all files already set to the desired owner/group, can
be rather wastefull. As near as I can tell, the kernel is called
for every file, even those for whom the update of attributes is
effectively a no-op. Further, these no-op calls apparently trigger
other non-updates to the filesystem whjich can affect files' mtime
and/or atime.
(FWIW, I frequently end up with such a directory when a CVS update
picks up a new file and I forgot to su(8) to the owner's UID first!
The new files get my current owner uid while all the other files
are owned by someone else.)
I propose the attached enhancement to chown/chgrp to avoid setting
a new user/group value if the desired values are already set. The
change is pretty simple.
Note that this change also modifies the changes that might be made
to a file's setuid/setgid mode bits. Current code simply clears the
bits for every file, whether or not the user/group is really being
updated. The attached patch only clears the bits if the user/group
is also being _changed_ from its current value.
Comments? Useful? Suggestions? Should I commit?
++--+------+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:|
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com|
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
| & Network Engineer | | pgoyett...@gmail.com |
++--+--+Index: chgrp.1
===
RCS file: /cvsroot/src/sbin/chown/chgrp.1,v
retrieving revision 1.8
diff -u -p -r1.8 chgrp.1
--- chgrp.1 4 Jul 2017 06:52:20 - 1.8
+++ chgrp.1 28 Apr 2023 19:01:05 -
@@ -31,7 +31,7 @@
.\" from: @(#)chgrp.1 8.3 (Berkeley) 3/31/94
.\"$NetBSD: chgrp.1,v 1.8 2017/07/04 06:52:20 wiz Exp $
.\"
-.Dd October 22, 2012
+.Dd May 1, 2023
.Dt CHGRP 1
.Os
.Sh NAME
@@ -86,6 +86,9 @@ option is specified, no symbolic links a
.It Fl R
Change the group ID for the file hierarchies rooted
in the files instead of just the files themselves.
+.It Fl d
+Do not attempt to update a file's group if it is already set to the
+desired value.
.It Fl f
The force option ignores errors, except for usage errors and doesn't
query about strange modes (unless the user does not have proper permissions).
@@ -164,6 +167,8 @@ utility is expected to be POSIX 1003.2 c
.Pp
The
.Fl v
-option and the use of ``#'' to force a numeric group ID
+and
+.Fl d
+options and the use of ``#'' to force a numeric group ID
are extensions to
.St -p1003.2 .
Index: chown.8
===
RCS file: /cvsroot/src/sbin/chown/chown.8,v
retrieving revision 1.12
diff -u -p -r1.12 chown.8
--- chown.8 4 Jul 2017 06:53:12 - 1.12
+++ chown.8 28 Apr 2023 19:01:05 -
@@ -28,7 +28,7 @@
.\" from: @(#)chown.8 8.3 (Berkeley) 3/31/94
.\"$NetBSD: chown.8,v 1.12 2017/07/04 06:53:12 wiz Exp $
.\"
-.Dd September 11, 2016
+.Dd May 1, 2023
.Dt CHOWN 8
.Os
.Sh NAME
@@ -84,6 +84,9 @@ option is specified, no symbolic links a
.It Fl R
Change the user ID and/or the group ID for the file hierarchies rooted
in the files instead of just the files themselves.
+.It Fl d
+Do not attempt to update a file's owner or group if it is already
+set to the desired value.
.It Fl f
Do not report any failure to change file owner or group, nor modify
the exit status to reflect such failures.
@@ -174,7 +177,9 @@ command is expected to be POSIX 1003.2 c
.Pp
The
.Fl v
-option and the use of ``#'' to force a numeric lookup
+and
+.Fl d
+options and the use of ``#'' to force a numeric lookup
are extensions to
.St -p1003.2 .
.Sh HISTORY
Index: chown.c
===
RCS file: /cvsroot/src/sbin/chown/chown.c,v
retrieving revision 1.9
diff -u -p -r1.9 chown.c
--- chown.c 28 Apr 2023 09:56:45 - 1.9
+++ chown.c 28 Apr 2023 19:01:05 -
@@ -82,7 +82,7 @@ main(int argc, char **argv)
{
FTS *ftsp;
FTSENT *p;
- int Hflag, Lflag, Rflag, ch, fflag, fts_options, hflag, rval, vflag;
+ int Hflag, Lflag, Rflag, ch, fflag, fts_options, hflag, rval, vflag,
dflag;
char *cp, *reference;
int (*change_owner)(const char *, uid_t, gid_t);
@@ -94,13 +94,16 @@ main(int argc, char **argv)
ischown = (myname[2] == 'o');
reference = NULL;
- Hflag = Lflag = Rflag = fflag = hflag = vflag = 0;
- while ((ch = getopt_long(argc, argv, "HLPRfhv",
+ Hflag = Lflag = Rflag = fflag = hflag = vflag = dflag = 0;
+ while ((ch = getopt
Re: style(5) proposal: forbid extern in .c
On Wed, 15 Mar 2023, Taylor R Campbell wrote: Proposal: Forbid extern declarations in .c files. extern declarations in .c files invite easily avoided bugs where the definition and use have mismatched types, because the compiler doesn't have an opportunity to check them. Fix: Always put the extern declaration in a .h file shared by the .c file defining it and the .c files using it. Pretty simple. Any objections? Long overdue IMHO. Go for it. ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
Re: /rescue/tar needing liblzma.so.2
On Mon, 4 Jul 2022, Martin Husemann wrote: On Mon, Jul 04, 2022 at 06:58:39PM +, Emmanuel Dreyfus wrote: On Mon, Jul 04, 2022 at 08:32:02PM +0200, Martin Husemann wrote: Try with PATH=/rescue, that should avoid the issue. Shouldn't /rescue binaries have /rescue prepended to their PATH? Tricky - isn't that too much magic? Yeah, too much magic indeed. We could have the /rescue/sh default to /rescue/.profile or something and arrange good "rescue defaults" there. That sounds like it should be workable. ++--+------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
Re: ZFS - mounting filesystems (Was CVS commit: src/etc)
On Mon, 14 Mar 2022, Taylor R Campbell wrote: Date: Mon, 14 Mar 2022 08:01:53 -0700 (PDT) From: Paul Goyette On Tue, 15 Mar 2022, Simon Burge wrote: Do we have any valid need to have non-critical local filesystems? Well, I have a dedicated filesystem for builds, separate from my OS. The /build happens to be my nvme SSD. Building (or being able to build) is not critical to having the machine running (and receiving mail). So, yeah, I think non-critical local filesystems are meaningful. But critical vs non-critical is just a question of ordering at boot. Do you have rc.d scripts that have to run some time between mountcritremote and mountall, for which it matters to defer mounting some file systems until mountall? If yes, why? No, I have no odering requirements. If that's all we get from the word "critical" then I humbly request we change the word! (Separately, there's `noauto' in fstab if you don't want the file system to be mounted automatically at boot.) But there is no "if-you-can" option in fstab. :0 I want it to be mounted if possible, but do not abort if not possible. ++------+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
Re: ZFS - mounting filesystems (Was CVS commit: src/etc)
On Tue, 15 Mar 2022, Simon Burge wrote: Do we have any valid need to have non-critical local filesystems? Well, I have a dedicated filesystem for builds, separate from my OS. The /build happens to be my nvme SSD. Building (or being able to build) is not critical to having the machine running (and receiving mail). So, yeah, I think non-critical local filesystems are meaningful. FWIW, I cannot spell zfs! :) ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
Re: draft mcount(3) man page
On Sat, 22 May 2021, David Holland wrote: To cut down on future confusion we should probably (if it's not excessively expensive for some reason) change all the compiler configs to call "__mcount_hook" and change the name of the C function to always be "__mcount_impl" or "__mcount_backend" or something like that. Having both _mcount and __mcount is terrible, especially when their roles are exchanged on ~half the ports we have. Yeah, this really is begging for a clean-up. ++------+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Importing aiomixer to src
On May 6, 2021, at 6:44 AM, nia wrote: I think this version is suitable for importing into NetBSD base for continued development. This will also allow us to easily keep it in sync if there are any changes to the audio stack. I've historically kept a Windoze machine around, just so I can handle audio. I just never was able to figure out how to "do audio" on NetBSD. So, anything that improves the interface for those of us who really want a "black box" (vs having to know what all the pieces are, and how they all fit together) is a great improvement. PLEASE! Go for it! :) ++--+-------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Waiting for Randot (or: nia and maya were right and I was wrong)
On Fri, 15 Jan 2021, Reinoud Zandijk wrote: On Fri, Jan 15, 2021 at 03:10:20PM +0100, Martin Husemann wrote: On Fri, Jan 15, 2021 at 03:04:21PM +0100, Reinoud Zandijk wrote: Can we create a random stream for all such situations instead of a file? Say open a TCP/IP connection to some NetBSD server that spits out a X number of random bytes by its random generator and then closes the stream? You want this to happen on the *local* network. Well no, on install, open a tcp connection to a TNF hosted server... Assuming you can trust the host _and_ the path to it hasn't been compromised... ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: inetd Enhancements
On Sun, 22 Nov 2020, Mouse wrote: I think that would be another disaster. I would look for a design that supports the flexibility without invalidating old files and without so much fluff, or at least without *requiring* so much fluff. Changing the file format also concerns me. It is entirely possible that some add-on software (such as is found in NetBSD's pkgsrc) will either directly modify inetd.conf or provide users with instructions to make modifications. You started off speaking of being unintrusive. I find it hard to see how changing the config file syntax so as to invalidate existing configurations could possibly be considered unintrusive. Changing the syntax is indeed extremely intrusive. ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Proposal to remove catman(8)
On Tue, 10 Nov 2020, Kamil Rytarowski wrote: It's not a selling point to any regular user, born after A.D. 2000 to optimize reading man pages. Whoa there. Don't put down us older folks. And why would you want to characterize "regular user" as being "not yet two decades old" ? ++--+-------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: style change: explicitly permit braces for single statements
if (ch == t.c_cc[VINTR]) {
...do INTR processing...
} else {
if (ch == t.c_cc[VQUIT]) {
...do QUIT processing...
} else {
if (ch == t.c_cc[VKILL]) {
...do KILL processing...
} else {
...etc
}
}
}
For this, I would prefer
if (ch == t.c_cc[VINTR]) {
...do INTR processing...
} else if (ch == t.c_cc[VQUIT]) {
...do QUIT processing...
} else if (ch == t.c_cc[VKILL]) {
...do KILL processing...
} else {
...etc
}
In this case, perhaps even a switch might better, assuming that all of
the t_c.cc[] are unique:
switch (ch) {
case t.c_cc[VINTR]) {
...do INTR processing...
break;
};
case t.c_cc[VQUIT]) {
...do QUIT processing...
break;
}
case t.c_cc[VKILL]) {
...do KILL processing...
break;
}
...etc
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
Re: style change: explicitly permit braces for single statements
On Sun, 12 Jul 2020, Valery Ushakov wrote:
Luke Mewburn wrote:
I propose that the NetBSD C style guide in to /usr/share/misc/style
is reworded to more explicitly permit braces around single statements,
instead of the current discourgement.
IMHO, permitting braces to be consistently used:
- Adds to clarity of intent.
- Aids code review.
- Avoids gotofail: https://en.wikipedia.org/wiki/Unreachable_code#goto_fail_bug
Yes, please.
My primary reason to prefer them is minimizing diffs when you do need
to add another statement. If the OTBS opening brace is already there
then you don't need to spend any mental effort on parsing:
- if (complex condition full of alphabet soup and punctuation)
+ if (complex condition full of alphabet suop and punctuation) {
to check whether the condition was changed or if it's just the brace.
Another +1 here. The "add another statement" is frequently "add a
debug_printf()" and many is the time i've broken an if statement by
adding debug code.
++------+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
Re: Empty lines in output of cal(1)
On Mon, 29 Jun 2020, Kimmo Suominen wrote: On Mon, Jun 29, 2020 at 11:29:10AM -0700, Paul Goyette wrote: Also note that when using ``cal -r'' it still displays 5 lines of output, even though only 3 (or 4) lines contain any day-numbers. This results in somewhat excessive vertical white-spacing. When outputting a full year (and possibly in other cases where more than one "row" of months is output) the fixed number of display lines per month looks more pleasing to the eye, I think. But in the single "row" case it would probably be fine to suppress the empty lines. It would seem unlikely that anything depends on the fixed number of output lines. What do you think? https://www.netbsd.org/~kim/cal-suppress-empty-output-lines.diff It really doesn't matter much to me. But if it is supposed to be "bit-for-bit compatable" with something else, maybe it's best not to mess with it any more. :) ++------+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Weekday abbreviations in output of cal(1)
Also note that when using ``cal -r'' it still displays 5 lines of output, even though only 3 (or 4) lines contain any day-numbers. This results in somewhat excessive vertical white-spacing. :) # cal -r September 1752 S M Tu W Th F S 1 2 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 # cal June 2020 S M Tu W Th F S 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 # On Mon, 29 Jun 2020, Valery Ushakov wrote: Michael Siegel wrote: So, in the output of NetBSD's cal(1), days are abbreviated with one letter, except for Tuesday and Thursday. I'd say this is: * inconsistent * potentially misleading (Saturday and Sunday are both just "S".) * unnecessarily cryptic [...] So, I'd say that, maybe, changing cal(1) in NetBSD to use two-letter abbreviations throughout as well would also be a good thing concerning compatibility with what other (widely-used) Unix-like operating systems do. No objections, but just for context/perspective/pedantry/... :) 2.11 BSD UNIX #1: Fri Jun 9 08:42:54 PDT 1995 root@SSU-64EN137:/usr/src/sys/SYSTEM [...] erase, kill ^U, intr ^C # cal usage: cal [month] year # cal 1 72 January 72 S M Tu W Th F S 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 # -uwe !DSPAM:5efa336781460411656! ++------+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: getrandom and getentropy
On Mon, 11 May 2020, Michael van Elst wrote: We only trust a HWRNG and the seed file because only these enter a non-zero value for entropy. I cannot configure any other source to do that. Why can't we allow the user to configure/enable estimation on a per-source basis? The default can certainly be "disabled", but why not override? Just like any other super-user thing, there's no reason not to enable shoot-my-random-foot mode. ++--+-------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: dhcpcd privilege separation user
On Thu, 23 Jan 2020, r...@reedmedia.net wrote: On Thu, 23 Jan 2020, Roy Marples wrote: dhcpcd-9 is almost ready for release and the big feature for it is privilege separation. The question is which system user should it use on NetBSD? Other BSD's have the _dhcp user - which shares DHCP serving on OpenBSD at least. Is this to generic and we should have a _dhcpcd user or is _dhcp satisfactory? Separate dedicated user. +1 ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: pthread_setname_np API is bad
On Fri, 9 Aug 2019, Christos Zoulas wrote: I think we should do something right now (even for NetBSD-9) to avoid causing pain upstream. Even the variadic change is an improvement. I was just arguing that if we were going to make the change, let's go all the way and fix it properly, but if people feel that there is a chance for upstream to adopt the printflike setname_np() (I don't), let's go for it. Agreed on both points: * Fix ASAP (now) * It seems unlikely for upstream to adopt our current API christos On Aug 9, 2019, at 7:11 PM, Kamil Rytarowski wrote: On 09.08.2019 17:47, Christos Zoulas wrote: I understand that I am using contrived examples. I am just pointing out that we don't usually implement APIs that work 99.% of the time when we can implement ones that work 100% of the time. It is not worth risking problems. You can always provide and use enhanced ones, but that causes non-portable software. Code that uses pthread_setname_np(t, "thread%d", 1) will work on NetBSD and not compile on Linux the same way code that uses pthread_fmtname_np(t, "thread%d", 1) will... Except that it will be obvious that pthread_fmtname_np() is a function that NetBSD has and Linux does not as opposed to an incompatibility in the implementation of pthread_setname_np(), which will cause the user of the function to try to figure out who's right and how to fix it. It was a mistake to provide an incompatible pthread_setname_np() in the first place, let's fix it properly instead of adding a most excellent band-aid. My only reason for my proposal was to keep API compat with the current users, however we can switch to the Linux API. I still think that these 0.1% of cases where it would be broken are in theory, not in practice.. but we can go for it. I will insist on an intermediate step here before any code changes in libpthread(3). I propose to try to push the Linux version to POSIX and in case of seeing it rejected, adapt the Linux version as is. All currently relevent POSIX-like OSs already support one or the other _np() variation. There is no pressure for a change to do it now, soon or for NetBSD 9.0 and waiting some weeks/months is fine. If it will land NetBSD 10.0, there will be no harm. !DSPAM:5d4da392153981598017751! ++------+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: find and limits
The problem is that it's trying to install a file on top of itself! Because it found a file in the work dir On Sat, 6 Apr 2019, co...@sdf.org wrote: On Sat, Apr 06, 2019 at 03:18:10PM +0700, Robert Elz wrote: Date:Sat, 6 Apr 2019 07:02:34 + From:co...@sdf.org Message-ID: <20190406070234.ga5...@sdf.org> | Thanks. I committed that. | I'm slightly horrified by this being the problem. I hope it was tested ... I don't often install fonts. As I said while it looked to be doing the wrong thing, I cannot explain the mechanism by which it caused a write error in install (doesn't help that I am not sure where the sources for that command live!) kre The command failing is, for urbanrenewal-ttf, $ make patch $ mkdir -p work/.destdir/usr/pkg/share/fonts/X11/TTF/ $ install work/Athene.ttf work/.destdir/usr/pkg/share/fonts/X11/TTF/ $ install work/.destdir/usr/pkg/share/fonts/X11/TTF/Athene.ttf work/.destdir/usr/pkg/share/fonts/X11/TTF/ install: work/.destdir/usr/pkg/share/fonts/X11/TTF//Athene.ttf: write: Invalid argument fonts.mk is a few days old :-) no worries of breaking a lot of stuff. !DSPAM:5ca863ca52041784745129! ++--+-------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Detecting keypress on console
On Fri, 29 Mar 2019, Paul Goyette wrote:
On Fri, 29 Mar 2019, Michael van Elst wrote:
On Fri, Mar 29, 2019 at 08:39:24AM +0800, Paul Goyette wrote:
Hmmm. On my amd64 8.99.35 system, I get
# wsmuxctl -f /dev/wsmux1 -l
wskbd0
Segmentation fault (core dumped)
Someone added a WSMUX_BELL device but forgot to support it in wsmuxctl.
The devnames array in wsmuxctl needs to be extended. Please try:
Index: wsmuxctl.c
===
RCS file: /cvsroot/src/usr.sbin/wsmuxctl/wsmuxctl.c,v
retrieving revision 1.12
diff -p -u -r1.12 wsmuxctl.c
--- wsmuxctl.c 3 Feb 2019 03:19:31 - 1.12
+++ wsmuxctl.c 29 Mar 2019 05:55:28 -
@@ -45,7 +45,7 @@ __dead static void usage(void);
static const char *ctlpath = "/dev/wsmuxctl";
-static const char *devnames[] = { "?", "wsmouse", "wskbd", "wsmux" };
+static const char *devnames[] = { "?", "wsmouse", "wskbd", "wsmux",
"wsbell" };
static void
usage(void)
Yup - I can confirm that with this change the segfault no longer occurs!
Thanks for the quick info - and please go ahead and commit (with an
appropriate KNF avoidance of >80char lines).
Never mind - I will commit, along with an error check to make sure we
don't run off the end of the array in the future!
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
Re: Detecting keypress on console
On Fri, 29 Mar 2019, Michael van Elst wrote:
On Fri, Mar 29, 2019 at 08:39:24AM +0800, Paul Goyette wrote:
Hmmm. On my amd64 8.99.35 system, I get
# wsmuxctl -f /dev/wsmux1 -l
wskbd0
Segmentation fault (core dumped)
Someone added a WSMUX_BELL device but forgot to support it in wsmuxctl.
The devnames array in wsmuxctl needs to be extended. Please try:
Index: wsmuxctl.c
===
RCS file: /cvsroot/src/usr.sbin/wsmuxctl/wsmuxctl.c,v
retrieving revision 1.12
diff -p -u -r1.12 wsmuxctl.c
--- wsmuxctl.c 3 Feb 2019 03:19:31 - 1.12
+++ wsmuxctl.c 29 Mar 2019 05:55:28 -
@@ -45,7 +45,7 @@ __dead static void usage(void);
static const char *ctlpath = "/dev/wsmuxctl";
-static const char *devnames[] = { "?", "wsmouse", "wskbd", "wsmux" };
+static const char *devnames[] = { "?", "wsmouse", "wskbd", "wsmux", "wsbell" };
static void
usage(void)
Yup - I can confirm that with this change the segfault no longer occurs!
Thanks for the quick info - and please go ahead and commit (with an
appropriate KNF avoidance of >80char lines).
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
Re: Detecting keypress on console
On Fri, 29 Mar 2019, Paul Goyette wrote: Hmmm. On my amd64 8.99.35 system, I get # wsmuxctl -f /dev/wsmux1 -l wskbd0 Segmentation fault (core dumped) According to my dmesg, I should also have wsbell0 at spkr0 mux 1 listed for mux1... # gdb /usr/sbin/wsmuxctl ... Reading symbols from /usr/sbin/wsmuxctl...Reading symbols from /usr/libdata/debug//usr/sbin/wsmuxctl.debug...done. done. (gdb) target core wsmuxctl.core [New process 1] Core was generated by `wsmuxctl'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x7e2763d92ae1 in strlen () from /usr/lib/libc.so.12 (gdb) bt #0 0x7e2763d92ae1 in strlen () from /usr/lib/libc.so.12 #1 0x7e2763d71bcf in __vfprintf_unlocked_l ( fp=fp@entry=0x7e2763ffe3d8 <__sF+152>, loc=, fmt0=fmt0@entry=0x196801365 "%*s%s%d\n", ap=ap@entry=0x7f7fffdb2388) at /build/netbsd-local/src_ro/lib/libc/stdio/vfwprintf.c:1373 #2 0x7e2763d733ff in vfprintf (fp=0x7e2763ffe3d8 <__sF+152>, fmt0=0x196801365 "%*s%s%d\n", ap=ap@entry=0x7f7fffdb2388) at /build/netbsd-local/src_ro/lib/libc/stdio/vfwprintf.c:555 #3 0x7e2763d6d01b in printf (fmt=) at /build/netbsd-local/src_ro/lib/libc/stdio/printf.c:59 #4 0x000196800f7a in listdevs (fd=, rec=0, ind=0) at /build/netbsd-local/src_ro/usr.sbin/wsmuxctl/wsmuxctl.c:87 #5 0x0001968011b7 in main (argc=, argv=) at /build/netbsd-local/src_ro/usr.sbin/wsmuxctl/wsmuxctl.c:165 (gdb) On Fri, 29 Mar 2019, Michael van Elst wrote: On Thu, Mar 28, 2019 at 04:33:00PM +, Emmanuel Dreyfus wrote: On Thu, Mar 28, 2019 at 02:41:08PM -, Michael van Elst wrote: Maybe /dev/wsmux1 ? wsmux0 is mouse input. Same fate. Is it expect behavior that muxctl -f $i -l lists nothing for any $i ? % sudo wsmuxctl -f /dev/wsmux1 -l wskbd0 Greetings, -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree." !DSPAM:5c9d63cc207191150611282! ++----------+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+ ++----------+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Detecting keypress on console
Hmmm. On my amd64 8.99.35 system, I get # wsmuxctl -f /dev/wsmux1 -l wskbd0 Segmentation fault (core dumped) # gdb /usr/sbin/wsmuxctl ... Reading symbols from /usr/sbin/wsmuxctl...Reading symbols from /usr/libdata/debug//usr/sbin/wsmuxctl.debug...done. done. (gdb) target core wsmuxctl.core [New process 1] Core was generated by `wsmuxctl'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x7e2763d92ae1 in strlen () from /usr/lib/libc.so.12 (gdb) bt #0 0x7e2763d92ae1 in strlen () from /usr/lib/libc.so.12 #1 0x7e2763d71bcf in __vfprintf_unlocked_l ( fp=fp@entry=0x7e2763ffe3d8 <__sF+152>, loc=, fmt0=fmt0@entry=0x196801365 "%*s%s%d\n", ap=ap@entry=0x7f7fffdb2388) at /build/netbsd-local/src_ro/lib/libc/stdio/vfwprintf.c:1373 #2 0x7e2763d733ff in vfprintf (fp=0x7e2763ffe3d8 <__sF+152>, fmt0=0x196801365 "%*s%s%d\n", ap=ap@entry=0x7f7fffdb2388) at /build/netbsd-local/src_ro/lib/libc/stdio/vfwprintf.c:555 #3 0x7e2763d6d01b in printf (fmt=) at /build/netbsd-local/src_ro/lib/libc/stdio/printf.c:59 #4 0x000196800f7a in listdevs (fd=, rec=0, ind=0) at /build/netbsd-local/src_ro/usr.sbin/wsmuxctl/wsmuxctl.c:87 #5 0x0001968011b7 in main (argc=, argv=) at /build/netbsd-local/src_ro/usr.sbin/wsmuxctl/wsmuxctl.c:165 (gdb) On Fri, 29 Mar 2019, Michael van Elst wrote: On Thu, Mar 28, 2019 at 04:33:00PM +, Emmanuel Dreyfus wrote: On Thu, Mar 28, 2019 at 02:41:08PM -, Michael van Elst wrote: Maybe /dev/wsmux1 ? wsmux0 is mouse input. Same fate. Is it expect behavior that muxctl -f $i -l lists nothing for any $i ? % sudo wsmuxctl -f /dev/wsmux1 -l wskbd0 Greetings, -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree." !DSPAM:5c9d63cc207191150611282! ++----------+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: colorls in base
On Sun, 17 Feb 2019, Joerg Sonnenberger wrote: ... In this case, the color doesn't take anything away from you. You are no worse off than before, e.g. you have to run additional commands or long format to figure out what are subdirectories etc. Not entirely true. For those of use with red-green protanopic (?) color-blindness, we have a deficiency in "red cones" which reduces the ability to distinguish red from black. Red text would disappear on a black background. +--+--+----+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: colorls in base
On Sat, 16 Feb 2019, Christian Groessler wrote: And, yes, in daily live, I can see and distinguish traffic lights. The only important thing in this regard... I actually have trouble at nighttime to tell the difference between the green traffic lights and other "white" lights. I actually used to check whether there was a different colored light above the green one, but that actually failed in some parts of Trenton NJ where the lights were mounted horizontally! I never could remember whether green was on the left or right! +--+--+----+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: colorls in base
On Sat, 16 Feb 2019, m...@netbsd.org wrote: Add to ~/.Xresources: ! show red as green *.color1: #D7005F *.color9: #D7005F xrdb -merge ~/.Xresources (I do this with ~/.xinitrc) Blue or Cyan would actually be better than Green! :) "Reverse-video" (or rv+bold) is actually the biggest attention-getter for me, and often requires changing text from black to white to increase contrast (especially important for red or purple backgrounds). +--+--+----+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: colorls in base
On Sat, 16 Feb 2019, Kamil Rytarowski wrote: With colors we can easily scroll thousands of lines in a terminal emulator and immediately catch where is the error message (red) within a fraction of second. Not true. My eyes require LARGE amounts of color info, especially for certain colors like red. Depending on the intensity and boldness, any red text would appear as some level of gray. In most cases it would appear as <20% or >80% gray, which means that either the text disappears completely, or is indistinguishable from normal black text. Now, if you were to use WHITE text on RED background for the error messages, there's a good chance I would see it, since the saturation level would be high! :) (Please note, I am NOT suggesting that this be implemented!) It's fine, [colors] can be disabled. Other find them needed and this is to be solved. It's been solved already - it's in pkgsrc. I am not objecting to implementing colorls (in whatever form), just requesting that the default is, and will remain, OFF. +--+--+--------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: colorls in base
Or you can: - Get the best of all worlds, not have to change anything, and emit the word "error:' in another color for interactive users. Putting the output in a logfile (often with "| tee") and "grep Error:" usually works for me. :) +--+--+--------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: colorls in base
On Fri, 15 Feb 2019, Christian Groessler wrote: On 2/15/19 9:47 PM, Kamil Rytarowski wrote: On 15.02.2019 17:58, Christian Groessler wrote: Please not. Red (esp. dark read) will be difficult to read for me. I'm color blind. export TERM=vt100 (or similar) Colors nowadays are industry standard and increase readability "increase readability"? Not for me, sorry. As another color-blind person, I agree with Chris - colorized ls presents a reduction in readability, especially for red-on-black. +--+--+----+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: Moving telnet/telnetd from base to pkgsrc
On Fri, 14 Dec 2018, Edgar Fu? wrote: send hate mail my way. I guess you are over-looking my (and probably a lot of other network administrator's) primary use case for /usr/bin/telnet: connect to a HTTP/SMTP/IMAP/whatever port and speak the protocol. Yep, there's still a lot of network gear out there that doesn't have a built-in pseudo-browser-for-device-management. On second thought, I think I'd prefer telnet over http anyway, even if the device _did_ have a pseudo-browser. :) +--+--+----+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: Problem with include/bitstring.h
On Tue, 7 Aug 2018, Kamil Rytarowski wrote: On 07.08.2018 00:30, Paul Goyette wrote: While looking at some other stuff, I noticed that the operations described in bitstring(3) and implement as macros in include/bitstring.h can have a multiple-evaluation problem if the macro arguments have side effects (such as a ++ on the bit-number). Shouldn't we include a warning about this, both in the man page and in the code? It looks like the calls with multiple evaluations could be changed into static inline functions wrapped with a macro, analogously to EV_SET from . I just filed PR lib/53505 and included your suggestion.B +--+--+----+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Problem with include/bitstring.h
While looking at some other stuff, I noticed that the operations described in bitstring(3) and implement as macros in include/bitstring.h can have a multiple-evaluation problem if the macro arguments have side effects (such as a ++ on the bit-number). Shouldn't we include a warning about this, both in the man page and in the code? +--+--+----+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Suggestion: add a new option for chown(1)/chmod(1)
I'm wondering if it would be generally useful to add a new option to both chown(1) and chmod(1) to prevent a recursive change (with the -R option) from traversing across mount points, similar to the -x option available in find(1)? I'd suggest using -x, since that's what find uses. Comments? +--+--+----+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: diff(1) command options
On Thu, 1 Mar 2018, Simon Burge wrote: Paul Goyette wrote: In my case, I have a shell alias for alias diff "diff -u" 'cuz most of the time I want a -u output. But once in a blue moon (or perhaps once in a blue+super moon) I want a -y (side-by-side) output; it's a real pain to have to bypass the alias by specifying a complete path to /usr/bin/diff Not really addressing your original question, but is using \diff an option for those times you want to use -y? Most shells allow you to put a \ in front of an alias to bypass the alias. At least it means you don't have to remember where diff lives and resort using the full path. yeah, a leading backslash is not a problem - great idea. Thanks! +--+--+--------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
diff(1) command options
Is there any _good_ reason that the various output-format options (-y, -u, -c, --normal, etc.) generate error messages if you specify more than one format? For example, # diff -u -y F1 F2 diff: conflicting output style options diff: Try `diff --help' for more information. # Most other utilities I can think of simply use the-last-specified option in a conflict set; in the above example, -y would "override" -u. In my case, I have a shell alias for alias diff "diff -u" 'cuz most of the time I want a -u output. But once in a blue moon (or perhaps once in a blue+super moon) I want a -y (side-by-side) output; it's a real pain to have to bypass the alias by specifying a complete path to /usr/bin/diff :) +--+--+--------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: kdump -E for time elapsed since the beginning of trace
On Thu, 7 Sep 2017, Valery Ushakov wrote: I'd like to add kdump -E option to print timestamps as time elapsed since the beginning of trace. The option name is from FreeBSD. While here, the patch makes it possible to use a combination of -T -E and -R options to print timestamps in several formats. The idea is also from FreeBSD. Trivial patch to the man page is not included. Any objections or comments? Sounds like a useful option. Go for it. +--+--+----+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: Suggestion: add a "no-stemming" option to apropos(1)?
On Mon, 19 Jun 2017, Paul Goyette wrote: On Sun, 18 Jun 2017, Abhinav Upadhyay wrote: I have just committed this: http://mail-index.netbsd.org/source-changes/2017/06/18/msg085477.html Could you give it a go and let me know how is it now :) (you will have to rebuild the database with `makemandb -f'). Yes, this looks much better. Thanks! +--+--+----+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: Suggestion: add a "no-stemming" option to apropos(1)?
On Sun, 18 Jun 2017, Abhinav Upadhyay wrote: I have just committed this: http://mail-index.netbsd.org/source-changes/2017/06/18/msg085477.html Could you give it a go and let me know how is it now :) (you will have to rebuild the database with `makemandb -f'). I'll give this a try tomorrow. +--+--+----+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
RE: Suggestion: add a "no-stemming" option to apropos(1)?
On Thu, 8 Jun 2017, Terry Moore wrote:
On Thu, 8 Jun 017, Paul Goyette wrote:
PG> Don't get me wrong, I love apropos(1). But...
PG> I'm continually bitten by the "stemming" that occurs. [...]
So am I. I completely switched over from "man -k" to an alias
effecting "apropos -l" ("legacy"-mode):
legacy mode is close, but it doesn't print the "context" information (and,
if you use "apropos -l -m" you still don't get context info, but you do get
extra blank lines).
How about
man -k lfs | grep -B2 '\
Getting closer. When the original match was in the context info, the
output is fine.
But if the original match was in the title line, the output from
grep -B2
includes context info from some previous match whether or not it
contains the actual 'lfs' string.
And yes, the '--' separator lines from each chunk of output from grep
are undesirable; of course I could remove them with another grep:
apropos -k lfs | grep -B2 '\
This suggests that the "no stem" option could be implemented in man as a
post-process, after the query, with negligible loss of efficiency.
+--+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org |
+--+--++
Re: Suggestion: add a "no-stemming" option to apropos(1)?
On Thu, 8 Jun 2017, Martin Neitzel wrote:
PG> Don't get me wrong, I love apropos(1). But...
PG> I'm continually bitten by the "stemming" that occurs. [...]
So am I. I completely switched over from "man -k" to an alias
effecting "apropos -l" ("legacy"-mode):
legacy mode is close, but it doesn't print the "context" information
(and, if you use "apropos -l -m" you still don't get context info, but
you do get extra blank lines).
% apropos -l lfs
lfs_segwait(2) - wait until a segment is written
lfs_markv(2) - rewrite disk blocks to new disk locations
lfs_bmapv(2) - retrieve disk addresses for arrays of blocks
lfs_segclean(2) - mark a segment clean
rump_lfs(8) - mount a lfs image with a userspace server
resize_lfs(8) - resize a mounted log-structured filesystem
newfs_lfs(8) - construct a new LFS file system
mount_sysctlfs(8) - mount sysctl namespace as a directory hierarchy
mount_nilfs(8) - mount a NILFS file system
mount_lfs(8) - mount a log-structured file system
lfs_cleanerd(8) - garbage collect a log-structured file system
hlfsd(8) - home-link file system daemon
fsck_lfs(8) - Log-structured File System consistency check and interactive
repair
dumplfs(8) - dump file system information
dump_lfs(8) - filesystem backup
%
(This is with netbsd7; with 6, apropos -C was fine, too.)
Martin
!DSPAM:59397143206401043911127!
+--+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org |
+--+--++
Suggestion: add a "no-stemming" option to apropos(1)?
Don't get me wrong, I love apropos(1). But... I'm continually bitten by the "stemming" that occurs. Today's example is an attempt to find all the man pages that refer to file system lfs. Using "apropos lfs" returns more than 120 entries, complete with their associated context! The vast majority of those entries are really for "lf" (in either upper- or lower-case), and have no relation to lfs the file system! Would it be unreasonable to add a no-stem option to apropos(1)? +--+------++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: KASSERT and clang static analyzer
I looked at the picture, and it seems to me it is doing the same thing that it does for any other "if ()" condition. Look just a little bit further down and you'll see the same "assumption" on an if that isn't buried inside a macro. In short, there's nothing wrong, nothing to investigate. On Tue, 18 Apr 2017, Kamil Rytarowski wrote: On 18.04.2017 11:39, co...@sdf.org wrote: Hi, I'm trying clang static analyzer. It seems to assume that KASSERT(a != 0) => test what happens if a == 0 in the rest of the function any idea how to convince it to stop doing that? example output: http://i.imgur.com/AqTm9mq.png I'm building kernel with 'scan-build make -j20' Thanks. Does disabling the diagnostics in the kernel help? +--+------++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: "cno" keyword for config(8)
On Sat, 6 Aug 2016, Christos Zoulas wrote: On Aug 7, 12:29am, k...@munnari.oz.au (Robert Elz) wrote: -- Subject: Re: "cno" keyword for config(8) | SOunds like a good idea to me, it bugs me often that my "no xxx" stuff | in config files keeps failing when someone deletes, or renames, xxx | | But an alternative would be to just change "no" so that it doesn't fail | when there is nothing to remove (make "no" effectively be "cno") - the | effect (not having whatever it is) is achieved whether the "no" deletes | it or whether it never existed in the first place. Well, yes I thought about that and then to have a warning option to print the ones that did not match so that we can see typos... What do people prefer? If I recall correctly, we get just such a warning when you use "no option foo" and "option foo" was not previously selected. I think we should be consistent. So, rather than using a new keyword 'cno', just change the current error into a warning. +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | +--+--++
Re: find(1) and group/user handling
On Sun, 12 Jun 2016, David Holland wrote:
On Sun, Jun 12, 2016 at 05:19:54PM +, David Holland wrote:
> On Sun, Jun 12, 2016 at 08:10:27PM +0800, Paul Goyette wrote:
> > In my opinion, the -user and -group primaries should work strictly with
> > _names_, and _never_ fallback to {u,g}id values; we could easily add
> > new primaries -uid and -gid to search for the numeric values. However,
> > this would make find(1) incompatible with existing versions.
> >
> > Comments?
>
> I agree; ambiguating what things do is usually not a good idea,
> because eventually the result is that it does something you don't
> expect and then you have to figure out both what it thought you meant
> and what it did.
> [...]
For now though I've fixed it so -user and -group at least behave the
same way.
Thanks!
Your earlier comments about user names not being allowed to start with a
plus or minus were informative. But what about group names? Can they
legally start with plus/minus? :)
+------+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--++
find(1) and group/user handling
WRT to your (kre's) PR bin/46158, I have to wonder ...
Assume there is an entry in the password database for a username "123"
but with uid value of 456. If find is invoked with '-user 123' should
we match this pw entry and compare the file's numeric owner with 456?
Or should find(1) treat an all-numeric username strictly as a number,
and compare in this case against 123?
In the latter case, it makes sense to allow the plus/minus prefix.
But if we decide that the "username" provided should be treated as a
name whenever possible, then it would not make sense to permit the
prefix. A '-user +123' should strictly match a username of +123; if
no such user exists (sidebar: are + and - valid characters in a
username?) we should treat the request as "any user id greater than
123".
In my opinion, the -user and -group primaries should work strictly with
_names_, and _never_ fallback to {u,g}id values; we could easily add
new primaries -uid and -gid to search for the numeric values. However,
this would make find(1) incompatible with existing versions.
Comments?
+--+------++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--++
Re: Possible enhancement to find(1)
On Sat, 11 Jun 2016, Paul Goyette wrote:
On Sat, 11 Jun 2016, Robert Elz wrote:
...
If you were also to add
{ "-newerat", N_ASINCE, c_asince, 1 }, /* gnu find
compat */
{ "-newerct", N_CSINCE, c_csince, 1 },
{ "-newermt", N_SINCE,c_since,1 },/* ung */
in the appropriate place, you'd have something that was command line
compatible with gnu findutils, so scripts written for that find, which
only use facilities actually implemented here, would work.
Would that really be such an evil thing?
For me, yes. I will not implement the ugly gnu stuff, neither in its
entirety nor partially.
Well, I've been convinced by several off-list exchanges that it's really
not so bad to implement the gnu stuff after all.
We only have to implement gnu-equivalents for the functionality that we
already have - so we don't have to implement comparisons of differing
attributes (ie, a found file's atime vs the reference file's mtime).
The man-page for findutils clearly states that not all combinations need
to be provided.
I've restructured the existing code a bit, so that the parsing code
provides each option's argument parser with the actual option name;
this allows us to use the same argument parsing routines for the "alias"
options as for the "real" options.
New diffs are attached. These include lists of the findutils -newerXY
options which remain unimplemented.
Comments are welcomed - even though I might at first reject them, I do
eventually consider them. :)
+--+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--++Index: extern.h
===
RCS file: /cvsroot/src/usr.bin/find/extern.h,v
retrieving revision 1.28
diff -u -p -r1.28 extern.h
--- extern.h19 Jul 2007 07:49:30 - 1.28
+++ extern.h12 Jun 2016 00:30:16 -
@@ -47,53 +47,56 @@ void printlong(char *, char *, struct s
int queryuser(char **);
voidshow_path(int);
-PLAN *c_amin(char ***, int);
-PLAN *c_anewer(char ***, int);
-PLAN *c_atime(char ***, int);
-PLAN *c_cmin(char ***, int);
-PLAN *c_cnewer(char ***, int);
-PLAN *c_ctime(char ***, int);
-PLAN *c_delete(char ***, int);
-PLAN *c_depth(char ***, int);
-PLAN *c_empty(char ***, int);
-PLAN *c_exec(char ***, int);
-PLAN *c_execdir(char ***, int);
-PLAN *c_exit(char ***, int);
-PLAN *c_false(char ***, int);
-PLAN *c_flags(char ***, int);
-PLAN *c_follow(char ***, int);
-PLAN *c_fprint(char ***, int);
-PLAN *c_fstype(char ***, int);
-PLAN *c_group(char ***, int);
-PLAN *c_iname(char ***, int);
-PLAN *c_inum(char ***, int);
-PLAN *c_iregex(char ***, int);
-PLAN *c_links(char ***, int);
-PLAN *c_ls(char ***, int);
-PLAN *c_maxdepth(char ***, int);
-PLAN *c_mindepth(char ***, int);
-PLAN *c_mmin(char ***, int);
-PLAN *c_mtime(char ***, int);
-PLAN *c_name(char ***, int);
-PLAN *c_newer(char ***, int);
-PLAN *c_nogroup(char ***, int);
-PLAN *c_nouser(char ***, int);
-PLAN *c_path(char ***, int);
-PLAN *c_perm(char ***, int);
-PLAN *c_print(char ***, int);
-PLAN *c_print0(char ***, int);
-PLAN *c_printx(char ***, int);
-PLAN *c_prune(char ***, int);
-PLAN *c_regex(char ***, int);
-PLAN *c_size(char ***, int);
-PLAN *c_type(char ***, int);
-PLAN *c_user(char ***, int);
-PLAN *c_xdev(char ***, int);
-PLAN *c_openparen(char ***, int);
-PLAN *c_closeparen(char ***, int);
-PLAN *c_not(char ***, int);
-PLAN *c_or(char ***, int);
-PLAN *c_null(char ***, int);
+PLAN *c_amin(char ***, int, char *);
+PLAN *c_anewer(char ***, int, char *);
+PLAN *c_asince(char ***, int, char *);
+PLAN *c_atime(char ***, int, char *);
+PLAN *c_cmin(char ***, int, char *);
+PLAN *c_cnewer(char ***, int, char *);
+PLAN *c_csince(char ***, int, char *);
+PLAN *c_ctime(char ***, int, char *);
+PLAN *c_delete(char ***, int, char *);
+PLAN *c_depth(char ***, int, char *);
+PLAN *c_empty(char ***, int, char *);
+PLAN *c_exec(char ***, int, char *);
+PLAN *c_execdir(char ***, int, char *);
+PLAN *c_exit(char ***, int, char *);
+PLAN *c_false(char ***, int, char *);
+PLAN *c_flags(char ***, int, char *);
+PLAN *c_follow(char ***, int, char *);
+PLAN *c_fprint(char ***, int, char *);
+PLAN *c_fstype(char ***, int, char *);
+PLAN *c_group(char ***, int, char *);
+PLAN *c_iname(char ***, int, char *);
+PLAN *c_inum(char ***, int, char *);
+PLAN *c_iregex(char ***, int, char *);
+PLAN *c_links(char ***, int, char *);
+PLAN *c_ls(char ***, int, char *);
+PLAN *c_maxdept
Re: Possible enhancement to find(1)
On Sat, 11 Jun 2016, Robert Elz wrote:
You added -since but documented -msince in the man page.
I think I just fixed that in my local copy. wiz@ pointed it out.
If you were also to add
{ "-newerat", N_ASINCE, c_asince, 1 },/* gnu
find compat */
{ "-newerct", N_CSINCE, c_csince, 1 },
{ "-newermt", N_SINCE,c_since,1 },/* ung */
in the appropriate place, you'd have something that was command line
compatible with gnu findutils, so scripts written for that find, which
only use facilities actually implemented here, would work.
Would that really be such an evil thing?
For me, yes. I will not implement the ugly gnu stuff, neither in its
entirety nor partially.
+--+--+----+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--++
Re: Possible enhancement to find(1)
Anyway, I don't really care one way or the other. I'll make my changes
locally, and I'll get what I want. If others want to use findutils, they
know where to get it; if others want my changes, ask for them.
I just won't commit them without some sort of indication of consent. (Just
like my changes re resurrecting the ksem module, discussed last year...)
If anyone wants them, the diffs are attached.
+--+--+----+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--++Index: extern.h
===
RCS file: /cvsroot/src/usr.bin/find/extern.h,v
retrieving revision 1.28
diff -u -p -r1.28 extern.h
--- extern.h19 Jul 2007 07:49:30 - 1.28
+++ extern.h11 Jun 2016 00:54:42 -
@@ -49,9 +49,11 @@ void show_path(int);
PLAN *c_amin(char ***, int);
PLAN *c_anewer(char ***, int);
+PLAN *c_asince(char ***, int);
PLAN *c_atime(char ***, int);
PLAN *c_cmin(char ***, int);
PLAN *c_cnewer(char ***, int);
+PLAN *c_csince(char ***, int);
PLAN *c_ctime(char ***, int);
PLAN *c_delete(char ***, int);
PLAN *c_depth(char ***, int);
@@ -85,6 +87,7 @@ PLAN *c_print0(char ***, int);
PLAN *c_printx(char ***, int);
PLAN *c_prune(char ***, int);
PLAN *c_regex(char ***, int);
+PLAN *c_since(char ***, int);
PLAN *c_size(char ***, int);
PLAN *c_type(char ***, int);
PLAN *c_user(char ***, int);
Index: find.1
===
RCS file: /cvsroot/src/usr.bin/find/find.1,v
retrieving revision 1.81
diff -u -p -r1.81 find.1
--- find.1 17 May 2014 11:31:40 - 1.81
+++ find.1 11 Jun 2016 00:54:42 -
@@ -32,7 +32,7 @@
.\"
.\"from: @(#)find.18.7 (Berkeley) 5/9/95
.\"
-.Dd May 17, 2014
+.Dd June 10, 2016
.Dt FIND 1
.Os
.Sh NAME
@@ -171,6 +171,11 @@ a preceding minus sign means
and neither means
.Dq exactly Ar n .
.Pp
+For primaries which take a
+.Ar timestamp
+argument, the argument must be valid input to
+.Xr parsedate 3 .
+.Pp
.Bl -tag -width Ds -compact
.It Ic -amin Ar n
True if the difference between the file last access time and the time
@@ -183,6 +188,10 @@ minutes.
True if the current file has a more recent last access time than
.Ar file .
.Pp
+.It Ic -asince Ar "timestamp"
+True if the file last access time is greater than the specified
+.Ar timestamp .
+.Pp
.It Ic -atime Ar n
True if the difference between the file last access time and the time
.Nm
@@ -202,6 +211,10 @@ minutes.
True if the current file has a more recent last change time than
.Ar file .
.Pp
+.It Ic -csince Ar "timestamp"
+True if the file last status change time is greater than the specified
+.Ar timestamp .
+.Pp
.It Ic -ctime Ar n
True if the difference between the time of last change of file status
information and the time
@@ -637,6 +650,10 @@ basic regular expression
This is a match on the whole path, not a search for the regular expression
within the path.
.Pp
+.It Ic -since Ar "timestamp"
+True if the file last modification time is more recent than
+.Ar timestamp .
+.Pp
.It Ic -size Ar n Ns Op Cm c
True if the file's size, rounded up, in 512-byte blocks is
.Ar n .
@@ -809,8 +826,10 @@ standard.
The options and the
.Ic -amin ,
.Ic -anewer ,
+.Ic -asince ,
.Ic -cmin ,
.Ic -cnewer ,
+.Ic -csince ,
.Ic -delete ,
.Ic -empty ,
.Ic -execdir ,
@@ -828,8 +847,9 @@ The options and the
.Ic -print0 ,
.Ic -printx ,
.Ic -regex ,
+.Ic -rm ,
and
-.Ic -rm
+.Ic -msince
primaries are extensions to
.St -p1003.2 .
.Pp
Index: find.h
===
RCS file: /cvsroot/src/usr.bin/find/find.h,v
retrieving revision 1.25
diff -u -p -r1.25 find.h
--- find.h 4 May 2013 06:29:32 - 1.25
+++ find.h 11 Jun 2016 00:54:42 -
@@ -40,13 +40,13 @@
/* node type */
enum ntype {
N_AND = 1, /* must start > 0 */
- N_AMIN, N_ANEWER, N_ATIME, N_CLOSEPAREN, N_CMIN, N_CNEWER, N_CTIME,
- N_DEPTH, N_EMPTY, N_EXEC, N_EXECDIR, N_EXIT, N_EXPR, N_FALSE, N_FLAGS,
- N_FOLLOW, N_FPRINT, N_FSTYPE, N_GROUP,
+ N_AMIN, N_ANEWER, N_ASINCE, N_ATIME, N_CLOSEPAREN, N_CMIN, N_CNEWER,
+ N_CSINCE, N_CTIME, N_DEPTH, N_EMPTY, N_EXEC, N_EXECDIR, N_EXIT,
+ N_EXPR, N_FALSE, N_FLAGS, N_FOLLOW, N_FPRINT, N_FSTYPE, N_GROUP,
N_INAME, N_INUM, N_IREGEX, N_LINKS, N_LS, N_MINDEPTH, N_MAXDEPTH,
N_MMIN, N_MTIME, N_NAME, N_NEWER, N_NOGROUP, N_NOT, N_NOUSER, N_OK,
N_OPENPAREN, N_OR, N_PATH, N_PERM, N_PRINT, N_PRINT0, N_PRINTX,
- N_PRUNE, N_REGEX, N
Re: Possible enhancement to find(1)
On Fri, 10 Jun 2016, Robert Elz wrote:
Date:Fri, 10 Jun 2016 17:03:35 +0800 (PHT)
From:Paul Goyette
Message-ID:
| Does anyone have suggestions and web-sites for a couple of linux
| distros? I'm not going to check them all... :)
I'd assume they all use the find that's in the gnu findutils which is
in pkgsrc (sysutils/findutils)
But from a man page on a real linux system...
-newerXY reference
Yeah, I noticed this, too, on findutils...
This is ugly.
If you want the linux variation, go install findutils from pkgsrc. :)
I'm willing to add the -{a,c,m}since options (or -{a,c,}since) with
parsing of the timestamp via parsedate(3), but I'm not going to copy
findutils.
The -d option of gnu date is essentially the same as in NetBSD date -d
(though I wouldn't guarantee that our parsedate() always produces the
same results as theirs - in fact it almost certainly doesn't).
I insist on using parsedate(3) since I want these to work:
find -asince "3 days ago"
find \! -since "last monday"
Note that that man page extract is useless, and leaves you guessing (which
is what I did) as to what this thing actually means! The text suggests that
both X and Y relate to the reference time, but that would make no sense at
all. I deduce that X is the inode time to check in the current file, and
Y is the reference time, as X==t is invalid.
It's the only interpretation that comes close to making sense.
Anyway, I don't really care one way or the other. I'll make my changes
locally, and I'll get what I want. If others want to use findutils,
they know where to get it; if others want my changes, ask for them.
I just won't commit them without some sort of indication of consent.
(Just like my changes re resurrecting the ksem module, discussed last
year...)
+--+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--++
Re: Possible enhancement to find(1)
On Fri, 10 Jun 2016, Robert Elz wrote:
Date:Fri, 10 Jun 2016 16:06:42 +0800 (PHT)
From:Paul Goyette
Message-ID:
| > On Fri, Jun 10, 2016 at 02:18:16PM +0800, Paul Goyette wrote:
| >> I'd like to suggest adding new primitives
| >>
| >> -asince "timestamp"
| >> -csince "timestamp"
| I'll get started on the changes tomorrow.
But add all 3 (useful) inode times, not just 2 of them (you can
ignore birthtime, as does almost everything else, that's a waste
of inode space)
yeah Birth is useless. :)
Along with -{a,c}{newer,min,time} there is also -mmin -mtime and -newer
(and yes, slight pity that the naming is not all consistent, but -newer
has been there much longer than the others).
It was my intent to also add -since (for consistency with -newer). I
_knew_ there was another one, I simply missed it the first time around.
+--+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--++
Re: Possible enhancement to find(1)
On Fri, 10 Jun 2016, Roy Marples wrote: On 10/06/2016 10:03, Paul Goyette wrote: Does anyone have suggestions and web-sites for a couple of linux distros? I'm not going to check them all... :) http://man7.org/linux/man-pages/man1/find.1.html Quite a few time related options. Yup - including -daystart This is basically the same as GNU findutils, which does not have the functionality that I'm adding. Thanks for the pointer. +--+--+----+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | +--+--++
Re: Possible enhancement to find(1)
On Fri, 10 Jun 2016, Simon Burge wrote:
Paul Goyette wrote:
I often find myself (no pun intended!) wanting to determine which files
were accessed before/since a particular timestamp. There currently
exist the -{a,c}{newer,min,time} primitives, but none of these allow me
to say "since today at 5 AM".
I'd like to suggest adding new primitives
-asince "timestamp"
-csince "timestamp"
where the timestamp argument would be converted to an actual time using
parsedate(3).
And -msince ?
Yes, I got that one, too! :)
+--+--+----+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--++
Re: Possible enhancement to find(1)
On Fri, 10 Jun 2016, Thomas Klausner wrote:
On Fri, Jun 10, 2016 at 02:18:16PM +0800, Paul Goyette wrote:
I often find myself (no pun intended!) wanting to determine which files were
accessed before/since a particular timestamp. There currently exist the
-{a,c}{newer,min,time} primitives, but none of these allow me to say "since
today at 5 AM".
I'd like to suggest adding new primitives
-asince "timestamp"
-csince "timestamp"
where the timestamp argument would be converted to an actual time using
parsedate(3).
Does anyone else think this is a good idea? Is there anyone who would
object to adding these primitives?
No, but can you please check some other operating systems/GNU tools if
they have some option like that and match the name, if possible?
I've checked both FreeBSD and OpenBSD and they don't seem to have done
anything similar. At least, no mention in their man pages.
Does anyone have suggestions and web-sites for a couple of linux
distros? I'm not going to check them all... :)
+--+------++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--++
Re: Possible enhancement to find(1)
On Fri, 10 Jun 2016, Martin Husemann wrote: On Fri, Jun 10, 2016 at 02:18:16PM +0800, Paul Goyette wrote: I'd like to suggest adding new primitives -asince "timestamp" -csince "timestamp" where the timestamp argument would be converted to an actual time using parsedate(3). Does anyone else think this is a good idea? Is there anyone who would object to adding these primitives? Yes, that looks good (I use "touch -d ... /tmp/mark" quite often for this, avoiding the temporary file would be great). Exactly! I'll get started on the changes tomorrow. +--+------++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | +--+--++
Possible enhancement to find(1)
I often find myself (no pun intended!) wanting to determine which files
were accessed before/since a particular timestamp. There currently
exist the -{a,c}{newer,min,time} primitives, but none of these allow me
to say "since today at 5 AM".
I'd like to suggest adding new primitives
-asince "timestamp"
-csince "timestamp"
where the timestamp argument would be converted to an actual time using
parsedate(3).
Does anyone else think this is a good idea? Is there anyone who would
object to adding these primitives?
+--+--+----+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--++
Re: Minor updates to sort ?
(Commenting in-line, not top-posting!) On Sun, 29 May 2016, Robert Elz wrote: Date:Sat, 28 May 2016 22:29:51 -0700 From:Alistair Crooks Message-ID: | Living on the edge and top posting aggresively, these changes would be good | to have. I also agree - these are all good changes. OK, but I will wait a day or two more to allow for more comments (or more suggested improvements.) I was asked (in off-list mail) to also add something to the manual about how multiple -k args work. This is more verbose that what was suggested... (I made this off-list comment...) sort compares records by comparing the key fields selected by -k arguments, from first given to last, until discovering a difference. If there are no -k arguments, the whole record is treated as the key. After exhausting the -k arguments, if no difference has been found, then the result depends upon the -u and -S option settings. With -u the records are considered identical, and one is supressed. Otherwise with -s set (default) the records are left in their original order, or with -S (posix mode) the whole record is considered as a tie breaker. Maybe update 2nd sentence? If there are no -k arguments, the whole record is treated as a single key. I also (now) have (currently anyway) in the proposed updated man page, the following commented text immediately after the paragraph above ... .\" .\" If you fail to understand why it doesn't matter which order .\" the records are output when they are wholly identical, there .\" is nothing that this man page can say that wll help! .\" (This is because there is a comment in the posix spec about this being unspecified...) Posix can be so helpful at times, and at other times, not so much ... +--+--+--------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | +--+--++
Re: PaX MPROTECT gdb and software breakpoints
uOn Sun, 22 May 2016, Martin Husemann wrote: On Sat, May 21, 2016 at 04:21:45PM -0400, Christos Zoulas wrote: There are three solutions I can think of (maybe you can think of a better one): 1. Leave it as it is and document that people will have to paxctl +m the executables that they need to mprotect before they can debug it. 2. create a uvm_io1() and a new UVM_EXTRACT that breaks MPROTECT and fetches with the right mappings. I don't like that, it breaks MPROTECT and uvm contracts. But it has the advantage of working on already started process we PT_ATTACH to. 3. when process is execed and is already traced (PT_TRACE_ME), disable MPROTECT. This should work with processes started from gdb, but not attached ones. We will still need to explain that to attach and insert breakpoints you need to set MPROTECT off. Tricky. I find (3) is a bit too limited, but it is the only clean way. Like David suggested, (1) could be extended by a gdb message explaining the issue. (2) is evil, but may be needed. Of course we should restrict the new path to traced processes, and maybe even limit it to root additionally? If we go ahead with (2), could we at least have a sysctl knob to enable it (with default of Disabled)? That way, you could get the needed functionality, but only with an explicit action to acknowledge that you are breaking all the contracts... +--+--+----+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | +--+--++
Re: refine of the GSOC project
On Mon, 9 May 2016, Brett Lymn wrote: On Mon, May 09, 2016 at 12:53:02AM +, Christos Zoulas wrote: Heh that's funny. He should then run the build.sh command with the old tooldir name or make a symlink from the old tooldir name to the new one. Why not just "build.sh tools" to regenerate the tools for the new kernel version? Or USETOOLS=NO if it is something quick and dirty... Or just add '-T /path/to/netbsd-6-tools' ?? +--+--+--------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | +--+--++
Re: Indexing and searching non-numeric sections with apropos(1)
On Thu, 14 Apr 2016, Paul Goyette wrote: On Thu, 14 Apr 2016, Abhinav Upadhyay wrote: On Thu, Apr 14, 2016 at 3:20 AM, Paul Goyette wrote: With bin/51062, makemandb(8) can index non-numeric sections and also apropos(1) can now accept non-numeric sections for querying. That means you do queries like apropos -s 9lua systm apropos -s n foo bar To be able to use this feature, you need to regenerate the database. You can do this by running makemandb -f manually. I rebuilt my database. Although apropos(1) now finds the information for the non-numeric sections, it is still reporting them wrongly: # apropos -s 9lua lua intro (9) introduction to the Lua kernel bindings This section provides an overview of the Lua kernel bindings, ... Note that the output says "intro (9)" - shouldn't it say "intro (9lua)"? Sorry, I forgot to mention that you also need to rebuild makemandb and apropos. After that, rebuilding the database should give the correct output. Ah, OK. I will check that soon. Yes, that works just great! # makemandb -f -Q # apropos -s 9lua lua intro (9lua)introduction to the Lua kernel bindings This section provides an overview of the Lua kernel bindings, ... +--+--+--------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | +--+--++
Re: Indexing and searching non-numeric sections with apropos(1)
On Thu, 14 Apr 2016, Abhinav Upadhyay wrote: On Thu, Apr 14, 2016 at 3:20 AM, Paul Goyette wrote: With bin/51062, makemandb(8) can index non-numeric sections and also apropos(1) can now accept non-numeric sections for querying. That means you do queries like apropos -s 9lua systm apropos -s n foo bar To be able to use this feature, you need to regenerate the database. You can do this by running makemandb -f manually. I rebuilt my database. Although apropos(1) now finds the information for the non-numeric sections, it is still reporting them wrongly: # apropos -s 9lua lua intro (9) introduction to the Lua kernel bindings This section provides an overview of the Lua kernel bindings, ... Note that the output says "intro (9)" - shouldn't it say "intro (9lua)"? Sorry, I forgot to mention that you also need to rebuild makemandb and apropos. After that, rebuilding the database should give the correct output. Ah, OK. I will check that soon. +--+--+--------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | +--+--++
Re: Indexing and searching non-numeric sections with apropos(1)
With bin/51062, makemandb(8) can index non-numeric sections and also apropos(1) can now accept non-numeric sections for querying. That means you do queries like apropos -s 9lua systm apropos -s n foo bar To be able to use this feature, you need to regenerate the database. You can do this by running makemandb -f manually. I rebuilt my database. Although apropos(1) now finds the information for the non-numeric sections, it is still reporting them wrongly: # apropos -s 9lua lua intro (9) introduction to the Lua kernel bindings This section provides an overview of the Lua kernel bindings, ... Note that the output says "intro (9)" - shouldn't it say "intro (9lua)"? +--+--+--------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | +--+--++
Re: Next steps for /bin/sh
On Sat, 27 Feb 2016, Robert Elz wrote: That one relates to what sh -c 'set -e; false && false; echo foo' should do. When the PR was filed, and during the discussion, up till when the PR was suspended, the POSIX standard in this area was nonsense - which I believe is what caused the problems, with some believing the standard should be followed, and others arguing for the "obviously" correct and intended result. In the interim, the 2013 version of the posix std has been published, with considerably better wording relating to the -e option. Now both the standard and the "obviously correct" interpretation agree. That is, the shell given the comamnd above should exit(1) and not print "foo" when the 2nd of the two "false" commands is executed. Now all that would be simple, and an obvious change to make (once I figure out what code changes are needed to correct it, but I hope that won't be a problem) if it wasn't for one other issue. That is: as far as I can determine, there isn't a single other modern shell that implements this the way it should be implemented, they all do the same as NetBSD's shell, which is to echo foo and exit(0). It is possible the ancient /bin/sh on (some versions of?) Solaris that everyone mostly loves to find ways to avoid because it is so ancient might be the sole surviving (actually used) shell that does this correctly. I don't have access to that one to test it. So, if we make this change, we will be the one and only shell doing it this way (at least for now: I suspect when bash 4.4 is released, at a very minimum in posix mode, it will also change, others might update eventually too). So, should we change it?If so, I'll look into what code needs altering. In my opinion, having the standard finally updated is a big step in the right direction. Since both the standard and the "obviously correct" result now agree, I would vote in favor of fixing this bug. I'm quite certain it won't be the first time we're in the vanguard of correctness, and perhaps our efforts might be used by others to justify adopting the updated standard. :) +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | +--+--++
Re: rc.d/{powerd,envsys}
Yeah, this makes sense. We shouldn't start powerd to process sensor events until after the sensors themselves are properly initialized. And, as you've seen on your machine, we can't always trust the BIOS to "properly" initialize things. :) On Thu, 18 Feb 2016, Edgar Fu? wrote: I have a case where the default limits on a sensor (probably set by the BIOS) are wrong and are prone to cause an immediate shutdown of the machine when powerd is run. I can correct the values in envsys.conf. However, upon startup, powerd may have been started before rc.d/envsys is run. So I suggest that rc.d/envsys should get an additional # BEFORE: powerd line. !DSPAM:56c5a2fa16832088018165! +--+--+--------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | +--+--++
Re: setting an envsys temperature limit (was: removing an envsys temperature limit)
On Wed, 17 Feb 2016, Edgar Fuss wrote: So, this is about the 45degC CritMin part? I see. Yes. I am curious on your resolution -- when you modify these limits through envsys, the values are supposed to get written back into the chip (http://bxr.su/n/sys/dev/i2c/dbcool.c#dbcool_set_temp_limits). It is unlikely that user-specified values will survive a reboot, unless the chip has NVRAM. :) Otherwise, the chip will reset, and then the BIOS gets its own chance to set start-up values. +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | +--+--++
Re: removing an envsys temperature limit
On Tue, 16 Feb 2016, Edgar Fu? wrote:
Is this a continuation of your prior thread:
http://mail-index.netbsd.org/tech-userlevel/2016/01/30/msg009639.html ?
No. That was about a 54 degC CritMax for CPU Temp.
If so, what you're effectively asking is for
http://bxr.su/n/sys/dev/i2c/dbcool.c#dbcool_get_temp_limits to stop
reading the limits from the chip, which I don't think is supported.
It doesn't report any limit for sensor0 (l_temp), so there must be a way of
having "no limit".
It is possible to have "no limit". However, if the BIOS (or the sensor
itself) establishes a limit, it cannot be removed. It can only be
modified.
The "envstat -S" command can be used to reset a sensor's limits to the
state they were in at boot-time. For sensors which do not have any
initial limit, this command will remove any user-specified limits. For
chips which have initial limits, those initial limits are restored.
I'm curious why any adverse action was taken when triggering the
critical-minimum alarm. /etc/powerd/scripts/temperature_sensor seems to
indicate the action should be a simple syslog message:
critical-under)
logger -p warning "${0}: ($1) dropped below critical limit [${3}]" >&1
exit 0
;;
+------+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--++
