Re: mandoc -Tlint and Mdocdate
On Fri, Jun 23, 2017 at 07:24:31PM +0200, Ingo Schwarze wrote: > Hi Jason, > > Jason McIntyre wrote on Thu, Jun 22, 2017 at 07:31:49AM +0100: > > On Thu, Jun 22, 2017 at 01:18:05AM +0200, Ingo Schwarze wrote: > >> Jason McIntyre wrote on Wed, Jun 21, 2017 at 11:10:55PM +0100: > > >>> i'm not entirely convinced... are there likely to be other style > >>> warnings that apply to our base manuals but not "portable"? > >>> if there's a list of things then maybe it makes sense. > > >> Quite likely in the future: > >> [ ... 4 examples deleted ... ] > > > fair enough then, if you think it's worth doing. > > but aren't you worried that you're gonna end up with all > > operating systems/interested parties wanting their own flags? > > Not worried, no. I'm not expecting that many, a handful at most, > and even a dozen would be less of a maintenance burden than many > of the switch/case features contained in the mdoc(7) language itself. > > - illumos, definitely. > - FreeBSD, maybe. I have no indication yet that they may want >to use the feature, but it would fit their culture. > - Debian, possibly. If there is something that they can tweak, >they usually tweak it. If there is not, they tweak it anyway. >But i guess it will take several years before they find out. >They don't move all that fast, you know. > > - Alpine, Void, Arch, Slackware, Crux Linux: >Very unlikely. They tend to refrain from customization, and >from creatung unnecessary maintenance workload for themselves, >whenever they can. > > - DragonFly, Minix, MacOS X: >Very unlikely. These projects look like abandonware to me. > > No other project is actively using mandoc at this point. > It also runs on IBM AIX and Oracle Solaris, and there are many > unofficial, outdated ports for major Linux distros, but none of > these will request their own -Tlint customizations. > > Yours, > Ingo > evening. thanks for answering my questions. so i have no objections. jmc
Re: mandoc -Tlint and Mdocdate
Hi Jason, Jason McIntyre wrote on Thu, Jun 22, 2017 at 07:31:49AM +0100: > On Thu, Jun 22, 2017 at 01:18:05AM +0200, Ingo Schwarze wrote: >> Jason McIntyre wrote on Wed, Jun 21, 2017 at 11:10:55PM +0100: >>> i'm not entirely convinced... are there likely to be other style >>> warnings that apply to our base manuals but not "portable"? >>> if there's a list of things then maybe it makes sense. >> Quite likely in the future: >> [ ... 4 examples deleted ... ] > fair enough then, if you think it's worth doing. > but aren't you worried that you're gonna end up with all > operating systems/interested parties wanting their own flags? Not worried, no. I'm not expecting that many, a handful at most, and even a dozen would be less of a maintenance burden than many of the switch/case features contained in the mdoc(7) language itself. - illumos, definitely. - FreeBSD, maybe. I have no indication yet that they may want to use the feature, but it would fit their culture. - Debian, possibly. If there is something that they can tweak, they usually tweak it. If there is not, they tweak it anyway. But i guess it will take several years before they find out. They don't move all that fast, you know. - Alpine, Void, Arch, Slackware, Crux Linux: Very unlikely. They tend to refrain from customization, and from creatung unnecessary maintenance workload for themselves, whenever they can. - DragonFly, Minix, MacOS X: Very unlikely. These projects look like abandonware to me. No other project is actively using mandoc at this point. It also runs on IBM AIX and Oracle Solaris, and there are many unofficial, outdated ports for major Linux distros, but none of these will request their own -Tlint customizations. Yours, Ingo
Re: SSH ~& command crash with a coredump
committed, thanks for the report Gregoire! On 01:34 Fri 23 Jun , Jeremie Courreges-Anglas wrote: > Gr??goire Jadi writes: > > > n 06/21/17 12:16, Ricardo Mestre wrote: > >> Hi, > >> > >> I can confirm this issue, and the diff below seems to solve it for me. > >> > >> Could you please test it and let us know if it works on your side? > > > > It does fix the issue. Thanks you. > > > >> > >> Reason: In clientloop.c during client_loop() this function calls > >> client_simple_escape_filter() which then calls process_escapes() which in > >> turn > >> fork()s the process. That being said, the pledge inside client_loop which > >> applies to this code path lacks the proc promise and therefore aborts ssh. > > At first I couldn't reproduce the crash since I'm using "ControlMaster > auto". Since all the other pledge calls specify "proc", I don't think > it's a big drawback. ok jca@
