Convert sysctl_sysvsem to sysctl_int_bounded
Mostly mindless application of the pattern established by "Convert
sysctl_sysvsem to sysctl_bounded_args".
>From bb0af6eb29a39924131bb87f4e78a27afc1d0e13 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Mon, 16 Nov 2020 22:27:33 -0800
Subject: [PATCH] Convert sysctl_sysvsem to sysctl_int_bounded
Performed a minor refactoring and removed a few trailing whitespaces.
---
sys/kern/sysv_shm.c | 106 ++--
1 file changed, 42 insertions(+), 64 deletions(-)
diff --git sys/kern/sysv_shm.c sys/kern/sysv_shm.c
index 1fd99f5b95d..311c9862353 100644
--- sys/kern/sysv_shm.c
+++ sys/kern/sysv_shm.c
@@ -252,7 +252,7 @@ sys_shmat(struct proc *p, void *v, register_t *retval)
prot |= PROT_WRITE;
if (SCARG(uap, shmaddr)) {
flags |= UVM_FLAG_FIXED;
- if (SCARG(uap, shmflg) & SHM_RND)
+ if (SCARG(uap, shmflg) & SHM_RND)
attach_va =
(vaddr_t)SCARG(uap, shmaddr) & ~(SHMLBA-1);
else if (((vaddr_t)SCARG(uap, shmaddr) & (SHMLBA-1)) == 0)
@@ -393,7 +393,7 @@ shmget_allocate_segment(struct proc *p,
struct shmid_ds *shmseg;
struct shm_handle *shm_handle;
int error = 0;
-
+
if (SCARG(uap, size) < shminfo.shmmin ||
SCARG(uap, size) > shminfo.shmmax)
return (EINVAL);
@@ -473,7 +473,7 @@ sys_shmget(struct proc *p, void *v, register_t *retval)
segnum = shm_find_segment_by_key(SCARG(uap, key));
if (segnum >= 0)
return (shmget_existing(p, uap, mode, segnum, retval));
- if ((SCARG(uap, shmflg) & IPC_CREAT) == 0)
+ if ((SCARG(uap, shmflg) & IPC_CREAT) == 0)
return (ENOENT);
}
error = shmget_allocate_segment(p, uap, mode, retval);
@@ -546,6 +546,28 @@ shminit(void)
shm_committed = 0;
}
+/* Expand shmsegs and shmseqs arrays */
+void
+shm_reallocate(int val)
+{
+ struct shmid_ds **newsegs;
+ unsigned short *newseqs;
+ newsegs = mallocarray(val, sizeof(struct shmid_ds *),
+ M_SHM, M_WAITOK|M_ZERO);
+ memcpy(newsegs, shmsegs,
+ shminfo.shmmni * sizeof(struct shmid_ds *));
+ free(shmsegs, M_SHM,
+ shminfo.shmmni * sizeof(struct shmid_ds *));
+ shmsegs = newsegs;
+ newseqs = mallocarray(val, sizeof(unsigned short), M_SHM,
+ M_WAITOK|M_ZERO);
+ memcpy(newseqs, shmseqs,
+ shminfo.shmmni * sizeof(unsigned short));
+ free(shmseqs, M_SHM, shminfo.shmmni * sizeof(unsigned short));
+ shmseqs = newseqs;
+ shminfo.shmmni = val;
+}
+
/*
* Userland access to struct shminfo.
*/
@@ -554,26 +576,14 @@ sysctl_sysvshm(int *name, u_int namelen, void *oldp,
size_t *oldlenp,
void *newp, size_t newlen)
{
int error, val;
- struct shmid_ds **newsegs;
- unsigned short *newseqs;
- if (namelen != 2) {
- switch (name[0]) {
- case KERN_SHMINFO_SHMMAX:
- case KERN_SHMINFO_SHMMIN:
- case KERN_SHMINFO_SHMMNI:
- case KERN_SHMINFO_SHMSEG:
- case KERN_SHMINFO_SHMALL:
- break;
- default:
-return (ENOTDIR); /* overloaded */
-}
-}
+ if (namelen != 1)
+return (ENOTDIR); /* leaf-only */
switch (name[0]) {
case KERN_SHMINFO_SHMMAX:
- if ((error = sysctl_int(oldp, oldlenp, newp, newlen,
- &shminfo.shmmax)) || newp == NULL)
+ if ((error = sysctl_int_bounded(oldp, oldlenp, newp, newlen,
+ &shminfo.shmmax, 0, INT_MAX)) || newp == NULL)
return (error);
/* If new shmmax > shmall, crank shmall */
@@ -581,57 +591,25 @@ sysctl_sysvshm(int *name, u_int namelen, void *oldp,
size_t *oldlenp,
shminfo.shmall = atop(round_page(shminfo.shmmax));
return (0);
case KERN_SHMINFO_SHMMIN:
- val = shminfo.shmmin;
- if ((error = sysctl_int(oldp, oldlenp, newp, newlen, &val)) ||
- val == shminfo.shmmin)
- return (error);
- if (val <= 0)
- return (EINVAL);/* shmmin must be >= 1 */
- shminfo.shmmin = val;
- return (0);
+ return (sysctl_int_bounded(oldp, oldlenp, newp, newlen,
+ &shminfo.shmmin, 1, INT_MAX));
case KERN_SHMINFO_SHMMNI:
val = shminfo.shmmni;
- if ((error = sysctl_int(oldp, oldlenp, newp, newlen, &val)) ||
- val == shminfo.shmmni)
+ /* can't decrease shmmni */
+ error = sysctl_int_bounded(oldp, oldlenp, newp, newlen,
+ &val, v
Re: find -exec util {} arg + confusion
On Mon, Nov 16, 2020 at 09:04:53AM +0100, Paul de Weerd wrote:
> Hi Alexander,
>
> On Sun, Nov 15, 2020 at 10:22:32PM +0100, Alexander Hall wrote:
> | I googled for "POSIX find", and hit this:
> |
> | https://pubs.opengroup.org/onlinepubs/009695399/utilities/find.html
> |
> | => "Only a plus sign that follows an argument containing the two
> | characters "{}" shall punctuate the end of the primary expression.
> | Other uses of the plus sign shall not be treated as special."
>
> Yep, I also found that when looking into this. It's unforunate, as it
> implies you can't use `-exec {} ... +` with e.g. ln, mv or cp, but oh
> well.
>
> (also, nitpicking, 'an argument containing the two characters "{}"'
> includes an argument like "hh}hh{hh", which I'm pretty sure is not
> what they mean)
>
> | What you do in your diff is exactly that, treating it special.
>
> I'm not sure I agree. I make sure I do not treat it special unless
^^
> it's at the end of the argument to 'exec'. Can you elaborate on what
^
> you mean here?
If it is not following {}, then it should not be treated as such. You
are assuming (or guessing) it was meant to be that special '+'.
Carefully crafted example of failing quoting of ';':
$ obj/find . -exec echo + ;# Just print a '+' for every entry
find: -exec: "+" should follow {}
The more I read and think about it, I feel the original error message is
actually correct in that there is no terminating ";" or "+", since the
required condition for it is not fullfilled...
/Alexander
>
> Thanks!
>
> Paul
>
> --
> >[<++>-]<+++.>+++[<-->-]<.>+++[<+
> +++>-]<.>++[<>-]<+.--.[-]
> http://www.weirdnet.nl/
>
Re: macppc clang: fix va_arg in Objective-C
> Date: Mon, 16 Nov 2020 15:59:13 -0500 > From: George Koehler > > On Wed, 4 Nov 2020 00:21:15 -0500 > George Koehler wrote: > > > Hello tech list, > > > > clang for 32-bit powerpc has a bug that breaks va_arg(3) when the > > argument type is an object or block in Objective-C. This breaks > > GNUstep on macppc. This clang diff fixes GNUstep. Objective-C uses > > pointers to represent objects and blocks, so this diff tells clang's > > va_arg to handle things with pointer representations as pointers. > > > > Anthony Richardby found and reported the bug, > > https://bugs.llvm.org/show_bug.cgi?id=47921 > > I want this diff (also at https://reviews.llvm.org/D90329). The first > change (isInt) fixes GNUstep, in a simpler way than my diff from 2 weeks > ago. The second change (isIndirect) fixes va_arg(3) with some C++ types. > The diff only affects 32-bit powerpc. > > ok to commit? Looks reasonable to me; ok kettenis@ > Index: clang/lib/CodeGen/TargetInfo.cpp > === > RCS file: /cvs/src/gnu/llvm/clang/lib/CodeGen/TargetInfo.cpp,v > retrieving revision 1.1.1.2 > diff -u -p -r1.1.1.2 TargetInfo.cpp > --- clang/lib/CodeGen/TargetInfo.cpp 9 Aug 2020 15:51:11 - 1.1.1.2 > +++ clang/lib/CodeGen/TargetInfo.cpp 10 Nov 2020 11:41:53 - > @@ -4248,13 +4248,12 @@ Address PPC32_SVR4_ABIInfo::EmitVAArg(Co >// }; > >bool isI64 = Ty->isIntegerType() && getContext().getTypeSize(Ty) == 64; > - bool isInt = > - Ty->isIntegerType() || Ty->isPointerType() || Ty->isAggregateType(); > + bool isInt = !Ty->isFloatingType(); >bool isF64 = Ty->isFloatingType() && getContext().getTypeSize(Ty) == 64; > >// All aggregates are passed indirectly? That doesn't seem consistent >// with the argument-lowering code. > - bool isIndirect = Ty->isAggregateType(); > + bool isIndirect = isAggregateTypeForABI(Ty); > >CGBuilderTy &Builder = CGF.Builder; > > >
Re: macppc clang: fix va_arg in Objective-C
On Wed, 4 Nov 2020 00:21:15 -0500 George Koehler wrote: > Hello tech list, > > clang for 32-bit powerpc has a bug that breaks va_arg(3) when the > argument type is an object or block in Objective-C. This breaks > GNUstep on macppc. This clang diff fixes GNUstep. Objective-C uses > pointers to represent objects and blocks, so this diff tells clang's > va_arg to handle things with pointer representations as pointers. > > Anthony Richardby found and reported the bug, > https://bugs.llvm.org/show_bug.cgi?id=47921 I want this diff (also at https://reviews.llvm.org/D90329). The first change (isInt) fixes GNUstep, in a simpler way than my diff from 2 weeks ago. The second change (isIndirect) fixes va_arg(3) with some C++ types. The diff only affects 32-bit powerpc. ok to commit? Index: clang/lib/CodeGen/TargetInfo.cpp === RCS file: /cvs/src/gnu/llvm/clang/lib/CodeGen/TargetInfo.cpp,v retrieving revision 1.1.1.2 diff -u -p -r1.1.1.2 TargetInfo.cpp --- clang/lib/CodeGen/TargetInfo.cpp9 Aug 2020 15:51:11 - 1.1.1.2 +++ clang/lib/CodeGen/TargetInfo.cpp10 Nov 2020 11:41:53 - @@ -4248,13 +4248,12 @@ Address PPC32_SVR4_ABIInfo::EmitVAArg(Co // }; bool isI64 = Ty->isIntegerType() && getContext().getTypeSize(Ty) == 64; - bool isInt = - Ty->isIntegerType() || Ty->isPointerType() || Ty->isAggregateType(); + bool isInt = !Ty->isFloatingType(); bool isF64 = Ty->isFloatingType() && getContext().getTypeSize(Ty) == 64; // All aggregates are passed indirectly? That doesn't seem consistent // with the argument-lowering code. - bool isIndirect = Ty->isAggregateType(); + bool isIndirect = isAggregateTypeForABI(Ty); CGBuilderTy &Builder = CGF.Builder;
Re: Import seq(1) from FreeBSD
On Mon, 16 Nov 2020 16:14:31 +0100, Ingo Schwarze wrote: > are you really sure this is a good idea? The version you sent is > wildly incompatible with GNU sed. So we add a non-standard utility > that exhibits different behaviour on different systems even though > a standard utility already exists for the purpose? I don't think we need to be bug-compatible with GNU seq and characterizing jot as a "standard utility" is simply not accurate. >$ seq 3 -1 10 ; echo $? > seq: needs positive increment > 1 >$ gseq 3 -1 10 ; echo $? > 0 This is not valid usage, you cannot get to 10 from 3 with a negative increment. We could silently exit like GNU seq if that is desirable but is silently ignoring a usage error really what we want? >$ seq 3 0 10 ; echo $? > seq: zero increment > 1 >$ gseq 3 0 10 ; echo $? > gseq: Abort trap (core dumped) > 134 I get the following: gseq: invalid Zero increment value: ‘0’ Try 'gseq --help' for more information. >$ seq 3 1 ; echo $? > 3 > 2 > 1 > 0 >$ gseq 3 1 ; echo $? > 0 GNU seq uses a default increment of 1 even if first > last. Personally, I think using a default increment of -1 makes more sense in the above case, but we can easily make this match the GNU behavior if we desire. >$ seq -f '%a' 3 > 0x1p+0 > 0x1p+1 > 0x1.8p+1 >$ gseq -f '%a' 3 > 0x8p-3 > 0x8p-2 > 0xcp-2 The BSD seq output is consistent with printf(1), GNU seq is not. I'd classify this as a GNU bug. >$ seq -f '%i' 3 > seq: invalid format string: `%i' >$ gseq -f '%i' 3 > gseq: Abort trap (core dumped) I get: gseq: format ‘%i’ has unknown %i directive >$ seq -s / 3 ; echo $? > 1/2/3/0 >$ gseq -s / 3 ; echo $? > 1/2/3 > 0 The missing newline appears to be a bug in the FreeBSD seq, NetBSD seq works correctly. >$ seq -s '.\n' 3 ; echo $? > 1. > 2. > 3. > 0 >$ gseq -s '.\n' 3 ; echo $? > 1.\n2.\n3 > 0 GNU seq does not support C-style escapes such as \n and \t. Plan 9 seq has no -s option. >$ seq -s / -t '\n' 3 ; echo $? > 1/2/3/ > 0 >$ gseq -s / -t '\n' 3 ; echo $? > gseq: unknown option -- t > Try 'gseq --help' for more information. > 1 >$ seq --help > seq: unknown option -- help > usage: seq [-w] [-f format] [-s string] [-t string] [first [incr]] last >$ gseq --help > [... prints a novel ...] Looks like a bug in BSD seq. >$ seq 0 .5 1 > 0 > 0.5 > 1 >$ gseq 0 .5 1 > 0.0 > 0.5 > 1.0 BSD seq output is consistent with Plan 9 but different from GNU. I'm happy to fix the actual bugs. I think we should be trying to match GNU seq behavior where possible so we can use seq in ports. - todd
Re: Import seq(1) from FreeBSD
Hi Todd, are you really sure this is a good idea? The version you sent is wildly incompatible with GNU sed. So we add a non-standard utility that exhibits different behaviour on different systems even though a standard utility already exists for the purpose? Is this needed for porting work? If so, which behavour is more commonly expected - GNU compatible or FreeBSD compatible? Would it be picked up by ./configure in ports, and to what effect? Yours, Ingo $ seq 3 -1 10 ; echo $? seq: needs positive increment 1 $ gseq 3 -1 10 ; echo $? 0 $ seq 3 0 10 ; echo $? seq: zero increment 1 $ gseq 3 0 10 ; echo $? gseq: Abort trap (core dumped) 134 $ seq 3 1 ; echo $? 3 2 1 0 $ gseq 3 1 ; echo $? 0 $ seq -f '%a' 3 0x1p+0 0x1p+1 0x1.8p+1 $ gseq -f '%a' 3 0x8p-3 0x8p-2 0xcp-2 $ seq -f '%i' 3 seq: invalid format string: `%i' $ gseq -f '%i' 3 gseq: Abort trap (core dumped) $ seq -s / 3 ; echo $? 1/2/3/0 $ gseq -s / 3 ; echo $? 1/2/3 0 $ seq -s '.\n' 3 ; echo $? 1. 2. 3. 0 $ gseq -s '.\n' 3 ; echo $? 1.\n2.\n3 0 $ seq -s / -t '\n' 3 ; echo $? 1/2/3/ 0 $ gseq -s / -t '\n' 3 ; echo $? gseq: unknown option -- t Try 'gseq --help' for more information. 1 $ seq --help seq: unknown option -- help usage: seq [-w] [-f format] [-s string] [-t string] [first [incr]] last $ gseq --help [... prints a novel ...] $ seq 0 .5 1 0 0.5 1 $ gseq 0 .5 1 0.0 0.5 1.0
Re: dt: add kernel function boundary tracing provider
As requested by Philip Guenther here is more information on how to use
this new dt provider.
After applying the diff you need to add to /etc/sysctl.conf
ddb.profile=1
kern.allowdt=1
kern.allowkmem=1
There are two way to start the tracing.
The first one is to use kgmon that will instantiate all entry probes,
gprof for reading the gmon.out files.
The second one is whith btrace. Btrace can take scripts as input to
start tracing. It follows the bpftrace language.
Here is the bpftrace man:
https://www.mankier.com/8/bpftrace
Example of a simple script that you can write.
(btrace -l for the list of available probes)
BEGIN
{
@open_entry = 0;
@open_ret = 0;
}
kprobe:sys_pread:entry
{
printf("sys_open: %d\n", @open_entry);
@open_entry = @open_entry + 1;
//Dump all cpus used
@[cpu] = count();
}
kprobe:sys_pread:return
{
printf("sys_ret: %d\n", @open_entry);
@ret_entry = @open_entry + 1;
}
Printf are done at trace time whereas maps (@[...]) are dumped when the
tracing is ended with Ctr-c.
Tom
Re: Import seq(1) from FreeBSD
On 2020/11/16 05:49, Todd C. Miller wrote: > This is originally from NetBSD but FreeBSD appears to have some > additional fixes. > > I know we have jot(1) but seq(1) is considerably easier to use for > simple things and at this point, most other systems have it. OK with me. If this goes in then patches/symlinks can be removed from a handful of ports (they're mostly taught to use gseq from coreutils). devel/ccache devel/universal-ctags mail/notmuch/notmuch net/isc-bind net/munin net/rrdtool security/cvechecker
Re: uvm_pagealloc() & uvm.free accounting
On 13/11/20(Fri) 21:05, Mark Kettenis wrote:
> [...]
> > Careful reviewers will spot an off-by-one change in the check for
> > pagedaemon's reserved memory. My understanding is that it's a bugfix,
> > is it correct?
>
> You mean for uvm_pagealloc(). I'd say yes. But this does mean that
> in some sense the pagedaemon reserve grows by a page at the cost of
> the kernel reserve. So I think it would be a good idea to bump the
> kernel reserve a bit. Maybe to 8 pages?
Fine with me. Could you do it?
> > I also started to document the locking for some of the `uvmexp' fields.
> > I'm well aware that reading `uvmexp.free' is done without the correct
> > lock in the pagedaemon, this will be addressed soon. The other accesses
> > shouldn't matter much as they are not used to make decisions.
> >
> > This should hopefully be good enough to make uvm_pagealloc() completely
> > mp-safe, something that matters much because it's called from pmap_enter(9)
> > on some architectures.
> >
> > ok?
>
> Some additional comments below...
Updated diff addressing your comments below, ok?
Index: uvm/uvm_extern.h
===
RCS file: /cvs/src/sys/uvm/uvm_extern.h,v
retrieving revision 1.154
diff -u -p -r1.154 uvm_extern.h
--- uvm/uvm_extern.h19 Oct 2020 08:19:46 - 1.154
+++ uvm/uvm_extern.h16 Nov 2020 13:09:39 -
@@ -142,14 +142,15 @@ typedef int vm_prot_t;
#defineUVM_PGA_ZERO0x0002 /* returned page must be zeroed
*/
/*
- * flags for uvm_pglistalloc()
+ * flags for uvm_pglistalloc() also used by uvm_pmr_getpages()
*/
#define UVM_PLA_WAITOK 0x0001 /* may sleep */
#define UVM_PLA_NOWAIT 0x0002 /* can't sleep (need one of the two) */
#define UVM_PLA_ZERO 0x0004 /* zero all pages before returning */
#define UVM_PLA_TRYCONTIG 0x0008 /* try to allocate contig physmem */
#define UVM_PLA_FAILOK 0x0010 /* caller can handle failure */
-#define UVM_PLA_NOWAKE 0x0020 /* don't wake the page daemon on
failure */
+#define UVM_PLA_NOWAKE 0x0020 /* don't wake page daemon on failure */
+#define UVM_PLA_USERESERVE 0x0040 /* can allocate from kernel reserve */
/*
* lockflags that control the locking behavior of various functions.
Index: uvm/uvm_page.c
===
RCS file: /cvs/src/sys/uvm/uvm_page.c,v
retrieving revision 1.150
diff -u -p -r1.150 uvm_page.c
--- uvm/uvm_page.c 22 Sep 2020 14:31:08 - 1.150
+++ uvm/uvm_page.c 16 Nov 2020 13:11:19 -
@@ -733,32 +733,11 @@ uvm_pglistalloc(psize_t size, paddr_t lo
size = atop(round_page(size));
/*
-* check to see if we need to generate some free pages waking
-* the pagedaemon.
-*/
- if ((uvmexp.free - BUFPAGES_DEFICIT) < uvmexp.freemin ||
- ((uvmexp.free - BUFPAGES_DEFICIT) < uvmexp.freetarg &&
- (uvmexp.inactive + BUFPAGES_INACT) < uvmexp.inactarg))
- wakeup(&uvm.pagedaemon);
-
- /*
* XXX uvm_pglistalloc is currently only used for kernel
* objects. Unlike the checks in uvm_pagealloc, below, here
-* we are always allowed to use the kernel reserve. However, we
-* have to enforce the pagedaemon reserve here or allocations
-* via this path could consume everything and we can't
-* recover in the page daemon.
+* we are always allowed to use the kernel reserve.
*/
- again:
- if ((uvmexp.free <= uvmexp.reserve_pagedaemon + size &&
- !((curproc == uvm.pagedaemon_proc) ||
- (curproc == syncerproc {
- if (flags & UVM_PLA_WAITOK) {
- uvm_wait("uvm_pglistalloc");
- goto again;
- }
- return (ENOMEM);
- }
+ flags |= UVM_PLA_USERESERVE;
if ((high & PAGE_MASK) != PAGE_MASK) {
printf("uvm_pglistalloc: Upper boundary 0x%lx "
@@ -871,7 +850,7 @@ uvm_pagerealloc_multi(struct uvm_object
}
/*
- * uvm_pagealloc_strat: allocate vm_page from a particular free list.
+ * uvm_pagealloc: allocate vm_page from a particular free list.
*
* => return null if no pages free
* => wake up pagedaemon if number of free pages drops below low water mark
@@ -886,37 +865,21 @@ uvm_pagealloc(struct uvm_object *obj, vo
struct vm_page *pg;
struct pglist pgl;
int pmr_flags;
- boolean_t use_reserve;
KASSERT(obj == NULL || anon == NULL);
+ KASSERT(anon == NULL || off == 0);
KASSERT(off == trunc_page(off));
- /*
-* check to see if we need to generate some free pages waking
-* the pagedaemon.
-*/
- if ((uvmexp.free - BUFPAGES_DEFICIT) < uvmexp.freemin ||
- ((uvmexp.free - BUFPAGES_DEFICIT) < uvmexp.freetarg &&
- (uvmexp.inactive + BUFPAGES_INACT)
Import seq(1) from FreeBSD
This is originally from NetBSD but FreeBSD appears to have some
additional fixes.
I know we have jot(1) but seq(1) is considerably easier to use for
simple things and at this point, most other systems have it.
- todd
Index: usr.bin/seq/Makefile
===
RCS file: usr.bin/seq/Makefile
diff -N usr.bin/seq/Makefile
--- /dev/null 1 Jan 1970 00:00:00 -
+++ usr.bin/seq/Makefile16 Nov 2020 03:52:57 -
@@ -0,0 +1,8 @@
+# $OpenBSD$
+
+PROG= seq
+CFLAGS+= -Wall
+LDADD+=-lm
+DPADD+=${LIBM}
+
+.include
Index: usr.bin/seq/seq.1
===
RCS file: usr.bin/seq/seq.1
diff -N usr.bin/seq/seq.1
--- /dev/null 1 Jan 1970 00:00:00 -
+++ usr.bin/seq/seq.1 16 Nov 2020 12:46:44 -
@@ -0,0 +1,206 @@
+.\"$OpenBSD$
+.\"
+.\" Copyright (c) 2005 The NetBSD Foundation, Inc.
+.\" All rights reserved.
+.\"
+.\" This code is derived from software contributed to The NetBSD Foundation
+.\" by Brian Ginsbach.
+.\"
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"notice, this list of conditions and the following disclaimer in the
+.\"documentation and/or other materials provided with the distribution.
+.\"
+.\" THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
+.\" ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
+.\" TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+.\" PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
+.\" BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+.\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+.\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+.\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+.\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+.\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+.\" POSSIBILITY OF SUCH DAMAGE.
+.\"
+.Dd $Mdocdate$
+.Dt SEQ 1
+.Os
+.Sh NAME
+.Nm seq
+.Nd print sequences of numbers
+.Sh SYNOPSIS
+.Nm
+.Op Fl w
+.Op Fl f Ar format
+.Op Fl s Ar string
+.Op Fl t Ar string
+.Op Ar first Op Ar incr
+.Ar last
+.Sh DESCRIPTION
+The
+.Nm
+utility prints a sequence of numbers, one per line
+.Pq default ,
+from
+.Ar first
+.Pq default 1 ,
+to near
+.Ar last
+as possible, in increments of
+.Ar incr
+.Pq default 1 .
+When
+.Ar first
+is larger than
+.Ar last ,
+the default
+.Ar incr
+is -1.
+.Pp
+All numbers are interpreted as floating point.
+.Pp
+Normally integer values are printed as decimal integers.
+.Pp
+The
+.Nm
+utility accepts the following options:
+.Bl -tag -width Ar
+.It Fl f Ar format , Fl -format Ar format
+Use a
+.Xr printf 3
+style
+.Ar format
+to print each number.
+Only the
+.Cm A ,
+.Cm a ,
+.Cm E ,
+.Cm e ,
+.Cm F ,
+.Cm f ,
+.Cm G ,
+.Cm g ,
+and
+.Cm %
+conversion characters are valid, along with any optional
+flags and an optional numeric minimum field width or precision.
+The
+.Ar format
+can contain character escape sequences in backslash notation as
+defined in
+.St -ansiC .
+The default is
+.Cm %g .
+.It Fl s Ar string , Fl -separator Ar string
+Use
+.Ar string
+to separate numbers.
+The
+.Ar string
+can contain character escape sequences in backslash notation as
+defined in
+.St -ansiC .
+The default is
+.Cm \en .
+.It Fl t Ar string , Fl -terminator Ar string
+Use
+.Ar string
+to terminate sequence of numbers.
+The
+.Ar string
+can contain character escape sequences in backslash notation as
+defined in
+.St -ansiC .
+This option is useful when the default separator
+does not contain a
+.Cm \en .
+.It Fl w , Fl -fixed-width
+Equalize the widths of all numbers by padding with zeros as necessary.
+This option has no effect with the
+.Fl f
+option.
+If any sequence numbers will be printed in exponential notation,
+the default conversion is changed to
+.Cm %e .
+.El
+.Sh EXIT STATUS
+.Ex -std
+.Sh EXAMPLES
+Generate a sequence from 1 to 3 (included) with a default increment of 1:
+.Bd -literal -offset indent
+# seq 1 3
+1
+2
+3
+.Ed
+.Pp
+Generate a sequence from 3 to 1 (included) with a default increment of -1:
+.Bd -literal -offset indent
+# seq 3 1
+3
+2
+1
+.Ed
+.Pp
+Generate a sequence from 0 to 0.1 (included) with an increment of 0.05 and
padding
+with leading zeroes.
+.Bd -literal -offset indent
+# seq -w 0 .05 .1
+0.00
+0.05
+0.10
+.Ed
+.Pp
+Generate a sequence from 1 to 3 (included) with a default increment of 1,
+a custom separator string and a custom terminator:
+.Bd -literal -offset indent
+# seq -s "-->"
Re: Convert sysctl_sysvsem to sysctl_bounded_args
On Sat, 14 Nov 2020 21:09:59 -0800, Greg Steuck wrote: > I went a tiny bit beyond pure textual conversion and moved a bit of code. OK millert@ - todd
Re: Convert fusefs_sysctl to sysctl_bounded_args
On Sat, 14 Nov 2020 21:05:39 -0800, Greg Steuck wrote: > This is trivial more-of-the-same. If somebody spots a bug, do speak > up. I feel pretty good about committing this promptly. OK millert@ - todd
Re: Remove the cases folded into sysctl_bounded_args but left behind
On Sat, 14 Nov 2020 21:08:09 -0800, Greg Steuck wrote: > This an "oops" moment... The code remained correct, but I forgot to > remove junk after converting it. OK millert@ - todd
Re: find -exec util {} arg + confusion
Hi Andreas,
On Mon, Nov 16, 2020 at 08:53:36AM +0100, Andreas Kusalananda Kähäri wrote:
| On Thu, Nov 12, 2020 at 08:51:22PM +0100, Paul de Weerd wrote:
| > Hi all,
| >
| > I misread find(1) and did:
| >
| > [weerdpom] $ find path/to/cam -name \*.JPG -exec cp {} path/to/store +
| > find: -exec no terminating ";" or "+"
|
| Not really what you're asking for, but...
|
| What you seem to want to do can be done with
|
| find path/to/cam -name '*.JPG' -exec sh -c 'cp "$@" path/to/store' sh
{} +
Thanks, I've solved this in the past with small scripts in my homedir
or going to `find | xargs -J`. I'll add your suggestion to my list.
| Or, with GNU coreutils installed,
|
| find path/to/cam -name '*.JPG' -exec gcp -t path/to/store {} +
Ugh, installing GNU stuff for something like this... :) Besides, the
problem is more generic than just cp(1). Do all GNU tools that (by
default) have the target argument as the last argument support -t? I
mean, I know cp, mv and ln do, but do they all?
| I quite like Alexander's proposed smaller diff.
Making it more clear to the user that + must follow {} is the thing
I'd like to achieve, so yeah :) No strong feelings over his vs my
diff.
Cheers,
Paul
--
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
http://www.weirdnet.nl/
Re: find -exec util {} arg + confusion
Hi Alexander,
On Sun, Nov 15, 2020 at 10:22:32PM +0100, Alexander Hall wrote:
| I googled for "POSIX find", and hit this:
|
| https://pubs.opengroup.org/onlinepubs/009695399/utilities/find.html
|
| => "Only a plus sign that follows an argument containing the two
| characters "{}" shall punctuate the end of the primary expression.
| Other uses of the plus sign shall not be treated as special."
Yep, I also found that when looking into this. It's unforunate, as it
implies you can't use `-exec {} ... +` with e.g. ln, mv or cp, but oh
well.
(also, nitpicking, 'an argument containing the two characters "{}"'
includes an argument like "hh}hh{hh", which I'm pretty sure is not
what they mean)
| What you do in your diff is exactly that, treating it special.
I'm not sure I agree. I make sure I do not treat it special unless
it's at the end of the argument to 'exec'. Can you elaborate on what
you mean here?
Thanks!
Paul
--
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
http://www.weirdnet.nl/
