Re: cwm: do not overlap menu entries
On Thu 2022.10.13 at 17:30 +0200, Omar Polo wrote:
> On 2022/10/13 15:16:47 +, Klemens Nanni wrote:
> > On Thu, Oct 13, 2022 at 04:39:04PM +0200, Omar Polo wrote:
> > > On 2022/10/13 13:00:34 +, Klemens Nanni wrote:
> > > > On Thu, Oct 13, 2022 at 08:28:50AM -0400, Okan Demirmen wrote:
> > > > > And I keep missing it! I can't reproduce this - can you share the font
> > > > > you're using maybe?
> > > >
> > > > Whatever is the default, I never fiddled with fonts in X, no xorg.conf,
> > > > `cwm -c/dev/null' shows the glitch for me on a ThinkPad X230.
> > >
> > > i can't reproduce it either, not with my normal cwmrc and nor with an
> > > empty one. However with your patch the selected menu entry seems to
> > > be... correctly sized? Without your patch the selected item seems to
> > > be slightly more tall and "touch" the numbers and the parens of the
> > > items below.
> >
> > That as well, at leat to my eye.
> >
> > Here are four screen shots from my X230 running `cwm -c /dev/null'
> > inside Xephyr, taken with `scrot -s -q 100' so I can select the area
> > without clicking into the window which would make cwm's menu disappear.
> >
> > "current-" and "patch-" mean cwm from current and with the +1 patch,
> > respectively.
> >
> > "top-bottom" and "bottom-top" mean that the cursor has been moved across
> > the menu top to bottom and bottom to top, respectively.
> >
> > current-bottom-top.png shows cropped "[]" chars in the second entry,
> > whereas current-top-bottom.png and patch-*.png do not.
>
> Ahhh, now i see that too. it's subtle but your screenshot clearly
> shows that the selected items hides the top row of fixes from the item
> belows it. I've never noticed it before 'cause the selected items
> here has a black background (due to my ~/.Xdefaults.), but it happens
> for me too. Actually, i get what it looks like a "pixel perfect"
> result by subtracting two instead of one from descent in menu.c, but i
> was just playing with it -- need to re-read that part more closely.
okay, i see it now!
**incomplete** but i think the right direction to use ascent+descent,
however i've missed something, so take this with a sea full of salt (and
yes, i'm still alive...). the menu rect is too big (by a factor of
entries i think) now and messes with other calculations dealing with ptr
selections/movement; i just need find the other assumptions made with this
+ 1 stuff and if i used the right surgical hammer.
Index: menu.c
===
RCS file: /home/open/cvs/xenocara/app/cwm/menu.c,v
retrieving revision 1.109
diff -u -p -r1.109 menu.c
--- menu.c 27 Feb 2020 14:56:39 - 1.109
+++ menu.c 14 Oct 2022 01:40:30 -
@@ -355,7 +355,7 @@ menu_draw(struct menu_ctx *mc, struct me
XftTextExtentsUtf8(X_Dpy, sc->xftfont,
(const FcChar8*)mc->dispstr, strlen(mc->dispstr), );
mc->geom.w = extents.xOff;
- mc->geom.h = sc->xftfont->height + 1;
+ mc->geom.h = sc->xftfont->ascent + sc->xftfont->descent;
mc->num = 1;
TAILQ_FOREACH(mi, resultq, resultentry) {
@@ -364,7 +364,7 @@ menu_draw(struct menu_ctx *mc, struct me
(const FcChar8*)mi->print,
MIN(strlen(mi->print), MENU_MAXENTRY), );
mc->geom.w = MAX(mc->geom.w, extents.xOff);
- mc->geom.h += sc->xftfont->height + 1;
+ mc->geom.h += sc->xftfont->ascent + sc->xftfont->descent;
mc->num++;
}
@@ -403,7 +403,7 @@ menu_draw(struct menu_ctx *mc, struct me
(const FcChar8*)mc->dispstr, strlen(mc->dispstr));
TAILQ_FOREACH(mi, resultq, resultentry) {
- int y = n * (sc->xftfont->height + 1) + sc->xftfont->ascent + 1;
+ int y = n * sc->xftfont->height + sc->xftfont->ascent;
/* Stop drawing when menu doesn't fit inside the screen. */
if (mc->geom.y + y > area.h)
@@ -435,12 +435,12 @@ menu_draw_entry(struct menu_ctx *mc, str
color = (active) ? CWM_COLOR_MENU_FG : CWM_COLOR_MENU_BG;
XftDrawRect(mc->xftdraw, >xftcolor[color], 0,
- (sc->xftfont->height + 1) * entry, mc->geom.w,
- (sc->xftfont->height + 1) + sc->xftfont->descent);
+ sc->xftfont->height * entry, mc->geom.w,
+ sc->xftfont->ascent + sc->xftfont->descent);
color = (active) ? CWM_COLOR_MENU_FONT_SEL : CWM_COLOR_MENU_FONT;
XftDrawStringUtf8(mc->xftdraw,
>xftcolor[color], sc->xftfont,
- 0, (sc->xftfont->height + 1) * entry + sc->xftfont->ascent + 1,
+ 0, sc->xftfont->height * entry + sc->xftfont->ascent,
(const FcChar8*)mi->print, strlen(mi->print));
}
@@ -487,11 +487,11 @@ menu_calc_entry(struct menu_ctx *mc, int
struct screen_ctx *sc = mc->sc;
int entry;
- entry = y / (sc->xftfont->height + 1);
+ entry = y /
Re: gunzip: support .zip files with a single member
On Thu, Oct 13, 2022 at 02:14:28PM -0600, Todd C. Miller wrote: > Comments or OKs? Golly! Why not add the functionality to cat(1)? Or straight into the shell as a built-in? -- . ___ ___ . . ___ . \/ |\ |\ \ . _\_ /__ |-\ |-\ \__
Re: gunzip: support .zip files with a single member
On Thu, 13 Oct 2022 14:14:28 -0600, "Todd C. Miller" wrote:
> GNU gzip support uncompressing .zip files that contain a single
> member. This can be very convenient when dealing with email
> attachments that use zip instead of gzip to compress a single file
> (I'm looking at you Google). Below is a diff to support this with
> our gzip. This turned out to be more complicated than I expected
> simply due to the number of zip extended header fields.
>
> If there is more than a single file in the .zip we extract the first
> one but leave the origin .zip file alone. I made some minor tweaks
> to main.c to support this. We now only remove the output file if
> error is set to FAILURE, not WARNING. This has the side effect
> that the output file is no longer removed simply due to a crc error,
> which I think is an improvement.
I found a problem with my previous version reporting crc errors for
larger files. That is fixed in the version below. With the latest
diff here is the size of distrib/special/gzip on amd64:
Old:
textdatabss dec hex
184591 777629104 221471 3611f
New:
textdatabss dec hex
184559 777629104 221439 360ff
There is now a net decrease in size :-)
- todd
Index: usr.bin/compress/Makefile
===
RCS file: /cvs/src/usr.bin/compress/Makefile,v
retrieving revision 1.22
diff -u -p -u -r1.22 Makefile
--- usr.bin/compress/Makefile 30 Mar 2016 06:38:45 - 1.22
+++ usr.bin/compress/Makefile 13 Oct 2022 19:33:57 -
@@ -1,7 +1,7 @@
# $OpenBSD: Makefile,v 1.22 2016/03/30 06:38:45 jmc Exp $
PROG= compress
-SRCS= main.c zopen.c gzopen.c nullopen.c
+SRCS= main.c zopen.c gzopen.c zipopen.c nullopen.c
MAN= compress.1 gzexe.1 gzip.1 zdiff.1 zforce.1 zmore.1 znew.1
LINKS= ${BINDIR}/compress ${BINDIR}/uncompress \
${BINDIR}/compress ${BINDIR}/zcat \
Index: usr.bin/compress/compress.h
===
RCS file: /cvs/src/usr.bin/compress/compress.h,v
retrieving revision 1.14
diff -u -p -u -r1.14 compress.h
--- usr.bin/compress/compress.h 18 Jan 2021 00:46:58 - 1.14
+++ usr.bin/compress/compress.h 13 Oct 2022 19:34:49 -
@@ -65,13 +65,16 @@ extern int zread(void *, char *, int);
extern int zwrite(void *, const char *, int);
extern int z_close(void *, struct z_info *, const char *, struct stat *);
-
extern void *gz_ropen(int, char *, int);
extern void *gz_wopen(int, char *, int, u_int32_t);
extern int gz_read(void *, char *, int);
extern int gz_write(void *, const char *, int);
extern int gz_close(void *, struct z_info *, const char *, struct stat *);
extern int gz_flush(void *, int);
+
+extern void *zip_ropen(int, char *, int);
+extern int zip_read(void *, char *, int);
+extern int zip_close(void *, struct z_info *, const char *, struct stat *);
extern void *null_ropen(int, char *, int);
extern void *null_wopen(int, char *, int, u_int32_t);
Index: usr.bin/compress/gzip.1
===
RCS file: /cvs/src/usr.bin/compress/gzip.1,v
retrieving revision 1.15
diff -u -p -u -r1.15 gzip.1
--- usr.bin/compress/gzip.1 14 Mar 2022 21:52:08 - 1.15
+++ usr.bin/compress/gzip.1 14 Oct 2022 00:04:57 -
@@ -83,10 +83,11 @@ utility restores compressed files to the
files by removing the extension (or by using the stored name if the
.Fl N
flag is specified).
-It has the ability to restore files compressed by both
-.Nm
+It has the ability to restore files compressed by
+.Nm ,
+.Xr compress 1
and
-.Xr compress 1 ,
+.Xr zip 1 ,
recognising the following extensions:
.Dq .Z ,
.Dq -Z ,
@@ -99,14 +100,23 @@ recognising the following extensions:
.Dq _tgz ,
.Dq .taz ,
.Dq -taz ,
+.Dq _taz ,
+.Dq .zip ,
+.Dq -zip
and
-.Dq _taz .
+.Dq _zip .
Extensions ending in
.Dq tgz
and
.Dq taz
are not removed when decompressing, instead they are converted to
.Dq tar .
+Files in zip format are only supported if they contain a single member
+compressed with either the
+.Em deflate
+or
+.Em store
+(uncompressed) method.
.Pp
The
.Nm gzcat
Index: usr.bin/compress/main.c
===
RCS file: /cvs/src/usr.bin/compress/main.c,v
retrieving revision 1.101
diff -u -p -u -r1.101 main.c
--- usr.bin/compress/main.c 29 Aug 2022 19:42:01 - 1.101
+++ usr.bin/compress/main.c 14 Oct 2022 00:31:14 -
@@ -102,6 +102,20 @@ const struct compressor {
zwrite,
z_close
},
+#define M_UNZIP (_table[2])
+ {
+ "unzip",
+ ".zip",
+ "PK",
+ NULL,
+ "cfhkLlNno:qrtVv",
+ "fhqr",
+ zip_ropen,
+ zip_read,
+ NULL,
+ NULL,
+ zip_close
+ },
#endif /* SMALL */
{ NULL }
};
@@ -725,10 +739,21 @@
Re: gunzip: support .zip files with a single member
On Fri, 14 Oct 2022 10:26:33 +1100, Jonathan Gray wrote: > I can't think of another reason for the single file limit. It must be. > > With most of the changes under SMALL or not built, ramdisks still fit? It should, none of the new code is compiled for the ramdisk version. - todd
Re: gunzip: support .zip files with a single member
On Fri, Oct 14, 2022 at 09:41:18AM +1100, Jonathan Gray wrote: > On Thu, Oct 13, 2022 at 02:14:28PM -0600, Todd C. Miller wrote: > > GNU gzip support uncompressing .zip files that contain a single > > member. This can be very convenient when dealing with email > > attachments that use zip instead of gzip to compress a single file > > (I'm looking at you Google). Below is a diff to support this with > > our gzip. This turned out to be more complicated than I expected > > simply due to the number of zip extended header fields. > > > > If there is more than a single file in the .zip we extract the first > > one but leave the origin .zip file alone. I made some minor tweaks > > to main.c to support this. We now only remove the output file if > > error is set to FAILURE, not WARNING. This has the side effect > > that the output file is no longer removed simply due to a crc error, > > which I think is an improvement. > > > > Comments or OKs? > > The extracted file has the name of the zip archive without '.zip' > instead of the name of the file in the zip archive. > > Is that the behaviour of GNU gunzip? It isn't what I expected. I can't think of another reason for the single file limit. It must be. With most of the changes under SMALL or not built, ramdisks still fit?
Re: gunzip: support .zip files with a single member
On Fri, 14 Oct 2022 09:41:18 +1100, Jonathan Gray wrote: > The extracted file has the name of the zip archive without '.zip' > instead of the name of the file in the zip archive. > > Is that the behaviour of GNU gunzip? It isn't what I expected. Yes, that is what GNU zip does too. If you use the -N flag gunzip will use the stored and (and mtime). - todd
Re: gunzip: support .zip files with a single member
On Thu, Oct 13, 2022 at 02:14:28PM -0600, Todd C. Miller wrote:
> GNU gzip support uncompressing .zip files that contain a single
> member. This can be very convenient when dealing with email
> attachments that use zip instead of gzip to compress a single file
> (I'm looking at you Google). Below is a diff to support this with
> our gzip. This turned out to be more complicated than I expected
> simply due to the number of zip extended header fields.
>
> If there is more than a single file in the .zip we extract the first
> one but leave the origin .zip file alone. I made some minor tweaks
> to main.c to support this. We now only remove the output file if
> error is set to FAILURE, not WARNING. This has the side effect
> that the output file is no longer removed simply due to a crc error,
> which I think is an improvement.
>
> Comments or OKs?
The extracted file has the name of the zip archive without '.zip'
instead of the name of the file in the zip archive.
Is that the behaviour of GNU gunzip? It isn't what I expected.
>
> - todd
>
> Index: usr.bin/compress/Makefile
> ===
> RCS file: /cvs/src/usr.bin/compress/Makefile,v
> retrieving revision 1.22
> diff -u -p -u -r1.22 Makefile
> --- usr.bin/compress/Makefile 30 Mar 2016 06:38:45 - 1.22
> +++ usr.bin/compress/Makefile 13 Oct 2022 19:33:57 -
> @@ -1,7 +1,7 @@
> #$OpenBSD: Makefile,v 1.22 2016/03/30 06:38:45 jmc Exp $
>
> PROG=compress
> -SRCS=main.c zopen.c gzopen.c nullopen.c
> +SRCS=main.c zopen.c gzopen.c zipopen.c nullopen.c
> MAN= compress.1 gzexe.1 gzip.1 zdiff.1 zforce.1 zmore.1 znew.1
> LINKS= ${BINDIR}/compress ${BINDIR}/uncompress \
> ${BINDIR}/compress ${BINDIR}/zcat \
> Index: usr.bin/compress/compress.h
> ===
> RCS file: /cvs/src/usr.bin/compress/compress.h,v
> retrieving revision 1.14
> diff -u -p -u -r1.14 compress.h
> --- usr.bin/compress/compress.h 18 Jan 2021 00:46:58 - 1.14
> +++ usr.bin/compress/compress.h 13 Oct 2022 19:34:49 -
> @@ -65,13 +65,16 @@ extern int zread(void *, char *, int);
> extern int zwrite(void *, const char *, int);
> extern int z_close(void *, struct z_info *, const char *, struct stat *);
>
> -
> extern void *gz_ropen(int, char *, int);
> extern void *gz_wopen(int, char *, int, u_int32_t);
> extern int gz_read(void *, char *, int);
> extern int gz_write(void *, const char *, int);
> extern int gz_close(void *, struct z_info *, const char *, struct stat *);
> extern int gz_flush(void *, int);
> +
> +extern void *zip_ropen(int, char *, int);
> +extern int zip_read(void *, char *, int);
> +extern int zip_close(void *, struct z_info *, const char *, struct stat *);
>
> extern void *null_ropen(int, char *, int);
> extern void *null_wopen(int, char *, int, u_int32_t);
> Index: usr.bin/compress/gzip.1
> ===
> RCS file: /cvs/src/usr.bin/compress/gzip.1,v
> retrieving revision 1.15
> diff -u -p -u -r1.15 gzip.1
> --- usr.bin/compress/gzip.1 14 Mar 2022 21:52:08 - 1.15
> +++ usr.bin/compress/gzip.1 13 Oct 2022 19:42:41 -
> @@ -83,10 +83,11 @@ utility restores compressed files to the
> files by removing the extension (or by using the stored name if the
> .Fl N
> flag is specified).
> -It has the ability to restore files compressed by both
> -.Nm
> +It has the ability to restore files compressed by
> +.Nm ,
> +.Xr compress 1
> and
> -.Xr compress 1 ,
> +.Xr zip 1 ,
> recognising the following extensions:
> .Dq .Z ,
> .Dq -Z ,
> @@ -99,14 +100,23 @@ recognising the following extensions:
> .Dq _tgz ,
> .Dq .taz ,
> .Dq -taz ,
> +.Dq _taz ,
> +.Dq .zip ,
> +.Dq -zip
> and
> -.Dq _taz .
> +.Dq _zip .
> Extensions ending in
> .Dq tgz
> and
> .Dq taz
> are not removed when decompressing, instead they are converted to
> .Dq tar .
> +Files in zip format are only supported if they contain a single member
> +compressed with either the
> +.Em deflate
> +or
> +.Em store
> +(uncompressed) method.
> .Pp
> The
> .Nm gzcat
> Index: usr.bin/compress/main.c
> ===
> RCS file: /cvs/src/usr.bin/compress/main.c,v
> retrieving revision 1.101
> diff -u -p -u -r1.101 main.c
> --- usr.bin/compress/main.c 29 Aug 2022 19:42:01 - 1.101
> +++ usr.bin/compress/main.c 13 Oct 2022 19:44:45 -
> @@ -102,6 +102,19 @@ const struct compressor {
> zwrite,
> z_close
> },
> + {
> + "unzip",
> + ".zip",
> + "PK",
> + NULL,
> + "cfhkLlNno:qrtVv",
> + "fhqr",
> + zip_ropen,
> + zip_read,
> + NULL,
> + NULL,
> + zip_close
> + },
> #endif /* SMALL */
>{ NULL }
> };
> @@ -725,10
rc.d: dhcpleased, rad: add configtest
Two more easy cases.
rad(8) requires a config file and there is no default /etc/rad.conf, so
configtest will fail unless a valid config (behind -f in rad_flags) exists.
dhcpleased(8) is happy without config at all, so configtest is always happy
unless a bogus config exists.
OK?
Index: dhcpleased
===
RCS file: /cvs/src/etc/rc.d/dhcpleased,v
retrieving revision 1.1
diff -u -p -r1.1 dhcpleased
--- dhcpleased 26 Feb 2021 17:18:41 - 1.1
+++ dhcpleased 13 Oct 2022 20:24:43 -
@@ -6,6 +6,11 @@ daemon="/sbin/dhcpleased"
. /etc/rc.d/rc.subr
+rc_configtest() {
+ # use rc_exec here since daemon_flags may contain arguments with spaces
+ rc_exec "${daemon} -n ${daemon_flags}"
+}
+
rc_reload=NO
rc_cmd $1
Index: rad
===
RCS file: /cvs/src/etc/rc.d/rad,v
retrieving revision 1.1
diff -u -p -r1.1 rad
--- rad 12 Jul 2018 08:20:36 - 1.1
+++ rad 13 Oct 2022 20:20:34 -
@@ -6,4 +6,9 @@ daemon="/usr/sbin/rad"
. /etc/rc.d/rc.subr
+rc_configtest() {
+ # use rc_exec here since daemon_flags may contain arguments with spaces
+ rc_exec "${daemon} -n ${daemon_flags}"
+}
+
rc_cmd $1
gunzip: support .zip files with a single member
GNU gzip support uncompressing .zip files that contain a single
member. This can be very convenient when dealing with email
attachments that use zip instead of gzip to compress a single file
(I'm looking at you Google). Below is a diff to support this with
our gzip. This turned out to be more complicated than I expected
simply due to the number of zip extended header fields.
If there is more than a single file in the .zip we extract the first
one but leave the origin .zip file alone. I made some minor tweaks
to main.c to support this. We now only remove the output file if
error is set to FAILURE, not WARNING. This has the side effect
that the output file is no longer removed simply due to a crc error,
which I think is an improvement.
Comments or OKs?
- todd
Index: usr.bin/compress/Makefile
===
RCS file: /cvs/src/usr.bin/compress/Makefile,v
retrieving revision 1.22
diff -u -p -u -r1.22 Makefile
--- usr.bin/compress/Makefile 30 Mar 2016 06:38:45 - 1.22
+++ usr.bin/compress/Makefile 13 Oct 2022 19:33:57 -
@@ -1,7 +1,7 @@
# $OpenBSD: Makefile,v 1.22 2016/03/30 06:38:45 jmc Exp $
PROG= compress
-SRCS= main.c zopen.c gzopen.c nullopen.c
+SRCS= main.c zopen.c gzopen.c zipopen.c nullopen.c
MAN= compress.1 gzexe.1 gzip.1 zdiff.1 zforce.1 zmore.1 znew.1
LINKS= ${BINDIR}/compress ${BINDIR}/uncompress \
${BINDIR}/compress ${BINDIR}/zcat \
Index: usr.bin/compress/compress.h
===
RCS file: /cvs/src/usr.bin/compress/compress.h,v
retrieving revision 1.14
diff -u -p -u -r1.14 compress.h
--- usr.bin/compress/compress.h 18 Jan 2021 00:46:58 - 1.14
+++ usr.bin/compress/compress.h 13 Oct 2022 19:34:49 -
@@ -65,13 +65,16 @@ extern int zread(void *, char *, int);
extern int zwrite(void *, const char *, int);
extern int z_close(void *, struct z_info *, const char *, struct stat *);
-
extern void *gz_ropen(int, char *, int);
extern void *gz_wopen(int, char *, int, u_int32_t);
extern int gz_read(void *, char *, int);
extern int gz_write(void *, const char *, int);
extern int gz_close(void *, struct z_info *, const char *, struct stat *);
extern int gz_flush(void *, int);
+
+extern void *zip_ropen(int, char *, int);
+extern int zip_read(void *, char *, int);
+extern int zip_close(void *, struct z_info *, const char *, struct stat *);
extern void *null_ropen(int, char *, int);
extern void *null_wopen(int, char *, int, u_int32_t);
Index: usr.bin/compress/gzip.1
===
RCS file: /cvs/src/usr.bin/compress/gzip.1,v
retrieving revision 1.15
diff -u -p -u -r1.15 gzip.1
--- usr.bin/compress/gzip.1 14 Mar 2022 21:52:08 - 1.15
+++ usr.bin/compress/gzip.1 13 Oct 2022 19:42:41 -
@@ -83,10 +83,11 @@ utility restores compressed files to the
files by removing the extension (or by using the stored name if the
.Fl N
flag is specified).
-It has the ability to restore files compressed by both
-.Nm
+It has the ability to restore files compressed by
+.Nm ,
+.Xr compress 1
and
-.Xr compress 1 ,
+.Xr zip 1 ,
recognising the following extensions:
.Dq .Z ,
.Dq -Z ,
@@ -99,14 +100,23 @@ recognising the following extensions:
.Dq _tgz ,
.Dq .taz ,
.Dq -taz ,
+.Dq _taz ,
+.Dq .zip ,
+.Dq -zip
and
-.Dq _taz .
+.Dq _zip .
Extensions ending in
.Dq tgz
and
.Dq taz
are not removed when decompressing, instead they are converted to
.Dq tar .
+Files in zip format are only supported if they contain a single member
+compressed with either the
+.Em deflate
+or
+.Em store
+(uncompressed) method.
.Pp
The
.Nm gzcat
Index: usr.bin/compress/main.c
===
RCS file: /cvs/src/usr.bin/compress/main.c,v
retrieving revision 1.101
diff -u -p -u -r1.101 main.c
--- usr.bin/compress/main.c 29 Aug 2022 19:42:01 - 1.101
+++ usr.bin/compress/main.c 13 Oct 2022 19:44:45 -
@@ -102,6 +102,19 @@ const struct compressor {
zwrite,
z_close
},
+ {
+ "unzip",
+ ".zip",
+ "PK",
+ NULL,
+ "cfhkLlNno:qrtVv",
+ "fhqr",
+ zip_ropen,
+ zip_read,
+ NULL,
+ NULL,
+ zip_close
+ },
#endif /* SMALL */
{ NULL }
};
@@ -725,10 +738,18 @@ dodecompress(const char *in, char *out,
error = errno == EINVAL ? WARNING : FAILURE;
}
- if (method->close(cookie, , NULL, NULL)) {
- if (!error && verbose >= 0)
- warnx("%s", in);
- error = FAILURE;
+ if (method->close(cookie, , NULL, NULL) && !error) {
+ if (errno == EEXIST) {
+ if (verbose >= 0) {
+ warnx("more than one entry in %s:
Re: ps.1: control terminal -> controlling terminal
Index: bin/ps/ps.1 === RCS file: /cvs/src/bin/ps/ps.1,v retrieving revision 1.128 diff -u -p -r1.128 ps.1 --- bin/ps/ps.1 3 Sep 2022 15:59:04 - 1.128 +++ bin/ps/ps.1 13 Oct 2022 17:05:57 - @@ -443,7 +443,8 @@ information: .Pp .Bl -tag -width indent -compact .It + -The process is in the foreground process group of its control terminal. +The process is in the foreground process group of its controlling +terminal. .It \*(Lt The process has a raised CPU scheduling priority (see @@ -508,7 +509,7 @@ Saved GID from a setgid executable. .It Cm svuid Saved UID from a setuid executable. .It Cm tdev -Control terminal device number. +Controlling terminal device number. .It Cm tid Thread ID. Used together with @@ -518,11 +519,11 @@ Alias: .Cm cputime . Accumulated CPU time, user + system. .It Cm tpgid -Control terminal process group ID. +Controlling terminal process group ID. .\".It trss .\"Text resident set size, in Kilobytes. .It Cm tsess -Control terminal session pointer. +Controlling terminal session pointer. .It Cm tsiz Text size, in Kilobytes. .It Cm tt @@ -536,7 +537,7 @@ This is followed by a if the process can no longer reach that controlling terminal (i.e. it has been revoked). .It Cm tty -Full name of control terminal. +Full name of controlling terminal. .It Cm ucomm Alias: .Cm comm . Index: lib/libc/compat-43/sigvec.3 === RCS file: /cvs/src/lib/libc/compat-43/sigvec.3,v retrieving revision 1.36 diff -u -p -r1.36 sigvec.3 --- lib/libc/compat-43/sigvec.3 31 Mar 2022 17:27:15 - 1.36 +++ lib/libc/compat-43/sigvec.3 13 Oct 2022 17:06:02 - @@ -243,8 +243,8 @@ with names as in the include file .It Dv SIGTSTP Ta "stop process" Ta "stop signal generated from keyboard" .It Dv SIGCONT Ta "discard signal" Ta "continue after stop" .It Dv SIGCHLD Ta "discard signal" Ta "child status has changed" -.It Dv SIGTTIN Ta "stop process" Ta "background read attempted from control terminal" -.It Dv SIGTTOU Ta "stop process" Ta "background write attempted to control terminal" +.It Dv SIGTTIN Ta "stop process" Ta "background read attempted from controlling terminal" +.It Dv SIGTTOU Ta "stop process" Ta "background write attempted to controlling terminal" .It Dv SIGIO Ta "discard signal" Ta "I/O is possible on a descriptor (see" .Xr fcntl 2 ) .It Dv SIGXCPU Ta "terminate process" Ta "CPU time limit exceeded (see" Index: lib/libc/gen/signal.3 === RCS file: /cvs/src/lib/libc/gen/signal.3,v retrieving revision 1.56 diff -u -p -r1.56 signal.3 --- lib/libc/gen/signal.3 1 Aug 2017 14:57:02 - 1.56 +++ lib/libc/gen/signal.3 13 Oct 2022 17:06:02 - @@ -76,12 +76,12 @@ typing the character. .Pp Signals are used when a process is stopped because it wishes to access -its control terminal while in the background (see +its controlling terminal while in the background (see .Xr tty 4 ) . Signals are optionally generated when a process resumes after being stopped, when the status of child processes changes, -or when input is ready at the control terminal. +or when input is ready at the controlling terminal. Most signals result in the termination of the process receiving them if no action is taken; some signals instead cause the process receiving them @@ -120,8 +120,8 @@ These signals are defined in the file .It Dv SIGTSTP Ta "stop process" Ta "stop signal generated from keyboard" .It Dv SIGCONT Ta "discard signal" Ta "continue after stop" .It Dv SIGCHLD Ta "discard signal" Ta "child status has changed" -.It Dv SIGTTIN Ta "stop process" Ta "background read attempted from control terminal" -.It Dv SIGTTOU Ta "stop process" Ta "background write attempted to control terminal" +.It Dv SIGTTIN Ta "stop process" Ta "background read attempted from controlling terminal" +.It Dv SIGTTOU Ta "stop process" Ta "background write attempted to controlling terminal" .It Dv SIGIO Ta "discard signal" Ta "I/O is possible on a descriptor (see" .Xr fcntl 2 ) .It Dv SIGXCPU Ta "terminate process" Ta "CPU time limit exceeded (see" Index: lib/libc/gen/ttyname.3 === RCS file: /cvs/src/lib/libc/gen/ttyname.3,v retrieving revision 1.19 diff -u -p -r1.19 ttyname.3 --- lib/libc/gen/ttyname.3 12 Nov 2013 05:12:15 - 1.19 +++ lib/libc/gen/ttyname.3 13 Oct 2022 17:06:02 - @@ -94,7 +94,8 @@ The maximum length of the terminal name .Pp The .Fn ttyslot -function fetches the current process's control terminal number from the +function fetches the current process's controlling terminal number from +the .Xr ttys 5 file entry. .Sh RETURN VALUES Index: lib/libc/sys/execve.2 === RCS file: /cvs/src/lib/libc/sys/execve.2,v retrieving revision
Re: ps.1: control terminal -> controlling terminal
On Thu, 13 Oct 2022 14:21:11 +0100, Jason McIntyre wrote: > hi. i'm not super up on the terminology here, but i do see we still have > other pages that talk about "control terminal". if any developer wants > to signal a clear desire to make such changes we can do that. The current term is "controlling terminal". I would support a diff to update this in all the man pages. - todd
Re: cwm: do not overlap menu entries
On Oct 13 2022, Walter Alejandro Iglesias wrote: > On Oct 13 2022, Klemens Nanni wrote: > > On Thu, Oct 13, 2022 at 08:28:50AM -0400, Okan Demirmen wrote: > > > And I keep missing it! I can't reproduce this - can you share the font > > > you're using maybe? > > > > Whatever is the default, I never fiddled with fonts in X, no xorg.conf, > > `cwm -c/dev/null' shows the glitch for me on a ThinkPad X230. > > > > > > In my case I can reproduce it with TrueType fonts (eg DejaVu Monospace), Not with all truetype fonts and sizes. It depends on how each font distributes vertical space (especially below). Here some fonts and sizes I can reproduce the issue: DejaVu Monospace 15 or 18 FreeMono 15 or 18 Liberation Mono all sizes Liberation Mono is the most affected because is the less vertically centered. -- Walter
Re: cwm: do not overlap menu entries
On Oct 13 2022, Klemens Nanni wrote: > On Thu, Oct 13, 2022 at 08:28:50AM -0400, Okan Demirmen wrote: > > And I keep missing it! I can't reproduce this - can you share the font > > you're using maybe? > > Whatever is the default, I never fiddled with fonts in X, no xorg.conf, > `cwm -c/dev/null' shows the glitch for me on a ThinkPad X230. > > In my case I can reproduce it with TrueType fonts (eg DejaVu Monospace), with bitmap fonts (eg Fixed) doesn't happen. I observe the overlapping in any menu, not only the windows one. Months ago I tried to fix this issue playing with the "height + 1" values, but since all cwm patches I been sending lately were ignored I lost interest. By the way, I'm glad Okan is still alive. :-) -- Walter
Re: cwm: do not overlap menu entries
On 2022/10/13 15:16:47 +, Klemens Nanni wrote: > On Thu, Oct 13, 2022 at 04:39:04PM +0200, Omar Polo wrote: > > On 2022/10/13 13:00:34 +, Klemens Nanni wrote: > > > On Thu, Oct 13, 2022 at 08:28:50AM -0400, Okan Demirmen wrote: > > > > And I keep missing it! I can't reproduce this - can you share the font > > > > you're using maybe? > > > > > > Whatever is the default, I never fiddled with fonts in X, no xorg.conf, > > > `cwm -c/dev/null' shows the glitch for me on a ThinkPad X230. > > > > i can't reproduce it either, not with my normal cwmrc and nor with an > > empty one. However with your patch the selected menu entry seems to > > be... correctly sized? Without your patch the selected item seems to > > be slightly more tall and "touch" the numbers and the parens of the > > items below. > > That as well, at leat to my eye. > > Here are four screen shots from my X230 running `cwm -c /dev/null' > inside Xephyr, taken with `scrot -s -q 100' so I can select the area > without clicking into the window which would make cwm's menu disappear. > > "current-" and "patch-" mean cwm from current and with the +1 patch, > respectively. > > "top-bottom" and "bottom-top" mean that the cursor has been moved across > the menu top to bottom and bottom to top, respectively. > > current-bottom-top.png shows cropped "[]" chars in the second entry, > whereas current-top-bottom.png and patch-*.png do not. Ahhh, now i see that too. it's subtle but your screenshot clearly shows that the selected items hides the top row of fixes from the item belows it. I've never noticed it before 'cause the selected items here has a black background (due to my ~/.Xdefaults.), but it happens for me too. Actually, i get what it looks like a "pixel perfect" result by subtracting two instead of one from descent in menu.c, but i was just playing with it -- need to re-read that part more closely.
Re: cwm: do not overlap menu entries
On Thu, Oct 13, 2022 at 04:39:04PM +0200, Omar Polo wrote: > On 2022/10/13 13:00:34 +, Klemens Nanni wrote: > > On Thu, Oct 13, 2022 at 08:28:50AM -0400, Okan Demirmen wrote: > > > And I keep missing it! I can't reproduce this - can you share the font > > > you're using maybe? > > > > Whatever is the default, I never fiddled with fonts in X, no xorg.conf, > > `cwm -c/dev/null' shows the glitch for me on a ThinkPad X230. > > i can't reproduce it either, not with my normal cwmrc and nor with an > empty one. However with your patch the selected menu entry seems to > be... correctly sized? Without your patch the selected item seems to > be slightly more tall and "touch" the numbers and the parens of the > items below. That as well, at leat to my eye. Here are four screen shots from my X230 running `cwm -c /dev/null' inside Xephyr, taken with `scrot -s -q 100' so I can select the area without clicking into the window which would make cwm's menu disappear. "current-" and "patch-" mean cwm from current and with the +1 patch, respectively. "top-bottom" and "bottom-top" mean that the cursor has been moved across the menu top to bottom and bottom to top, respectively. current-bottom-top.png shows cropped "[]" chars in the second entry, whereas current-top-bottom.png and patch-*.png do not. current-bottom-top.png Description: Binary data current-top-bottom.png Description: Binary data patch-bottom-top.png Description: Binary data patch-top-bottom.png Description: Binary data
Re: cwm: do not overlap menu entries
On 2022/10/13 13:00:34 +, Klemens Nanni wrote: > On Thu, Oct 13, 2022 at 08:28:50AM -0400, Okan Demirmen wrote: > > And I keep missing it! I can't reproduce this - can you share the font > > you're using maybe? > > Whatever is the default, I never fiddled with fonts in X, no xorg.conf, > `cwm -c/dev/null' shows the glitch for me on a ThinkPad X230. i can't reproduce it either, not with my normal cwmrc and nor with an empty one. However with your patch the selected menu entry seems to be... correctly sized? Without your patch the selected item seems to be slightly more tall and "touch" the numbers and the parens of the items below.
TLSv1.3 PSK: Add initial NewSessionTicket parsing
This hangs a few bits off SSL_SESSION and populates them on receipt of a
NewSessionTicket. Since the current session may already be in the cache,
and as such should not be changed, we dup the session using a new
ssl_session_dup() and modify that one. I added an include_ticket
parameter which we could use if we should need the SSL_SESSION_dup() API.
The actual parse function is directly modeled after RFC 8446, section
4.6.1, with the EVP_Digest() for the session_id matching what's done in
ssl3_get_new_session_ticket().
As always with PHH messages, there is a bit of a DOS question. For now
the general rate limiting of 100 PHH messages per hour is all we have.
Index: ssl_locl.h
===
RCS file: /cvs/src/lib/libssl/ssl_locl.h,v
retrieving revision 1.427
diff -u -p -r1.427 ssl_locl.h
--- ssl_locl.h 2 Oct 2022 16:36:41 - 1.427
+++ ssl_locl.h 13 Oct 2022 13:21:17 -
@@ -507,6 +507,10 @@ struct ssl_session_st {
size_t tlsext_ticklen; /* Session ticket length */
uint32_t tlsext_tick_lifetime_hint; /* Session lifetime hint in
seconds */
+ /* RFC 8446 info */
+ uint32_t tlsext_tick_age_add;
+ struct tls13_secret resumption_master_secret;
+
CRYPTO_EX_DATA ex_data; /* application specific data */
/* These are used to make removal of session-ids more
@@ -1311,6 +1315,7 @@ int ssl_security_cert_chain(const SSL *s
int ssl_security_shared_group(const SSL *ssl, uint16_t group_id);
int ssl_security_supported_group(const SSL *ssl, uint16_t group_id);
+SSL_SESSION *ssl_session_dup(SSL_SESSION *src, int include_ticket);
int ssl_get_new_session(SSL *s, int session);
int ssl_get_prev_session(SSL *s, CBS *session_id, CBS *ext_block,
int *alert);
Index: ssl_sess.c
===
RCS file: /cvs/src/lib/libssl/ssl_sess.c,v
retrieving revision 1.118
diff -u -p -r1.118 ssl_sess.c
--- ssl_sess.c 2 Oct 2022 16:36:41 - 1.118
+++ ssl_sess.c 13 Oct 2022 13:21:17 -
@@ -222,6 +222,12 @@ SSL_SESSION_new(void)
return (NULL);
}
+ if (!tls13_secret_init(>resumption_master_secret, 256)) {
+ SSLerrorx(ERR_R_MALLOC_FAILURE);
+ free(ss);
+ return (NULL);
+ }
+
ss->verify_result = 1; /* avoid 0 (= X509_V_OK) just in case */
ss->references = 1;
ss->timeout = 60 * 5 + 4; /* 5 minutes 4 seconds timeout by default */
@@ -242,6 +248,108 @@ SSL_SESSION_new(void)
return (ss);
}
+SSL_SESSION *
+ssl_session_dup(SSL_SESSION *src, int include_ticket)
+{
+ SSL_SESSION *dest;
+ CBS cbs;
+
+ if ((dest = calloc(1, sizeof(*dest))) == NULL) {
+ SSLerrorx(ERR_R_MALLOC_FAILURE);
+ goto err;
+ }
+
+ if (!tls13_secret_init(>resumption_master_secret, 256)) {
+ SSLerrorx(ERR_R_MALLOC_FAILURE);
+ goto err;
+ }
+
+ CBS_init(, src->master_key, src->master_key_length);
+ if (!CBS_write_bytes(, dest->master_key, sizeof(dest->master_key),
+ >master_key_length))
+ goto err;
+
+ CBS_init(, src->session_id, src->session_id_length);
+ if (!CBS_write_bytes(, dest->session_id, sizeof(dest->session_id),
+ >session_id_length))
+ goto err;
+
+ CBS_init(, src->sid_ctx, src->sid_ctx_length);
+ if (!CBS_write_bytes(, dest->sid_ctx, sizeof(dest->sid_ctx),
+ >sid_ctx_length))
+ goto err;
+
+ if (src->peer_cert != NULL) {
+ if (!X509_up_ref(src->peer_cert))
+ goto err;
+ dest->peer_cert = src->peer_cert;
+ }
+ dest->peer_cert_type = src->peer_cert_type;
+
+ dest->verify_result = src->verify_result;
+
+ dest->timeout = src->timeout;
+ dest->time = src->time;
+ dest->references = 1;
+
+ dest->cipher = src->cipher;
+ dest->cipher_id = src->cipher_id;
+
+ if (src->ciphers != NULL) {
+ if ((dest->ciphers = sk_SSL_CIPHER_dup(src->ciphers)) == NULL)
+ goto err;
+ }
+
+ if (include_ticket) {
+ if (src->tlsext_tick != NULL) {
+ CBS_init(, src->tlsext_tick, src->tlsext_ticklen);
+ if (!CBS_stow(, >tlsext_tick,
+ >tlsext_ticklen))
+ goto err;
+ dest->tlsext_tick_lifetime_hint =
+ src->tlsext_tick_lifetime_hint;
+ }
+
+ /* XXX - include TLSv1.3 NST here? */
+ }
+
+ if (!CRYPTO_new_ex_data(CRYPTO_EX_INDEX_SSL_SESSION, dest,
+ >ex_data))
+ goto err;
+
+ if (!CRYPTO_dup_ex_data(CRYPTO_EX_INDEX_SSL_SESSION, >ex_data,
+ >ex_data))
+ goto err;
+
+ /* Omit
Re: aucat.1: Improve description
On Wed, Oct 12, 2022 at 08:51:10PM -0400, Josiah Frentsos wrote: > Index: aucat.1 > === > RCS file: /cvs/src/usr.bin/aucat/aucat.1,v > retrieving revision 1.117 > diff -u -p -r1.117 aucat.1 > --- aucat.1 7 Mar 2022 09:04:45 - 1.117 > +++ aucat.1 13 Oct 2022 00:49:47 - > @@ -19,7 +19,7 @@ > .Os > .Sh NAME > .Nm aucat > -.Nd audio files manipulation tool > +.Nd manipulate audio files > .Sh SYNOPSIS > .Nm aucat > .Op Fl dn > i think i prefer it as-is. it says what it is, not what it does. i might be inclined to shave the "s" off "files" though... jmc
Re: ps.1: control terminal -> controlling terminal
On Tue, Oct 11, 2022 at 07:23:45PM -0400, Josiah Frentsos wrote: > Index: ps.1 > === > RCS file: /cvs/src/bin/ps/ps.1,v > retrieving revision 1.128 > diff -u -p -r1.128 ps.1 > --- ps.1 3 Sep 2022 15:59:04 - 1.128 > +++ ps.1 11 Oct 2022 23:20:34 - > @@ -443,7 +443,8 @@ information: > .Pp > .Bl -tag -width indent -compact > .It + > -The process is in the foreground process group of its control terminal. > +The process is in the foreground process group of its controlling > +terminal. hi. i'm not super up on the terminology here, but i do see we still have other pages that talk about "control terminal". if any developer wants to signal a clear desire to make such changes we can do that. jmc > .It \*(Lt > The process has a raised CPU > scheduling priority (see > @@ -508,7 +509,7 @@ Saved GID from a setgid executable. > .It Cm svuid > Saved UID from a setuid executable. > .It Cm tdev > -Control terminal device number. > +Controlling terminal device number. > .It Cm tid > Thread ID. > Used together with > @@ -518,11 +519,11 @@ Alias: > .Cm cputime . > Accumulated CPU time, user + system. > .It Cm tpgid > -Control terminal process group ID. > +Controlling terminal process group ID. > .\".It trss > .\"Text resident set size, in Kilobytes. > .It Cm tsess > -Control terminal session pointer. > +Controlling terminal session pointer. > .It Cm tsiz > Text size, in Kilobytes. > .It Cm tt > @@ -536,7 +537,7 @@ This is followed by a > if the process can no longer reach that > controlling terminal (i.e. it has been revoked). > .It Cm tty > -Full name of control terminal. > +Full name of controlling terminal. > .It Cm ucomm > Alias: > .Cm comm . >
Re: cwm: do not overlap menu entries
On Thu, Oct 13, 2022 at 08:28:50AM -0400, Okan Demirmen wrote: > And I keep missing it! I can't reproduce this - can you share the font > you're using maybe? Whatever is the default, I never fiddled with fonts in X, no xorg.conf, `cwm -c/dev/null' shows the glitch for me on a ThinkPad X230.
Re: mg: add zap-to-char and zap-up-to-char
On 2022/10/13 13:35:18 +0200, Florian Obser wrote:
> On 2022-10-13 12:16 +02, Omar Polo wrote:
> > small quality-of-life addition. GNU Emacs has zap-to-char bound by to
> > M-z and zap-up-to-char unbound; i'm unsure how closely we want to
> > follow emacs here, IMHO zap-up-to-char is way more useful than
> > zap-to-char and so i opted to bound M-z to zap-up-to-char by default.
>
> I always tried to stay as close to emacs as possible. I'd consider it a
> bug otherwise. So I think you should bind zap-to-char per default and
> override it in your startup file.
agreed, i can carry an extra global-set-key in my ~/.mg :)
> emacs also has this: "Goes backward if ARG is negative"
>
> Could you implement that, or at least check that n is not negative?
Arrggg, right, I forgot that the prefix argument can be negative or
zero. Here's another attempt that handles it too.
The only difference I can spot with emacs now is that zap-to-char
alters `pat' so C-s C-s (resuming isearch) uses the character set by
zap.
thanks!
diff 40c942665e2a6e73653062386b61f09373477e3d
768e3c8d03fa68b2a6a27077e22e96a41f8a57b6
commit - 40c942665e2a6e73653062386b61f09373477e3d
commit + 768e3c8d03fa68b2a6a27077e22e96a41f8a57b6
blob - d546dba15dd5b45503679454fbe55673640ea74e
blob + 87704c129ee172c2f504741d534df826cf77131d
--- usr.bin/mg/def.h
+++ usr.bin/mg/def.h
@@ -651,6 +651,9 @@ int readpattern(char *);
int forwsrch(void);
int backsrch(void);
int readpattern(char *);
+int zapuptochar(int, int);
+int zaptochar(int, int);
+int zap(int, int);
/* spawn.c X */
int spawncli(int, int);
blob - 36a88e4573d47eae4d321ee899f71e52ef77a8c9
blob + d9cb10a264955db8e6e77b8b8aa6352ed8db9bfd
--- usr.bin/mg/funmap.c
+++ usr.bin/mg/funmap.c
@@ -138,6 +138,8 @@ static struct funmap functnames[] = {
{killbuffer_cmd, "kill-buffer", 1},
{killline, "kill-line", 1},
{killpara, "kill-paragraph", 1},
+ {zaptochar, "zap-to-char", 1},
+ {zapuptochar, "zap-up-to-char", 1},
{killregion, "kill-region", 0},
{delfword, "kill-word", 1},
{toggleleavetmp, "leave-tmpdir-backups", 0},
blob - 32a9267d30fbbbc2f4fcc126133313cbc6799201
blob + 8cc8ac482f1ca345a0a6455649e4728d7946db93
--- usr.bin/mg/keymap.c
+++ usr.bin/mg/keymap.c
@@ -290,7 +290,7 @@ static PF metal[] = {
copyregion, /* w */
extend, /* x */
rescan, /* y */
- rescan, /* z */
+ zaptochar, /* z */
gotobop,/* { */
piperegion, /* | */
gotoeop /* } */
blob - a335c89e4d5329776a85c473c716b5e9e2597f19
blob + 6a910b7b1861aeeacab728e4139d5963d9ecaabd
--- usr.bin/mg/mg.1
+++ usr.bin/mg/mg.1
@@ -331,6 +331,8 @@ execute-extended-command
copy-region-as-kill
.It M-x
execute-extended-command
+.It M-z
+zap-to-char
.It M-{
backward-paragraph
.It M-|
@@ -986,6 +988,11 @@ It is not a ring.
kill buffer consists only
of the most recent kill.
It is not a ring.
+.It zap-to-char
+Ask for a character and delete text from the current cursor position
+until the next instance of that character, including it.
+.It zap-up-to-char
+Like zap-to-char but doesn't delete the target character.
.El
.Sh MG DIRED KEY BINDINGS
Specific key bindings are available in dired mode.
blob - fa12b4094aae01385711ca7b01c7eba964571e65
blob + 06cddf62221237bd4abe7c1772f0e6031bdb49ab
--- usr.bin/mg/search.c
+++ usr.bin/mg/search.c
@@ -853,3 +853,74 @@ readpattern(char *r_prompt)
retval = FALSE;
return (retval);
}
+
+/*
+ * Prompt for a character and kill until a it (including). Mark is
+ * cleared afterwards.
+ */
+int
+zaptochar(int f, int n)
+{
+ return (zap(TRUE, n));
+}
+
+/* Like zaptochar but stops before the character. */
+int
+zapuptochar(int f, int n)
+{
+ return (zap(FALSE, n));
+}
+
+/*
+ * Prompt for a charcter and deletes from the point up to, optionally
+ * including, the first instance of that charcters. Marks is cleared
+ * afterwards.
+ */
+int
+zap(int including, int n)
+{
+ int s, backward;
+
+ backward = n < 0;
+ if (backward)
+ n = -n;
+
+ if (including)
+ ewprintf("Zap to char: ");
+ else
+ ewprintf("Zap up to char: ");
+
+ s = getkey(FALSE);
+ eerase();
+ if (s == ABORT || s == CCHR('G'))
+ return (FALSE);
+
+ if (n == 0)
+ return (TRUE);
+
+ pat[0] = (char)s;
+ pat[1] = '\0';
+
+ isetmark();
+ while (n--) {
+ s = backward ? backsrch() : forwsrch();
+ if (s != TRUE) {
+ dobeep();
+ ewprintf("Search failed: \"%s\"", pat);
+ swapmark(FFARG, 0);
+ clearmark(FFARG, 0);
+ return
Re: ypldap TLS by default
On Thu, Oct 13, 2022 at 10:11:39PM +1000, Jonathan Matthew wrote:
> While working on ypconnect(2), Theo suggested that ypldap(8) should
> not default to plaintext LDAP connections, since the data it's dealing with
> is pretty important to the security of the system. Here's a straightforward
> diff implementing that, defaulting to what was previously called 'tls'
> (STARTTLS on port 389), and adding a 'notls' option for plaintext.
>
> ok? other opinions on what this option should be called?
Given TLS and STARTTLS, "plain" might be a tad clearer as "notls" could
still be understood as no-TLS-but-try-STARTTLS.
Given the existing "tls" and "ldaps" keywords, I thnk "ldap" would be
most clear and consistent.
> Index: parse.y
> ===
> RCS file: /cvs/src/usr.sbin/ypldap/parse.y,v
> retrieving revision 1.36
> diff -u -p -u -p -r1.36 parse.y
> --- parse.y 13 Oct 2022 04:55:33 - 1.36
> +++ parse.y 13 Oct 2022 08:13:21 -
> @@ -107,7 +107,7 @@ typedef struct {
> %token SERVER FILTER ATTRIBUTE BASEDN BINDDN GROUPDN BINDCRED MAPS
> CHANGE DOMAIN PROVIDE
> %token USER GROUP TO EXPIRE HOME SHELL GECOS UID GID INTERVAL
> %token PASSWD NAME FIXED LIST GROUPNAME GROUPPASSWD GROUPGID MAP
> -%token INCLUDE DIRECTORY CLASS PORT ERROR GROUPMEMBERS LDAPS TLS CAFILE
> +%token INCLUDE DIRECTORY CLASS PORT ERROR GROUPMEMBERS LDAPS TLS NOTLS
> CAFILE
> %token BIND LOCAL PORTMAP BINDEXT CERTFILE KEYFILE
> %token STRING
> %token NUMBER
> @@ -366,9 +366,10 @@ diropt : BINDDN STRING
> {
> }
> ;
>
> -ssl : /* empty */ { $$ = 0; }
> +ssl : /* empty */ { $$ = F_STARTTLS; }
> | LDAPS { $$ = F_SSL; }
> | TLS { $$ = F_STARTTLS; }
> + | NOTLS { $$ = 0; }
> ;
>
> directory: DIRECTORY STRING port ssl {
> @@ -556,6 +557,7 @@ lookup(char *s)
> { "map",MAP },
> { "maps", MAPS },
> { "name", NAME },
> + { "notls", NOTLS },
> { "passwd", PASSWD },
> { "port", PORT },
> { "portmap",PORTMAP },
> Index: ypldap.conf.5
> ===
> RCS file: /cvs/src/usr.sbin/ypldap/ypldap.conf.5,v
> retrieving revision 1.28
> diff -u -p -u -p -r1.28 ypldap.conf.5
> --- ypldap.conf.5 13 Oct 2022 04:55:33 - 1.28
> +++ ypldap.conf.5 13 Oct 2022 08:13:21 -
> @@ -119,15 +119,19 @@ directory are used to construct YP map e
> .Bl -tag -width Ds
> .It Ic directory Ar hostname Oo Ic port Ar port Oc Oo tls Oc Brq ...
> Defines a directory by hostname and optionally port number.
> -If the
> +The
> .Ar tls
> -argument is not specified, no transport-level security will be used.
> +argument specifies the transport-level security used for the connection.
> Valid options are:
> .Bl -tag -width Ds
> .It Ic tls
> -Use STARTTLS to negotiate TLS, by default on port 389.
> +Use STARTTLS to negotiate TLS on port 389 unless an alternate port is
> +specified.
> +This is the default.
> .It Ic ldaps
> -Connect with TLS enabled, by default on port 636.
> +Connect with TLS enabled on port 636 unless an alternate port is specified.
> +.It Ic notls
> +Connect with no transport-level security.
> .El
> .El
> .Pp
>
Re: cwm: do not overlap menu entries
On Wed 2022.10.12 at 21:42 +, Klemens Nanni wrote: > This has annoyed me for a long time... > > 1. have at least two windows > 2. open the window menu with M-slash (alt+/) > 3. show all windows with C-A (ctrl+a) > 4. move cursor over list from top to bottom, >observe no glitch > 5. move cursor over list from bottom to top, >observe "[" and "]" chars in entries being drawn over at the top, >i.e. upper entries overlap lower ones > > It's easy to miss but hard to unsee. And I keep missing it! I can't reproduce this - can you share the font you're using maybe? > Today I looked and came up with the following fix, drawing menu entries > without overlap. > > All these `height + 1' spread across seem off, but they seem consistent. > > Okan, is there a better way to fix this? > > > This is trivial to reproduce wihout messing with your running X: > > $ Xephyr :1 & > $ xterm -display 1 & > $ xterm -display 1 & > $ DISPLAY=:1 ./obj/cwm > > Then click on the background/root window to navigate the window menu. > > > Index: app/cwm/menu.c > === > RCS file: /cvs/xenocara/app/cwm/menu.c,v > retrieving revision 1.109 > diff -u -p -r1.109 menu.c > --- app/cwm/menu.c27 Feb 2020 14:56:39 - 1.109 > +++ app/cwm/menu.c12 Oct 2022 21:24:17 - > @@ -436,7 +436,7 @@ menu_draw_entry(struct menu_ctx *mc, str > color = (active) ? CWM_COLOR_MENU_FG : CWM_COLOR_MENU_BG; > XftDrawRect(mc->xftdraw, >xftcolor[color], 0, > (sc->xftfont->height + 1) * entry, mc->geom.w, > - (sc->xftfont->height + 1) + sc->xftfont->descent); > + (sc->xftfont->height + 1) + sc->xftfont->descent - 1); > color = (active) ? CWM_COLOR_MENU_FONT_SEL : CWM_COLOR_MENU_FONT; > XftDrawStringUtf8(mc->xftdraw, > >xftcolor[color], sc->xftfont,
ypldap TLS by default
While working on ypconnect(2), Theo suggested that ypldap(8) should
not default to plaintext LDAP connections, since the data it's dealing with
is pretty important to the security of the system. Here's a straightforward
diff implementing that, defaulting to what was previously called 'tls'
(STARTTLS on port 389), and adding a 'notls' option for plaintext.
ok? other opinions on what this option should be called?
Index: parse.y
===
RCS file: /cvs/src/usr.sbin/ypldap/parse.y,v
retrieving revision 1.36
diff -u -p -u -p -r1.36 parse.y
--- parse.y 13 Oct 2022 04:55:33 - 1.36
+++ parse.y 13 Oct 2022 08:13:21 -
@@ -107,7 +107,7 @@ typedef struct {
%token SERVER FILTER ATTRIBUTE BASEDN BINDDN GROUPDN BINDCRED MAPS CHANGE
DOMAIN PROVIDE
%token USER GROUP TO EXPIRE HOME SHELL GECOS UID GID INTERVAL
%token PASSWD NAME FIXED LIST GROUPNAME GROUPPASSWD GROUPGID MAP
-%token INCLUDE DIRECTORY CLASS PORT ERROR GROUPMEMBERS LDAPS TLS CAFILE
+%token INCLUDE DIRECTORY CLASS PORT ERROR GROUPMEMBERS LDAPS TLS NOTLS CAFILE
%token BIND LOCAL PORTMAP BINDEXT CERTFILE KEYFILE
%token STRING
%token NUMBER
@@ -366,9 +366,10 @@ diropt : BINDDN STRING
{
}
;
-ssl: /* empty */ { $$ = 0; }
+ssl: /* empty */ { $$ = F_STARTTLS; }
| LDAPS { $$ = F_SSL; }
| TLS { $$ = F_STARTTLS; }
+ | NOTLS { $$ = 0; }
;
directory : DIRECTORY STRING port ssl {
@@ -556,6 +557,7 @@ lookup(char *s)
{ "map",MAP },
{ "maps", MAPS },
{ "name", NAME },
+ { "notls", NOTLS },
{ "passwd", PASSWD },
{ "port", PORT },
{ "portmap",PORTMAP },
Index: ypldap.conf.5
===
RCS file: /cvs/src/usr.sbin/ypldap/ypldap.conf.5,v
retrieving revision 1.28
diff -u -p -u -p -r1.28 ypldap.conf.5
--- ypldap.conf.5 13 Oct 2022 04:55:33 - 1.28
+++ ypldap.conf.5 13 Oct 2022 08:13:21 -
@@ -119,15 +119,19 @@ directory are used to construct YP map e
.Bl -tag -width Ds
.It Ic directory Ar hostname Oo Ic port Ar port Oc Oo tls Oc Brq ...
Defines a directory by hostname and optionally port number.
-If the
+The
.Ar tls
-argument is not specified, no transport-level security will be used.
+argument specifies the transport-level security used for the connection.
Valid options are:
.Bl -tag -width Ds
.It Ic tls
-Use STARTTLS to negotiate TLS, by default on port 389.
+Use STARTTLS to negotiate TLS on port 389 unless an alternate port is
+specified.
+This is the default.
.It Ic ldaps
-Connect with TLS enabled, by default on port 636.
+Connect with TLS enabled on port 636 unless an alternate port is specified.
+.It Ic notls
+Connect with no transport-level security.
.El
.El
.Pp
Re: mg: add zap-to-char and zap-up-to-char
On 2022-10-13 12:16 +02, Omar Polo wrote:
> small quality-of-life addition. GNU Emacs has zap-to-char bound by to
> M-z and zap-up-to-char unbound; i'm unsure how closely we want to
> follow emacs here, IMHO zap-up-to-char is way more useful than
> zap-to-char and so i opted to bound M-z to zap-up-to-char by default.
I always tried to stay as close to emacs as possible. I'd consider it a
bug otherwise. So I think you should bind zap-to-char per default and
override it in your startup file.
emacs also has this: "Goes backward if ARG is negative"
Could you implement that, or at least check that n is not negative?
>
> ok?
>
> diff 40c942665e2a6e73653062386b61f09373477e3d
> b164b420ae16a7b218f9df51fb8c8a7ce8d5b054
> commit - 40c942665e2a6e73653062386b61f09373477e3d
> commit + b164b420ae16a7b218f9df51fb8c8a7ce8d5b054
> blob - d546dba15dd5b45503679454fbe55673640ea74e
> blob + 87704c129ee172c2f504741d534df826cf77131d
> --- usr.bin/mg/def.h
> +++ usr.bin/mg/def.h
> @@ -651,6 +651,9 @@ intreadpattern(char *);
> int forwsrch(void);
> int backsrch(void);
> int readpattern(char *);
> +int zapuptochar(int, int);
> +int zaptochar(int, int);
> +int zap(int, int);
>
> /* spawn.c X */
> int spawncli(int, int);
> blob - 36a88e4573d47eae4d321ee899f71e52ef77a8c9
> blob + d9cb10a264955db8e6e77b8b8aa6352ed8db9bfd
> --- usr.bin/mg/funmap.c
> +++ usr.bin/mg/funmap.c
> @@ -138,6 +138,8 @@ static struct funmap functnames[] = {
> {killbuffer_cmd, "kill-buffer", 1},
> {killline, "kill-line", 1},
> {killpara, "kill-paragraph", 1},
> + {zaptochar, "zap-to-char", 1},
> + {zapuptochar, "zap-up-to-char", 1},
> {killregion, "kill-region", 0},
> {delfword, "kill-word", 1},
> {toggleleavetmp, "leave-tmpdir-backups", 0},
> blob - 32a9267d30fbbbc2f4fcc126133313cbc6799201
> blob + 6e6b649f756b879127e1f22b8178fe529b7ced03
> --- usr.bin/mg/keymap.c
> +++ usr.bin/mg/keymap.c
> @@ -290,7 +290,7 @@ static PF metal[] = {
> copyregion, /* w */
> extend, /* x */
> rescan, /* y */
> - rescan, /* z */
> + zapuptochar,/* z */
> gotobop,/* { */
> piperegion, /* | */
> gotoeop /* } */
> blob - a335c89e4d5329776a85c473c716b5e9e2597f19
> blob + fd5a2df0f48d7966ca1d4467ccf16bd68caf4c5b
> --- usr.bin/mg/mg.1
> +++ usr.bin/mg/mg.1
> @@ -331,6 +331,8 @@ execute-extended-command
> copy-region-as-kill
> .It M-x
> execute-extended-command
> +.It M-z
> +zap-up-to-char
> .It M-{
> backward-paragraph
> .It M-|
> @@ -986,6 +988,11 @@ It is not a ring.
> kill buffer consists only
> of the most recent kill.
> It is not a ring.
> +.It zap-to-char
> +Ask for a character and delete text from the current cursor position
> +until the next instance of that character, including it.
> +.It zap-up-to-char
> +Like zap-to-char but doesn't delete the target character.
> .El
> .Sh MG DIRED KEY BINDINGS
> Specific key bindings are available in dired mode.
> blob - fa12b4094aae01385711ca7b01c7eba964571e65
> blob + e9184de33a7cd149fd521ba7d1c57310f3b16953
> --- usr.bin/mg/search.c
> +++ usr.bin/mg/search.c
> @@ -853,3 +853,61 @@ readpattern(char *r_prompt)
> retval = FALSE;
> return (retval);
> }
> +
> +/*
> + * Prompt for a character and kill until a it (including). Mark is
> + * cleared afterwards.
> + */
> +int
> +zaptochar(int f, int n)
> +{
> + return (zap(TRUE, n));
> +}
> +
> +/* Like zaptochar but stops before the character. */
> +int
> +zapuptochar(int f, int n)
> +{
> + return (zap(FALSE, n));
> +}
> +
> +/*
> + * Prompt for a charcter and deletes from the point up to, optionally
> + * including, the first instance of that charcters. Marks is cleared
> + * afterwards.
> + */
> +int
> +zap(int including, int n)
> +{
> + int s;
> +
> + if (including)
> + ewprintf("Zap to char: ");
> + else
> + ewprintf("Zap up to char: ");
> +
> + s = getkey(FALSE);
> + eerase();
> + if (s == ABORT || s == CCHR('G'))
> + return (FALSE);
> +
> + pat[0] = (char)s;
> + pat[1] = '\0';
> +
> + isetmark();
> + while (n--) {
> + if (forwsrch() == FALSE) {
> + dobeep();
> + ewprintf("Search failed: \"%s\"", pat);
> + swapmark(FFARG, 0);
> + clearmark(FFARG, 0);
> + return (FALSE);
> + }
> + }
> +
> + if (!including)
> + (void) backchar(FFARG, 1);
> + killregion(FFARG, 0);
> + clearmark(FFARG, 0);
> + return (TRUE);
> +}
>
>
--
I'm not entirely sure you are real.
mg: handle prefix argument in shell-command{,-on-region}
shell-command (M-!) and shell-command-on-region (M-|) works by
displaying the output of the command in a new buffer, but in emacs
using a prefix argument (C-u) allows to operate on the current buffer.
diff belows adds that for mg. I can finally C-u M-! got diff RET when
composing mails :)
A possible drawback is that now the *Shell Command Output* buffer
gains an undo history. linsert is also possibly slower than addline
but on the plus side we're no more limited to BUFSIZ long lines.
ok/comments/improvements?
diff b164b420ae16a7b218f9df51fb8c8a7ce8d5b054
96b4e7eb3a0369bac8e2ddc717e03b246d64bbfd
commit - b164b420ae16a7b218f9df51fb8c8a7ce8d5b054
commit + 96b4e7eb3a0369bac8e2ddc717e03b246d64bbfd
blob - 21c5174f52d21103b9cd15942620eb746b5069b2
blob + 2be40574f0d56645018f4c7cad49d547769ba79f
--- usr.bin/mg/region.c
+++ usr.bin/mg/region.c
@@ -26,14 +26,13 @@ static char leftover[BUFSIZ];
#define TIMEOUT 1
-static char leftover[BUFSIZ];
-
static int getregion(struct region *);
static int iomux(int, char * const, int, struct buffer *);
static int preadin(int, struct buffer *);
static voidpwriteout(int, char **, int *);
static int setsize(struct region *, RSIZE);
-static int shellcmdoutput(char * const[], char * const, int);
+static int shellcmdoutput(char * const[], char * const, int,
+ struct buffer *);
/*
* Kill the region. Ask "getregion" to figure out the bounds of the region.
@@ -419,14 +418,11 @@ piperegion(int f, int n)
piperegion(int f, int n)
{
struct region region;
+ struct buffer *bp = NULL;
int len;
char *cmd, cmdbuf[NFILEN], *text;
char *argv[] = {"sh", "-c", (char *) NULL, (char *) NULL};
- /* C-u M-| is not supported yet */
- if (n > 1)
- return (ABORT);
-
if (curwp->w_markp == NULL) {
dobeep();
ewprintf("The mark is not set now, so there is no region");
@@ -452,7 +448,13 @@ piperegion(int f, int n)
region_get_data(, text, len);
- return shellcmdoutput(argv, text, len);
+ if (n > 1) {
+ bp = curbp;
+ killregion(FFRAND, 1);
+ kdelete();
+ }
+
+ return (shellcmdoutput(argv, text, len, bp));
}
/*
@@ -462,12 +464,12 @@ shellcommand(int f, int n)
int
shellcommand(int f, int n)
{
-
+ struct buffer *bp = NULL;
char *cmd, cmdbuf[NFILEN];
char *argv[] = {"sh", "-c", (char *) NULL, (char *) NULL};
if (n > 1)
- return (ABORT);
+ bp = curbp;
if ((cmd = eread("Shell command: ", cmdbuf, sizeof(cmdbuf),
EFNEW | EFCR)) == NULL || (cmd[0] == '\0'))
@@ -475,36 +477,43 @@ shellcommand(int f, int n)
argv[2] = cmd;
- return shellcmdoutput(argv, NULL, 0);
+ return (shellcmdoutput(argv, NULL, 0, bp));
}
-
int
-shellcmdoutput(char* const argv[], char* const text, int len)
+shellcmdoutput(char* const argv[], char* const text, int len,
+struct buffer *bp)
{
-
- struct buffer *bp;
+ struct mgwin *wp;
char*shellp;
- int ret;
+ int ret, special = 0;
- bp = bfind("*Shell Command Output*", TRUE);
- bp->b_flag |= BFREADONLY;
- if (bclear(bp) != TRUE) {
- free(text);
- return (FALSE);
+ if (bp == NULL) {
+ special = 1;
+ bp = bfind("*Shell Command Output*", TRUE);
+ bp->b_flag &= ~BFREADONLY; /* disable read-only */
+ wp = popbuf(bp, WNONE);
+ if (wp == NULL || bclear(bp) != TRUE) {
+ free(text);
+ return (FALSE);
+ }
+ curbp = bp;
+ curwp = wp;
}
shellp = getenv("SHELL");
ret = pipeio(shellp, argv, text, len, bp);
-
if (ret == TRUE) {
eerase();
- if (lforw(bp->b_headp) == bp->b_headp)
+ if (special && lforw(bp->b_headp) == bp->b_headp)
addline(bp, "(Shell command succeeded with no output)");
}
free(text);
+
+ if (special)
+ bp->b_flag |= BFREADONLY; /* restore read-only */
return (ret);
}
@@ -551,7 +560,11 @@ pipeio(const char* const path, char* const argv[], cha
default:
/* Parent process */
close(s[1]);
+
+ undo_boundary_enable(FFRAND, 0);
ret = iomux(s[0], text, len, outbp);
+ undo_boundary_enable(FFRAND, 1);
+
waitpid(pid, NULL, 0); /* Collect child to prevent zombies */
return (ret);
@@ -596,13 +609,6 @@ iomux(int fd, char* const text, int len, struct buffer
}
close(fd);
- /* In case if last line doesn't have a '\n' add the leftover
-* characters to buffer.
-*/
- if
mg: add zap-to-char and zap-up-to-char
small quality-of-life addition. GNU Emacs has zap-to-char bound by to
M-z and zap-up-to-char unbound; i'm unsure how closely we want to
follow emacs here, IMHO zap-up-to-char is way more useful than
zap-to-char and so i opted to bound M-z to zap-up-to-char by default.
ok?
diff 40c942665e2a6e73653062386b61f09373477e3d
b164b420ae16a7b218f9df51fb8c8a7ce8d5b054
commit - 40c942665e2a6e73653062386b61f09373477e3d
commit + b164b420ae16a7b218f9df51fb8c8a7ce8d5b054
blob - d546dba15dd5b45503679454fbe55673640ea74e
blob + 87704c129ee172c2f504741d534df826cf77131d
--- usr.bin/mg/def.h
+++ usr.bin/mg/def.h
@@ -651,6 +651,9 @@ int readpattern(char *);
int forwsrch(void);
int backsrch(void);
int readpattern(char *);
+int zapuptochar(int, int);
+int zaptochar(int, int);
+int zap(int, int);
/* spawn.c X */
int spawncli(int, int);
blob - 36a88e4573d47eae4d321ee899f71e52ef77a8c9
blob + d9cb10a264955db8e6e77b8b8aa6352ed8db9bfd
--- usr.bin/mg/funmap.c
+++ usr.bin/mg/funmap.c
@@ -138,6 +138,8 @@ static struct funmap functnames[] = {
{killbuffer_cmd, "kill-buffer", 1},
{killline, "kill-line", 1},
{killpara, "kill-paragraph", 1},
+ {zaptochar, "zap-to-char", 1},
+ {zapuptochar, "zap-up-to-char", 1},
{killregion, "kill-region", 0},
{delfword, "kill-word", 1},
{toggleleavetmp, "leave-tmpdir-backups", 0},
blob - 32a9267d30fbbbc2f4fcc126133313cbc6799201
blob + 6e6b649f756b879127e1f22b8178fe529b7ced03
--- usr.bin/mg/keymap.c
+++ usr.bin/mg/keymap.c
@@ -290,7 +290,7 @@ static PF metal[] = {
copyregion, /* w */
extend, /* x */
rescan, /* y */
- rescan, /* z */
+ zapuptochar,/* z */
gotobop,/* { */
piperegion, /* | */
gotoeop /* } */
blob - a335c89e4d5329776a85c473c716b5e9e2597f19
blob + fd5a2df0f48d7966ca1d4467ccf16bd68caf4c5b
--- usr.bin/mg/mg.1
+++ usr.bin/mg/mg.1
@@ -331,6 +331,8 @@ execute-extended-command
copy-region-as-kill
.It M-x
execute-extended-command
+.It M-z
+zap-up-to-char
.It M-{
backward-paragraph
.It M-|
@@ -986,6 +988,11 @@ It is not a ring.
kill buffer consists only
of the most recent kill.
It is not a ring.
+.It zap-to-char
+Ask for a character and delete text from the current cursor position
+until the next instance of that character, including it.
+.It zap-up-to-char
+Like zap-to-char but doesn't delete the target character.
.El
.Sh MG DIRED KEY BINDINGS
Specific key bindings are available in dired mode.
blob - fa12b4094aae01385711ca7b01c7eba964571e65
blob + e9184de33a7cd149fd521ba7d1c57310f3b16953
--- usr.bin/mg/search.c
+++ usr.bin/mg/search.c
@@ -853,3 +853,61 @@ readpattern(char *r_prompt)
retval = FALSE;
return (retval);
}
+
+/*
+ * Prompt for a character and kill until a it (including). Mark is
+ * cleared afterwards.
+ */
+int
+zaptochar(int f, int n)
+{
+ return (zap(TRUE, n));
+}
+
+/* Like zaptochar but stops before the character. */
+int
+zapuptochar(int f, int n)
+{
+ return (zap(FALSE, n));
+}
+
+/*
+ * Prompt for a charcter and deletes from the point up to, optionally
+ * including, the first instance of that charcters. Marks is cleared
+ * afterwards.
+ */
+int
+zap(int including, int n)
+{
+ int s;
+
+ if (including)
+ ewprintf("Zap to char: ");
+ else
+ ewprintf("Zap up to char: ");
+
+ s = getkey(FALSE);
+ eerase();
+ if (s == ABORT || s == CCHR('G'))
+ return (FALSE);
+
+ pat[0] = (char)s;
+ pat[1] = '\0';
+
+ isetmark();
+ while (n--) {
+ if (forwsrch() == FALSE) {
+ dobeep();
+ ewprintf("Search failed: \"%s\"", pat);
+ swapmark(FFARG, 0);
+ clearmark(FFARG, 0);
+ return (FALSE);
+ }
+ }
+
+ if (!including)
+ (void) backchar(FFARG, 1);
+ killregion(FFARG, 0);
+ clearmark(FFARG, 0);
+ return (TRUE);
+}
Error on incorrect find -type argument.
Dear colleagues,
find's -type flag considers only the first character of the next
argument. These commands consequently print regular file paths (only).
find . -type folder
find . -type f,d
find . -type flødebølle
I propose that they produce an error instead.
I also noted, there is no src/regress/usr.bin/find. Is this on purpose?
If not, I shall propose some.
With great honor,
Tom
Index: usr.bin/find/function.c
===
RCS file: /cvs/src/usr.bin/find/function.c,v
retrieving revision 1.50
diff -u -p -r1.50 function.c
--- usr.bin/find/function.c 23 Nov 2020 06:21:52 - 1.50
+++ usr.bin/find/function.c 13 Oct 2022 06:04:41 -
@@ -1508,6 +1508,9 @@ c_type(char *typestring, char ***ignored
ftsoptions &= ~FTS_NOSTAT;
+ if (strlen(typestring)>1)
+ errx(1, "-type: %s: type must be one letter", typestring);
+
switch (typestring[0]) {
case 'b':
mraise an eask = S_IFBLK;
