Re: [PATCH] /etc/netstart: unquoted command substitution inside arithmetic expression
Exactly my point. Even if the circumstances were contrived, I think it would good to fix it just for the sake of correctness. The issue is actually a pattern I found not only in /etc/netstart but also in /etc/rc. (( )) cannot deal with an empty result yet it sometimes includes calls to sysctl which apparently can return an empty string in some cases. So options are: 1. ensure that sysctl always returns a number where it is expected 2. work around the issue by using /bin/[ in place of or in addition to, the arithmetic expression (depending on the expression being tested), so that whatever returns empty string can be tested instead of blowing up. P.S. To answer another poster's question, I didn't get any error from sysctl. I tried it manually at the prompt and I got back nothing. Hope that helps. ‐‐‐ Original Message ‐‐‐ On Friday, October 8th, 2021 at 1:41 PM, Philip Guenther wrote: > On Fri, Oct 8, 2021 at 8:57 AM Theo de Raadt wrote: > >> Philip Guenther wrote: >> >>> On Thu, Oct 7, 2021 at 5:57 PM bm1les wrote: >>> >>> > --- netstart 2 Sep 2021 19:38:20 - 1.216 >>> > +++ netstart 8 Oct 2021 02:43:30 - >>> > @@ -365,7 +365,7 @@ ifmstart "tun tap gif etherip gre egre p >>> > if [[ $ip6kernel == YES ]]; then >>> > # Ensure IPv6 Duplicate Address Detection (DAD) is completed. >>> > count=0 >>> > - while ((count++ < 10 && $(sysctl -n net.inet6.ip6.dad_pending) != >>> > 0)); do >>> > + while ((count++ < 10 && "$(sysctl -n net.inet6.ip6.dad_pending)" >>> > != 0)); do >>> > sleep 1 >>> > done >>> > fi >>> > >>> >>> I can't figure out what problem you think this could solve. Can you >>> explain the circumstances under which those quotes could make a difference? >> >> Not the OP's issue, but I think a kernels compiled without option INET6 >> will return an errno, and I cannot tell if sysctl prints out an error message >> or converts to "", the empty string, which would conceivably mis-parse. > > AFAICT, an empty quoted string there results in the exact same error. As I > wrote off-list to the original submitter: > >> Can you be clearer about how the quoting makes the result any better when >> run under bsd.rd? Doesn't it fail in the same way? Testing with 'echo' >> instead would seem to indicate so: >> : bleys; (( 1 < 10 && $(echo) != 0 )); echo $? >> /bin/ksh: 1 < 10 && != 0 : unexpected `!=' >> 2 >> : bleys; (( 1 < 10 && $(echo -n) != 0 )); echo $? >> /bin/ksh: 1 < 10 && != 0 : unexpected `!=' >> 2 >> : bleys; (( 1 < 10 && "$(echo)" != 0 )); echo $? >> /bin/ksh: 1 < 10 && != 0 : unexpected `!=' >> 2 >> : bleys; (( 1 < 10 && "$(echo -n)" != 0 )); echo $? >> /bin/ksh: 1 < 10 && != 0 : unexpected `!=' >> 2 >> : bleys; > > Philip
Re: head(1): fully support the legacy -count syntax
On 10/10/21 5:03 PM, Scott Cheloha wrote:
On Sun, Oct 10, 2021 at 02:36:32PM -0600, Theo de Raadt wrote:
Stuart Henderson wrote:
x1> On 2021/10/10 14:26, Scott Cheloha wrote:
On Sun, Oct 10, 2021 at 12:31:22PM -0600, Theo de Raadt wrote:
Bryan Steele wrote:
On Sun, Oct 10, 2021 at 12:18:55PM -0500, Scott Cheloha wrote:
On Sun, Oct 10, 2021 at 10:51:29AM -0600, Theo de Raadt wrote:
did anyone ever use it this way, or are you getting ahead of yourself.
I don't understand the question.
I've only ever seen it used with -count as the first argument, can't
say it's every occoured to me to type "head file -10".
That is not what I proposed. Reread my first message:
https://marc.info/?l=openbsd-tech=163388435528203=2
i.e. "head -2 -3 somefile" is taken as -3.
This is unportable syntax, GNU head doesn't support it, current OpenBSD head
doesn't support it,
... obviously. That's why I posted the patch. :)
and it doesn't seem to be really meaningful.
Additionally I don't think we've ever had a problem with this in ports.
I think we would be better served to keep things as-is and not support it.
Seems that FreeBSD is the odd one out here?
If we're only going to support it as the first argument then we've
created a "gotcha", a special exception to the expected behavior. We
claim to support the legacy syntax but we don't actually fully support
it. The requirement that the legacy syntax be the first option
argument to head(1) in order to work as expected is undocumented.
So we could document this peculiarity...
... or we could just use my tiny patch and fully support it and
everything will work as documented today.
Indeed, the problem is our code supports this
but noone else supports it
NetBSD and FreeBSD support it. It was a standard part of the syntax
in SUSv2. I showed you in a private mail that it was supported in
1BSD through 4.3BSD, and then again in 4.4BSD some time in 1992.
Somewhere along the way between CSRG and NetBSD and our repository
the support was removed.
well, someone might accidentally use it in a script they write on OpenBSD
and... it is unportable, the behaviour is either different, or an error
condition
So who benefits? Noone, the way I see it.
If we want to have the unportable legacy syntax then it should work
like other option arguments. Option arguments can be respecified
multiple times in most other utilities. The last such appearance of
an option argument is the one the utility uses. That's how option
arguments work, for the most part.
We could remove the legacy syntax and shave a couple lines of code.
OTOH, supporting it fully is super easy. I've provided a patch.
The man page says head [-count | -n count] [file ...]
There are only two valid switches.
One, the other, or none.
Using more than one is -undefined-.
I doubt it ever has been defined.
It could be asserted that any more than 1 switch is an error.
If you have an old man page that says {[ -count | -n count ] ...}
then your argument has some merit.
geoff steckel
head(1): increase line count maximum to LLONG_MAX
This unifies the input maximums on 32-bit and 64-bit platforms.
ok?
Index: head.c
===
RCS file: /cvs/src/usr.bin/head/head.c,v
retrieving revision 1.22
diff -u -p -r1.22 head.c
--- head.c 10 Oct 2021 15:57:25 - 1.22
+++ head.c 11 Oct 2021 00:09:31 -
@@ -50,9 +50,9 @@ main(int argc, char *argv[])
{
const char *errstr;
FILE*fp;
- longcnt;
+ long long cnt;
int ch, firsttime;
- longlinecnt = 10;
+ long long linecnt = 10;
int status = 0;
if (pledge("stdio rpath", NULL) == -1)
@@ -61,7 +61,7 @@ main(int argc, char *argv[])
/* handle obsolete -number syntax */
if (argc > 1 && argv[1][0] == '-' &&
isdigit((unsigned char)argv[1][1])) {
- linecnt = strtonum(argv[1] + 1, 1, LONG_MAX, );
+ linecnt = strtonum(argv[1] + 1, 1, LLONG_MAX, );
if (errstr != NULL)
errx(1, "count is %s: %s", errstr, argv[1] + 1);
argc--;
@@ -71,7 +71,7 @@ main(int argc, char *argv[])
while ((ch = getopt(argc, argv, "n:")) != -1) {
switch (ch) {
case 'n':
- linecnt = strtonum(optarg, 1, LONG_MAX, );
+ linecnt = strtonum(optarg, 1, LLONG_MAX, );
if (errstr != NULL)
errx(1, "count is %s: %s", errstr, optarg);
break;
Re: [PATCH] /etc/netstart: unquoted command substitution inside arithmetic expression
On Sun, Oct 10, 2021 at 1:48 PM bm1les wrote: > Exactly my point. Even if the circumstances were contrived, I think it > would good to fix it just for the sake of correctness. > Sure, knowing what circumstances could cause a problem assists in achieving correctness. > The issue is actually a pattern I found not only in /etc/netstart but also > in /etc/rc. (( )) cannot deal with an empty result yet it sometimes > includes calls to sysctl which apparently can return an empty string in > some cases. > > So options are: > > 1. ensure that sysctl always returns a number where it is expected > 2. work around the issue by using /bin/[ in place of or in addition to, > the arithmetic expression (depending on the expression being tested), so > that whatever returns empty string can be tested instead of blowing up. > 3. use syntax with works when the expansion is empty, such as (( $(sysctl blah) + 0 != 0 )) which is unary plus when it's empty, or (( $(sysctl blah)0 != 0 )) which multiplies the value by 10 when not empty and is zero when it's empty. Philip Guenther (Per POSIX rules, any arithmetic expression is effectively evaluated in double-quotes. If you follow the spec from there, you can work out that if an arithmetic expression that directly** contains double-quotes parses correctly, then it must also parse correctly with the double-quotes removed; adding double-quotes can't fix an arithmetic expression. The reverse is not true: adding double-quotes can break the parsing. ** i.e., not counting quotes inside a nested parameter expansion or command substitution.)
Re: cwm: add group-last command [Was: Re: cwm: add last-group command]
Tom Murphy wrote:
> Hi,
>
> Here's an updated diff from Omar Polo's addition of group-last
> command to cwm. I've been using it without issues and it's
> really handy to be able to switch back to the previous
> workspace you were on with it.
>
> Many thanks to Omar Polo for doing all the original work. I've
> just updated the diff so it applies cleanly.
>
> OK?
>
> Tom
>
>
> Index: calmwm.h
> ===
> RCS file: /cvs/xenocara/app/cwm/calmwm.h,v
> retrieving revision 1.375
> diff -u -p -r1.375 calmwm.h
> --- calmwm.h 16 Apr 2020 13:32:35 - 1.375
> +++ calmwm.h 10 Oct 2021 19:13:41 -
> @@ -214,6 +214,7 @@ struct screen_ctx {
> struct region_q regionq;
> struct group_q groupq;
> struct group_ctx*group_active;
> + int group_last;
> Colormap colormap;
> Visual *visual;
> struct {
> @@ -501,6 +502,7 @@ void
> kbfunc_client_toggle_group(void
> void kbfunc_client_movetogroup(void *, struct cargs *);
> void kbfunc_group_toggle(void *, struct cargs *);
> void kbfunc_group_only(void *, struct cargs *);
> +void kbfunc_group_last(void *, struct cargs *);
> void kbfunc_group_close(void *, struct cargs *);
> void kbfunc_group_cycle(void *, struct cargs *);
> void kbfunc_group_toggle_all(void *, struct cargs *);
> Index: conf.c
> ===
> RCS file: /cvs/xenocara/app/cwm/conf.c,v
> retrieving revision 1.252
> diff -u -p -r1.252 conf.c
> --- conf.c16 Apr 2020 13:32:35 - 1.252
> +++ conf.c10 Oct 2021 19:13:41 -
> @@ -139,6 +139,7 @@ static const struct {
>
> { FUNC_SC(group-cycle, group_cycle, (CWM_CYCLE_FORWARD)) },
> { FUNC_SC(group-rcycle, group_cycle, (CWM_CYCLE_REVERSE)) },
> + { FUNC_SC(group-last, group_last, 0) },
> { FUNC_SC(group-toggle-all, group_toggle_all, 0) },
> { FUNC_SC(group-toggle-1, group_toggle, 1) },
> { FUNC_SC(group-toggle-2, group_toggle, 2) },
> Index: cwmrc.5
> ===
> RCS file: /cvs/xenocara/app/cwm/cwmrc.5,v
> retrieving revision 1.76
> diff -u -p -r1.76 cwmrc.5
> --- cwmrc.5 16 Apr 2020 13:32:35 - 1.76
> +++ cwmrc.5 10 Oct 2021 19:13:41 -
> @@ -273,6 +273,8 @@ menu.
> Toggle visibility of group n, where n is 1-9.
> .It group-only-[n]
> Show only group n, where n is 1-9, hiding other groups.
> +.It group-last
> +Show only the last viewed group.
> .It group-close-[n]
> Close all windows in group n, where n is 1-9.
> .It group-toggle-all
> Index: group.c
> ===
> RCS file: /cvs/xenocara/app/cwm/group.c,v
> retrieving revision 1.137
> diff -u -p -r1.137 group.c
> --- group.c 27 Feb 2020 14:56:39 - 1.137
> +++ group.c 10 Oct 2021 19:13:41 -
> @@ -215,6 +215,9 @@ group_only(struct screen_ctx *sc, int id
> {
> struct group_ctx*gc;
>
> + if (sc->group_active->num != idx)
> + sc->group_last = sc->group_active->num;
> +
> TAILQ_FOREACH(gc, >groupq, entry) {
> if (gc->num == idx)
> group_show(gc);
> Index: kbfunc.c
> ===
> RCS file: /cvs/xenocara/app/cwm/kbfunc.c,v
> retrieving revision 1.170
> diff -u -p -r1.170 kbfunc.c
> --- kbfunc.c 20 Mar 2020 18:50:08 - 1.170
> +++ kbfunc.c 10 Oct 2021 19:13:41 -
> @@ -479,6 +479,14 @@ kbfunc_group_only(void *ctx, struct carg
> }
>
> void
> +kbfunc_group_last(void *ctx, struct cargs *cargs)
> +{
> + struct screen_ctx *sc = ctx;
> +
> + group_only(ctx, sc->group_last);
> +}
> +
> +void
> kbfunc_group_toggle(void *ctx, struct cargs *cargs)
> {
> group_toggle(ctx, cargs->flag);
> Index: screen.c
> ===
> RCS file: /cvs/xenocara/app/cwm/screen.c,v
> retrieving revision 1.97
> diff -u -p -r1.97 screen.c
> --- screen.c 24 Mar 2020 14:47:29 - 1.97
> +++ screen.c 10 Oct 2021 19:13:41 -
> @@ -53,6 +53,7 @@ screen_init(int which)
> sc->visual = DefaultVisual(X_Dpy, sc->which);
> sc->cycling = 0;
> sc->hideall = 0;
> + sc->group_last = 1;
>
> conf_screen(sc);
I discovered something strange while testing this.
X Windows appears to bug out and ends up showing one
of the windows across all groups until cwm is reloaded.
To reproduce:
1. Bind group-last to any key you like (I used 4-Tab)
2. Open up a window in group 1
3. Switch to group 2 and open up a different window there
4. Switch back to group 1
5. Jam on the 4-Tab key (or whatever you bound in step 1)
Re: More pchgpio(4)
> Date: Sat, 9 Oct 2021 22:27:52 +0200 (CEST)
> From: Mark Kettenis
>
> > Date: Sat, 9 Oct 2021 20:55:10 +0200 (CEST)
> > From: Mark Kettenis
> >
> > This time adding support for Sunrisepoint-H and Sunrisepoint-LP.
> > Because of all the failed attempts by Intel to get their 10nm process
> > under control, this may cover Intel Mobile CPUs marketed as 6th, 7th,
> > 8th, 9th and 10th generation. So if you have a Laptop that isn't at
> > least 5 years old, give this a try if pchgpio(4) doesn't attach. This
> > may fix all sorts of issues with keyboards, touchpads or
> > suspend/resume.
> >
> > ok?
>
> Updated diff that masks unhandled interrupts like we do in amdgpio(4).
And another update to fix a typo in the pin groups for Sunrisepoint-LP.
Index: dev/acpi/pchgpio.c
===
RCS file: /cvs/src/sys/dev/acpi/pchgpio.c,v
retrieving revision 1.8
diff -u -p -r1.8 pchgpio.c
--- dev/acpi/pchgpio.c 29 Sep 2021 22:03:33 - 1.8
+++ dev/acpi/pchgpio.c 10 Oct 2021 21:40:45 -
@@ -107,13 +107,76 @@ struct cfdriver pchgpio_cd = {
};
const char *pchgpio_hids[] = {
+ "INT344B",
"INT3450",
+ "INT3451",
+ "INT345D",
"INT34BB",
"INT34C5",
"INT34C6",
NULL
};
+/* Sunrisepoint-LP */
+
+const struct pchgpio_group spt_lp_groups[] =
+{
+ /* Community 0 */
+ { 0, 0, 0, 23, 0 }, /* GPP_A */
+ { 0, 1, 24, 47, 24 }, /* GPP_B */
+
+ /* Community 1 */
+ { 1, 0, 48, 71, 48 }, /* GPP_C */
+ { 1, 1, 72, 95, 72 }, /* GPP_D */
+ { 1, 2, 96, 119, 96 }, /* GPP_E */
+
+ /* Community 3 */
+ { 2, 0, 120, 143, 120 },/* GPP_F */
+ { 2, 1, 144, 151, 144 },/* GPP_G */
+};
+
+const struct pchgpio_device spt_lp_device =
+{
+ .pad_size = 16,
+ .gpi_is = 0x100,
+ .gpi_ie = 0x120,
+ .groups = spt_lp_groups,
+ .ngroups = nitems(spt_lp_groups),
+ .npins = 176,
+};
+
+/* Sunrisepoint-H */
+
+const struct pchgpio_group spt_h_groups[] =
+{
+ /* Community 0 */
+ { 0, 0, 0, 23, 0 }, /* GPP_A */
+ { 0, 1, 24, 47, 24 }, /* GPP_B */
+
+ /* Community 1 */
+ { 1, 0, 48, 71, 48 }, /* GPP_C */
+ { 1, 1, 72, 95, 72 }, /* GPP_D */
+ { 1, 2, 96, 108, 96 }, /* GPP_E */
+ { 1, 3, 109, 132, 120 },/* GPP_F */
+ { 1, 4, 133, 156, 144 },/* GPP_G */
+ { 1, 5, 157, 180, 168 },/* GPP_H */
+
+ /* Community 3 */
+ { 2, 0, 181, 191, 192 },/* GPP_I */
+};
+
+const struct pchgpio_device spt_h_device =
+{
+ .pad_size = 16,
+ .gpi_is = 0x100,
+ .gpi_ie = 0x120,
+ .groups = spt_h_groups,
+ .ngroups = nitems(spt_h_groups),
+ .npins = 224,
+};
+
+/* Cannon Lake-H */
+
const struct pchgpio_group cnl_h_groups[] =
{
/* Community 0 */
@@ -146,6 +209,8 @@ const struct pchgpio_device cnl_h_device
.npins = 384,
};
+/* Cannon Lake-LP */
+
const struct pchgpio_group cnl_lp_groups[] =
{
/* Community 0 */
@@ -173,6 +238,8 @@ const struct pchgpio_device cnl_lp_devic
.npins = 320,
};
+/* Tiger Lake-LP */
+
const struct pchgpio_group tgl_lp_groups[] =
{
/* Community 0 */
@@ -205,6 +272,8 @@ const struct pchgpio_device tgl_lp_devic
.npins = 360,
};
+/* Tiger Lake-H */
+
const struct pchgpio_group tgl_h_groups[] =
{
/* Community 0 */
@@ -242,7 +311,10 @@ const struct pchgpio_device tgl_h_device
};
struct pchgpio_match pchgpio_devices[] = {
+ { "INT344B", _lp_device },
{ "INT3450", _h_device },
+ { "INT3451", _h_device },
+ { "INT345D", _h_device },
{ "INT34BB", _lp_device },
{ "INT34C5", _lp_device },
{ "INT34C6", _h_device },
@@ -473,11 +545,38 @@ pchgpio_intr_establish(void *cookie, int
}
int
+pchgpio_intr_handle(struct pchgpio_softc *sc, int group, int bit)
+{
+ uint32_t enable;
+ int gpiobase, pin, handled = 0;
+ uint8_t bank, bar;
+
+ bar = sc->sc_device->groups[group].bar;
+ bank = sc->sc_device->groups[group].bank;
+ gpiobase = sc->sc_device->groups[group].gpiobase;
+
+ pin = gpiobase + bit;
+ if (sc->sc_pin_ih[pin].ih_func) {
+ sc->sc_pin_ih[pin].ih_func(sc->sc_pin_ih[pin].ih_arg);
+ handled = 1;
+ } else {
+ /* Mask unhandled interrupt. */
+ enable = bus_space_read_4(sc->sc_memt[bar], sc->sc_memh[bar],
+ sc->sc_device->gpi_ie + bank * 4);
+ enable &= ~(1 << bit);
+ bus_space_write_4(sc->sc_memt[bar], sc->sc_memh[bar],
+ sc->sc_device->gpi_ie + bank * 4, enable);
+ }
+
+ return handled;
+}
+
+int
pchgpio_intr(void *arg)
{
struct pchgpio_softc *sc = arg;
uint32_t status,
Re: head(1): fully support the legacy -count syntax
On Sun, Oct 10, 2021 at 02:36:32PM -0600, Theo de Raadt wrote: > Stuart Henderson wrote: > > x1> On 2021/10/10 14:26, Scott Cheloha wrote: > > > On Sun, Oct 10, 2021 at 12:31:22PM -0600, Theo de Raadt wrote: > > > > Bryan Steele wrote: > > > > > > > > > On Sun, Oct 10, 2021 at 12:18:55PM -0500, Scott Cheloha wrote: > > > > > > On Sun, Oct 10, 2021 at 10:51:29AM -0600, Theo de Raadt wrote: > > > > > > > did anyone ever use it this way, or are you getting ahead of > > > > > > > yourself. > > > > > > > > > > > > I don't understand the question. > > > > > > > > > > I've only ever seen it used with -count as the first argument, can't > > > > > say it's every occoured to me to type "head file -10". > > > > > > That is not what I proposed. Reread my first message: > > > > > > https://marc.info/?l=openbsd-tech=163388435528203=2 > > > > i.e. "head -2 -3 somefile" is taken as -3. > > > > This is unportable syntax, GNU head doesn't support it, current OpenBSD head > > doesn't support it, ... obviously. That's why I posted the patch. :) > > and it doesn't seem to be really meaningful. > > Additionally I don't think we've ever had a problem with this in ports. > > I think we would be better served to keep things as-is and not support it. > > Seems that FreeBSD is the odd one out here? If we're only going to support it as the first argument then we've created a "gotcha", a special exception to the expected behavior. We claim to support the legacy syntax but we don't actually fully support it. The requirement that the legacy syntax be the first option argument to head(1) in order to work as expected is undocumented. So we could document this peculiarity... ... or we could just use my tiny patch and fully support it and everything will work as documented today. > Indeed, the problem is our code supports this > > but noone else supports it NetBSD and FreeBSD support it. It was a standard part of the syntax in SUSv2. I showed you in a private mail that it was supported in 1BSD through 4.3BSD, and then again in 4.4BSD some time in 1992. Somewhere along the way between CSRG and NetBSD and our repository the support was removed. > well, someone might accidentally use it in a script they write on OpenBSD > > and... it is unportable, the behaviour is either different, or an error > condition > > So who benefits? Noone, the way I see it. If we want to have the unportable legacy syntax then it should work like other option arguments. Option arguments can be respecified multiple times in most other utilities. The last such appearance of an option argument is the one the utility uses. That's how option arguments work, for the most part. We could remove the legacy syntax and shave a couple lines of code. OTOH, supporting it fully is super easy. I've provided a patch.
Re: head(1): fully support the legacy -count syntax
Stuart Henderson wrote: x1> On 2021/10/10 14:26, Scott Cheloha wrote: > > On Sun, Oct 10, 2021 at 12:31:22PM -0600, Theo de Raadt wrote: > > > Bryan Steele wrote: > > > > > > > On Sun, Oct 10, 2021 at 12:18:55PM -0500, Scott Cheloha wrote: > > > > > On Sun, Oct 10, 2021 at 10:51:29AM -0600, Theo de Raadt wrote: > > > > > > did anyone ever use it this way, or are you getting ahead of > > > > > > yourself. > > > > > > > > > > I don't understand the question. > > > > > > > > I've only ever seen it used with -count as the first argument, can't > > > > say it's every occoured to me to type "head file -10". > > > > That is not what I proposed. Reread my first message: > > > > https://marc.info/?l=openbsd-tech=163388435528203=2 > > i.e. "head -2 -3 somefile" is taken as -3. > > This is unportable syntax, GNU head doesn't support it, current OpenBSD head > doesn't support it, and it doesn't seem to be really meaningful. > Additionally I don't think we've ever had a problem with this in ports. > I think we would be better served to keep things as-is and not support it. > Seems that FreeBSD is the odd one out here? Indeed, the problem is our code supports this but noone else supports it well, someone might accidentally use it in a script they write on OpenBSD and... it is unportable, the behaviour is either different, or an error condition So who benefits? Noone, the way I see it.
Re: head(1): fully support the legacy -count syntax
On Sun, Oct 10, 2021 at 09:11:50PM +0100, Stuart Henderson wrote: > On 2021/10/10 14:26, Scott Cheloha wrote: > > On Sun, Oct 10, 2021 at 12:31:22PM -0600, Theo de Raadt wrote: > > > Bryan Steele wrote: > > > > > > > On Sun, Oct 10, 2021 at 12:18:55PM -0500, Scott Cheloha wrote: > > > > > On Sun, Oct 10, 2021 at 10:51:29AM -0600, Theo de Raadt wrote: > > > > > > did anyone ever use it this way, or are you getting ahead of > > > > > > yourself. > > > > > > > > > > I don't understand the question. > > > > > > > > I've only ever seen it used with -count as the first argument, can't > > > > say it's every occoured to me to type "head file -10". > > > > That is not what I proposed. Reread my first message: > > > > https://marc.info/?l=openbsd-tech=163388435528203=2 > > i.e. "head -2 -3 somefile" is taken as -3. > > This is unportable syntax, GNU head doesn't support it, current OpenBSD head > doesn't support it, and it doesn't seem to be really meaningful. > Additionally I don't think we've ever had a problem with this in ports. > I think we would be better served to keep things as-is and not support it. > Seems that FreeBSD is the odd one out here? > FreeBSD and NetBSD merged an obsolete() function from Lite-2 which converts all -NUMBER arguments into -nNUMBER and then lets getopt take care of picking the last -n argument. If we want to do this, we should probably follow their pattern.
Re: cwm: add group-last command [Was: Re: cwm: add last-group command]
Hi,
Here's an updated diff from Omar Polo's addition of group-last
command to cwm. I've been using it without issues and it's
really handy to be able to switch back to the previous
workspace you were on with it.
Many thanks to Omar Polo for doing all the original work. I've
just updated the diff so it applies cleanly.
OK?
Tom
Index: calmwm.h
===
RCS file: /cvs/xenocara/app/cwm/calmwm.h,v
retrieving revision 1.375
diff -u -p -r1.375 calmwm.h
--- calmwm.h16 Apr 2020 13:32:35 - 1.375
+++ calmwm.h10 Oct 2021 19:13:41 -
@@ -214,6 +214,7 @@ struct screen_ctx {
struct region_q regionq;
struct group_q groupq;
struct group_ctx*group_active;
+ int group_last;
Colormap colormap;
Visual *visual;
struct {
@@ -501,6 +502,7 @@ void
kbfunc_client_toggle_group(void
voidkbfunc_client_movetogroup(void *, struct cargs *);
voidkbfunc_group_toggle(void *, struct cargs *);
voidkbfunc_group_only(void *, struct cargs *);
+voidkbfunc_group_last(void *, struct cargs *);
voidkbfunc_group_close(void *, struct cargs *);
voidkbfunc_group_cycle(void *, struct cargs *);
voidkbfunc_group_toggle_all(void *, struct cargs *);
Index: conf.c
===
RCS file: /cvs/xenocara/app/cwm/conf.c,v
retrieving revision 1.252
diff -u -p -r1.252 conf.c
--- conf.c 16 Apr 2020 13:32:35 - 1.252
+++ conf.c 10 Oct 2021 19:13:41 -
@@ -139,6 +139,7 @@ static const struct {
{ FUNC_SC(group-cycle, group_cycle, (CWM_CYCLE_FORWARD)) },
{ FUNC_SC(group-rcycle, group_cycle, (CWM_CYCLE_REVERSE)) },
+ { FUNC_SC(group-last, group_last, 0) },
{ FUNC_SC(group-toggle-all, group_toggle_all, 0) },
{ FUNC_SC(group-toggle-1, group_toggle, 1) },
{ FUNC_SC(group-toggle-2, group_toggle, 2) },
Index: cwmrc.5
===
RCS file: /cvs/xenocara/app/cwm/cwmrc.5,v
retrieving revision 1.76
diff -u -p -r1.76 cwmrc.5
--- cwmrc.5 16 Apr 2020 13:32:35 - 1.76
+++ cwmrc.5 10 Oct 2021 19:13:41 -
@@ -273,6 +273,8 @@ menu.
Toggle visibility of group n, where n is 1-9.
.It group-only-[n]
Show only group n, where n is 1-9, hiding other groups.
+.It group-last
+Show only the last viewed group.
.It group-close-[n]
Close all windows in group n, where n is 1-9.
.It group-toggle-all
Index: group.c
===
RCS file: /cvs/xenocara/app/cwm/group.c,v
retrieving revision 1.137
diff -u -p -r1.137 group.c
--- group.c 27 Feb 2020 14:56:39 - 1.137
+++ group.c 10 Oct 2021 19:13:41 -
@@ -215,6 +215,9 @@ group_only(struct screen_ctx *sc, int id
{
struct group_ctx*gc;
+ if (sc->group_active->num != idx)
+ sc->group_last = sc->group_active->num;
+
TAILQ_FOREACH(gc, >groupq, entry) {
if (gc->num == idx)
group_show(gc);
Index: kbfunc.c
===
RCS file: /cvs/xenocara/app/cwm/kbfunc.c,v
retrieving revision 1.170
diff -u -p -r1.170 kbfunc.c
--- kbfunc.c20 Mar 2020 18:50:08 - 1.170
+++ kbfunc.c10 Oct 2021 19:13:41 -
@@ -479,6 +479,14 @@ kbfunc_group_only(void *ctx, struct carg
}
void
+kbfunc_group_last(void *ctx, struct cargs *cargs)
+{
+ struct screen_ctx *sc = ctx;
+
+ group_only(ctx, sc->group_last);
+}
+
+void
kbfunc_group_toggle(void *ctx, struct cargs *cargs)
{
group_toggle(ctx, cargs->flag);
Index: screen.c
===
RCS file: /cvs/xenocara/app/cwm/screen.c,v
retrieving revision 1.97
diff -u -p -r1.97 screen.c
--- screen.c24 Mar 2020 14:47:29 - 1.97
+++ screen.c10 Oct 2021 19:13:41 -
@@ -53,6 +53,7 @@ screen_init(int which)
sc->visual = DefaultVisual(X_Dpy, sc->which);
sc->cycling = 0;
sc->hideall = 0;
+ sc->group_last = 1;
conf_screen(sc);
Re: head(1): fully support the legacy -count syntax
On 2021/10/10 14:26, Scott Cheloha wrote: > On Sun, Oct 10, 2021 at 12:31:22PM -0600, Theo de Raadt wrote: > > Bryan Steele wrote: > > > > > On Sun, Oct 10, 2021 at 12:18:55PM -0500, Scott Cheloha wrote: > > > > On Sun, Oct 10, 2021 at 10:51:29AM -0600, Theo de Raadt wrote: > > > > > did anyone ever use it this way, or are you getting ahead of yourself. > > > > > > > > I don't understand the question. > > > > > > I've only ever seen it used with -count as the first argument, can't > > > say it's every occoured to me to type "head file -10". > > That is not what I proposed. Reread my first message: > > https://marc.info/?l=openbsd-tech=163388435528203=2 i.e. "head -2 -3 somefile" is taken as -3. This is unportable syntax, GNU head doesn't support it, current OpenBSD head doesn't support it, and it doesn't seem to be really meaningful. Additionally I don't think we've ever had a problem with this in ports. I think we would be better served to keep things as-is and not support it. Seems that FreeBSD is the odd one out here?
Re: head(1): fully support the legacy -count syntax
On Sun, Oct 10, 2021 at 02:26:32PM -0500, Scott Cheloha wrote: > On Sun, Oct 10, 2021 at 12:31:22PM -0600, Theo de Raadt wrote: > > Bryan Steele wrote: > > > > > On Sun, Oct 10, 2021 at 12:18:55PM -0500, Scott Cheloha wrote: > > > > On Sun, Oct 10, 2021 at 10:51:29AM -0600, Theo de Raadt wrote: > > > > > did anyone ever use it this way, or are you getting ahead of yourself. > > > > > > > > I don't understand the question. > > > > > > I've only ever seen it used with -count as the first argument, can't > > > say it's every occoured to me to type "head file -10". > > That is not what I proposed. Reread my first message: > > https://marc.info/?l=openbsd-tech=163388435528203=2 Yes, sorry. It's been a day.. > > POSIX says options before arguments. That is what we support. We don't > > support options after arguments. > > Yep. >
Re: head(1): fully support the legacy -count syntax
On Sun, Oct 10, 2021 at 12:31:22PM -0600, Theo de Raadt wrote: > Bryan Steele wrote: > > > On Sun, Oct 10, 2021 at 12:18:55PM -0500, Scott Cheloha wrote: > > > On Sun, Oct 10, 2021 at 10:51:29AM -0600, Theo de Raadt wrote: > > > > did anyone ever use it this way, or are you getting ahead of yourself. > > > > > > I don't understand the question. > > > > I've only ever seen it used with -count as the first argument, can't > > say it's every occoured to me to type "head file -10". That is not what I proposed. Reread my first message: https://marc.info/?l=openbsd-tech=163388435528203=2 > POSIX says options before arguments. That is what we support. We don't > support options after arguments. Yep.
Re: head(1): fully support the legacy -count syntax
Bryan Steele wrote: > On Sun, Oct 10, 2021 at 12:18:55PM -0500, Scott Cheloha wrote: > > On Sun, Oct 10, 2021 at 10:51:29AM -0600, Theo de Raadt wrote: > > > did anyone ever use it this way, or are you getting ahead of yourself. > > > > I don't understand the question. > > I've only ever seen it used with -count as the first argument, can't > say it's every occoured to me to type "head file -10". POSIX says options before arguments. That is what we support. We don't support options after arguments.
Re: head(1): fully support the legacy -count syntax
On Sun, Oct 10, 2021 at 12:18:55PM -0500, Scott Cheloha wrote: > On Sun, Oct 10, 2021 at 10:51:29AM -0600, Theo de Raadt wrote: > > did anyone ever use it this way, or are you getting ahead of yourself. > > I don't understand the question. I've only ever seen it used with -count as the first argument, can't say it's every occoured to me to type "head file -10". > The -count syntax was fully supported in the first revision of head(1): > > https://svnweb.freebsd.org/csrg/usr.bin/head/head.c?view=markup=1026 > > The -count syntax was fully supported through 4.4BSD: > > https://svnweb.freebsd.org/csrg/usr.bin/head/head.c?revision=69237=markup > > The -count syntax was also standard in SUSv2: > > https://pubs.opengroup.org/onlinepubs/7908799/xcu/head.html > > ... and then dropped in SUSv3 (POSIX-2001): > > https://pubs.opengroup.org/onlinepubs/009695399/utilities/head.html > > FreeBSD maintains full support for the -count syntax: > > https://cgit.freebsd.org/src/tree/usr.bin/head/head.c#n191 > > ... so clearly people have used it this way. If we're going to > support the -count syntax at all, why not fully support it? We can do > so with very little code. > >
Re: head(1): fully support the legacy -count syntax
On Sun, Oct 10, 2021 at 10:51:29AM -0600, Theo de Raadt wrote: > did anyone ever use it this way, or are you getting ahead of yourself. I don't understand the question. The -count syntax was fully supported in the first revision of head(1): https://svnweb.freebsd.org/csrg/usr.bin/head/head.c?view=markup=1026 The -count syntax was fully supported through 4.4BSD: https://svnweb.freebsd.org/csrg/usr.bin/head/head.c?revision=69237=markup The -count syntax was also standard in SUSv2: https://pubs.opengroup.org/onlinepubs/7908799/xcu/head.html ... and then dropped in SUSv3 (POSIX-2001): https://pubs.opengroup.org/onlinepubs/009695399/utilities/head.html FreeBSD maintains full support for the -count syntax: https://cgit.freebsd.org/src/tree/usr.bin/head/head.c#n191 ... so clearly people have used it this way. If we're going to support the -count syntax at all, why not fully support it? We can do so with very little code.
Re: head(1): fully support the legacy -count syntax
did anyone ever use it this way, or are you getting ahead of yourself.
Scott Cheloha wrote:
> Hi,
>
> head(1) takes line count arguments in two ways. The legacy (1977)
> syntax is "-count" [1]. The "new" (1992) syntax is "-n count" [2].
> In either case, "count" must be a positive decimal value.
>
> Somewhere along the way, support for the legacy syntax was neutered.
> At present it only works as expected if -count is the first option
> argument to head(1), i.e. this works:
>
> $ head -20 file
>
> but this is an error:
>
> $ head -20 -25 file
>
> I'm not a fan of this. If we're going to support the legacy syntax I
> think it should behave like option arguments for other utilities. You
> should be able to specify -count multiple times. We do this for
> tail(1), which has a similar legacy syntax problem.
>
> The easiest way to transparently support such invocations is to use
> the GNU double-colon extension for getopt(3). We then rebuild the
> number string with asprintf(3), parse it with strtonum(3), and free
> the string.
>
> Before:
>
> $ jot 10 | head -5 -6
> head: unknown option -- 6
> usage: head [-count | -n count] [file ...]
>
> After:
>
> $ jot 10 | head -5 -6
> 1
> 2
> 3
> 4
> 5
> 6
>
> --
>
> ok?
>
> [1]
> https://svnweb.freebsd.org/csrg/usr.bin/head/head.c?revision=1026=markup
>
> [2]
> https://svnweb.freebsd.org/csrg/usr.bin/head/head.c?revision=52824=markup
>
> Index: head.c
> ===
> RCS file: /cvs/src/usr.bin/head/head.c,v
> retrieving revision 1.22
> diff -u -p -r1.22 head.c
> --- head.c10 Oct 2021 15:57:25 - 1.22
> +++ head.c10 Oct 2021 16:44:01 -
> @@ -49,27 +49,30 @@ int
> main(int argc, char *argv[])
> {
> const char *errstr;
> + char *str;
> FILE*fp;
> longcnt;
> int ch, firsttime;
> longlinecnt = 10;
> - int status = 0;
> + int error, status = 0;
>
> if (pledge("stdio rpath", NULL) == -1)
> err(1, "pledge");
>
> - /* handle obsolete -number syntax */
> - if (argc > 1 && argv[1][0] == '-' &&
> - isdigit((unsigned char)argv[1][1])) {
> - linecnt = strtonum(argv[1] + 1, 1, LONG_MAX, );
> - if (errstr != NULL)
> - errx(1, "count is %s: %s", errstr, argv[1] + 1);
> - argc--;
> - argv++;
> - }
> -
> - while ((ch = getopt(argc, argv, "n:")) != -1) {
> +#define OPTSTR "0::1::2::3::4::5::6::7::8::9::n:"
> + while ((ch = getopt(argc, argv, OPTSTR)) != -1) {
> switch (ch) {
> + case '0': case '1': case '2': case '3': case '4':
> + case '5': case '6': case '7': case '8': case '9':
> + error = asprintf(, "%c%s",
> + ch, (optarg == NULL) ? "" : optarg);
> + if (error == -1)
> + err(1, "asprintf");
> + linecnt = strtonum(str, 1, LONG_MAX, );
> + if (errstr != NULL)
> + errx(1, "count is %s: %s", errstr, str);
> + free(str);
> + break;
> case 'n':
> linecnt = strtonum(optarg, 1, LONG_MAX, );
> if (errstr != NULL)
>
head(1): fully support the legacy -count syntax
Hi,
head(1) takes line count arguments in two ways. The legacy (1977)
syntax is "-count" [1]. The "new" (1992) syntax is "-n count" [2].
In either case, "count" must be a positive decimal value.
Somewhere along the way, support for the legacy syntax was neutered.
At present it only works as expected if -count is the first option
argument to head(1), i.e. this works:
$ head -20 file
but this is an error:
$ head -20 -25 file
I'm not a fan of this. If we're going to support the legacy syntax I
think it should behave like option arguments for other utilities. You
should be able to specify -count multiple times. We do this for
tail(1), which has a similar legacy syntax problem.
The easiest way to transparently support such invocations is to use
the GNU double-colon extension for getopt(3). We then rebuild the
number string with asprintf(3), parse it with strtonum(3), and free
the string.
Before:
$ jot 10 | head -5 -6
head: unknown option -- 6
usage: head [-count | -n count] [file ...]
After:
$ jot 10 | head -5 -6
1
2
3
4
5
6
--
ok?
[1]
https://svnweb.freebsd.org/csrg/usr.bin/head/head.c?revision=1026=markup
[2]
https://svnweb.freebsd.org/csrg/usr.bin/head/head.c?revision=52824=markup
Index: head.c
===
RCS file: /cvs/src/usr.bin/head/head.c,v
retrieving revision 1.22
diff -u -p -r1.22 head.c
--- head.c 10 Oct 2021 15:57:25 - 1.22
+++ head.c 10 Oct 2021 16:44:01 -
@@ -49,27 +49,30 @@ int
main(int argc, char *argv[])
{
const char *errstr;
+ char *str;
FILE*fp;
longcnt;
int ch, firsttime;
longlinecnt = 10;
- int status = 0;
+ int error, status = 0;
if (pledge("stdio rpath", NULL) == -1)
err(1, "pledge");
- /* handle obsolete -number syntax */
- if (argc > 1 && argv[1][0] == '-' &&
- isdigit((unsigned char)argv[1][1])) {
- linecnt = strtonum(argv[1] + 1, 1, LONG_MAX, );
- if (errstr != NULL)
- errx(1, "count is %s: %s", errstr, argv[1] + 1);
- argc--;
- argv++;
- }
-
- while ((ch = getopt(argc, argv, "n:")) != -1) {
+#define OPTSTR "0::1::2::3::4::5::6::7::8::9::n:"
+ while ((ch = getopt(argc, argv, OPTSTR)) != -1) {
switch (ch) {
+ case '0': case '1': case '2': case '3': case '4':
+ case '5': case '6': case '7': case '8': case '9':
+ error = asprintf(, "%c%s",
+ ch, (optarg == NULL) ? "" : optarg);
+ if (error == -1)
+ err(1, "asprintf");
+ linecnt = strtonum(str, 1, LONG_MAX, );
+ if (errstr != NULL)
+ errx(1, "count is %s: %s", errstr, str);
+ free(str);
+ break;
case 'n':
linecnt = strtonum(optarg, 1, LONG_MAX, );
if (errstr != NULL)
Re: head(1): validate all line count arguments
On Sat, 09 Oct 2021 20:43:12 -0500, Scott Cheloha wrote: > head(1) currently only validates the last count argument given. I > think we ought to be stricter. You can specify the -n option an > arbitrary number of times. Yes, it is better to perform the check during argument processing. OK millert@ - todd
[Patch] Fix a couple of minor errors in OpenSSH section of 70.html
Missing space after "RFC" and a typo... Ross Index: 70.html === RCS file: /cvs/www/70.html,v retrieving revision 1.87 diff -u -p -r1.87 70.html --- 70.html 10 Oct 2021 06:32:45 - 1.87 +++ 70.html 10 Oct 2021 09:07:43 - @@ -895,7 +895,7 @@ to 7.0. sshd(8): remove references to ChallengeResponseAuthentication in favour of KbdInteractiveAuthentication. The former is what was in SSHv1, - the latter is what is in SSHv2 (RFC4256) + the latter is what is in SSHv2 (RFC 4256) and they were treated as somewhat but not entirely equivalent. We retain the old name as a deprecated alias so configuration files continue to work as well as a reference in the man page @@ -938,7 +938,7 @@ to 7.0. which allows RSA/SHA2 signatures for public key authentication but fails to advertise this correctly via SSH2_MSG_EXT_INFO. This causes clients of these server to incorrectly match - PubkeyAcceptedAlgorithmse and potentially refuse to offer + PubkeyAcceptedAlgorithms and potentially refuse to offer valid keys. sftp(1)/ scp(1): degrade
