Re: pfctl interprets "# ... \" as multi-line comment and can skip rules

On 16/01/2016 5:52 PM, Theo de Raadt wrote: I've been using pf for years and really like it. I accidentally discovered some undesirable behavior from the rule parser that caused some rules to be skipped. This has happened to me twice and there was much hair pulling. The short version is rules

Proper printf attribute in less(1)

Michael Reed and I noticed the straggling lintism PRINTFLIKE1 in less(1). Should it be replaced with an attribute? If so, am I doing this right? Index: funcs.h === RCS file: /cvs/src/usr.bin/less/funcs.h,v retrieving revision 1.17

Re: [patch] ls + utf-8 support

Martin Natano wrote: > I agree with Ingo, ls(1) shouldn't generate unsafe output. Regardless > of whether the output is to a terminal or some other file. While POSIX is not holy law, doing what you suggest would probably be a violation. See the description of the -q option:

Re: [PATCH] uname, arch/machine -> %c, %a update in PKG_PATH

Raf Czlonka wrote: > Hi all, > > Given that PKG_PATH and pkg.conf(5)'s installpath, now supports %c, %a, > etc. sequences, it might be worth advertising it a bit more by changing > all relevant uname(1), arch(1)/machine(1) occurrences or (hard-coded > release versions or hardware architectures

Re: [patch] ls + utf-8 support

Ingo Schwarze wrote: > The old ls(1) also weeded out non-printable bytes, in particular > control codes. The old ls only had this behavior for terminals however. Redirecting to a file or pipe would always output the original bytes.

Re: [patch] ls + utf-8 support

On 2016/01/17 14:29, Ted Unangst wrote: > Ingo Schwarze wrote: > > The old ls(1) also weeded out non-printable bytes, in particular > > control codes. > > The old ls only had this behavior for terminals however. Redirecting to a file > or pipe would always output the original bytes. I've used

Re: Perl 5.22.1 testing request + issue on alpha

> I have run into a strange issue on alpha that I'm still tracking down. > I fear this has interrupted me too long to get 5.22 in for OpenBSD 5.9, > but maybe we can get ahead of the curve and be ready after unlock. > > Previously, NaN + 1 looked like this: > $ perl -we 'print "NaN" + 1' > -nan >

Re: [patch] ls + utf-8 support

I agree with Ingo, ls(1) shouldn't generate unsafe output. Regardless of whether the output is to a terminal or some other file. cheers, natano

Re: [patch] ls + utf-8 support

And now with the patch... - Forwarded message from Ingo Schwarze - From: Ingo Schwarze Date: Sun, 17 Jan 2016 21:37:56 +0100 To: Stuart Henderson , Ted Unangst Cc: Martijn van Duren

Re: [patch] ls + utf-8 support

Hi, Stuart Henderson wrote on Sun, Jan 17, 2016 at 07:46:23PM +: > On 2016/01/17 14:29, Ted Unangst wrote: >> Ingo Schwarze wrote: >>> The old ls(1) also weeded out non-printable bytes, in particular >>> control codes. >> The old ls only had this behavior for terminals however. >>

morse(6) update

Update for the current spec which includes an official prosign for @ (I'm not sure where the old one we had came from but it's not the right thing to use nowadays) and distinct parentheses. OK? Index: morse.6 === RCS file:

Re: morse(6) update

Stuart Henderson writes: > Update for the current spec which includes an official prosign for @ > (I'm not sure where the old one we had came from but it's not the right > thing to use nowadays) and distinct parentheses. > > OK? OK abieber@ if you haven't gotten one yet. > > Index: morse.6 >

Re: [PATCH] mount_tmpfs -P option for populating after mounting (simplified)

ping. On Sun, 13 Sep 2015 14:50:19 +0100 bytevolc...@safe-mail.net wrote: > Hello, > > Although a patch like this was submitted before, this one is more > "focused". It may be useful for those moving from MFS who use this > option to pre-populate an MFS mount with a collection of files. This >

Re: [patch] ls + utf-8 support

Hi Martijn, Martijn van Duren wrote on Sun, Jan 17, 2016 at 12:58:38PM +0100: > I've come across a fair amount of malformed file names by all sorts > of causes. Be it malware or just human error. When such a malformed > character is in an inconvenient place and can't be auto-completed > I

Re: start UTF-8 support for ksh(1) vi editing mode

Hi Martin, hi Theo, thank you for your feedback! Martijn van Duren wrote on Sun, Jan 17, 2016 at 12:06:26PM +0100: > When applying this patch and running in an environment without an > UTF-8 LC_ALL or LC_CTYPE the isu8cont gives the reverse problem of > the current ksh having UTF-8 filenames