Re: refine of the GSOC project

ols for the new kernel version? Or USETOOLS=NO if it is something quick and dirty... -- Brett Lymn Let go, or be dragged - Zen proverb.

Re: curses: Visible cursor not set with wmove

w. > Anyway--is this a known bug for NetBSD curses? > It may be a bug or it may be correct behaviour - we need to check the specifications. The fact that it behaves differently in ncurses is not necessarily an indication we have a bug - the ncurses implementation may be bugged :) -- Brett Lymn

Re: curses: Home key sends 0x162 in tmux

nitions of the keys from the terminfo entry. If that has mapped HOME to mean BEGIN (which doesn't sound unreasonable) then that is what curses will do. -- Brett Lymn Let go, or be dragged - Zen proverb.

Re: curses: Home key sends 0x162 in tmux

On Tue, Nov 29, 2016 at 10:20:21PM +0100, Carsten Kunze wrote: > Brett Lymn <bl...@internode.on.net> wrote: > > > What does the output of infocmp look like? Curses pulls the definitions > > of the keys from the terminfo entry. If that has mapped HOME to mean > &

Re: NetBSD on embedded devices

ing for live upgrade can be confusing as a lot of hits will talk about upgrading solaris but live upgrade can also be used for patching the operating system. -- Brett Lymn Let go, or be dragged - Zen proverb.

Re: curses: create panel from stdscr?

y because the native curses "does not work". It is wrong and a pain but ncurses has the larger market share so whatever we do different is considered a but so we may as well just suck it up and make our libpanel have the same brokenness. -- Brett Lymn Let go, or be dragged - Zen proverb.

Re: curses bug - incorrect curx at end of line

Looks good to me, go for it. Thanks (sorry for the top post... damn webmail)  - Original Message - From: "Simon Burge" To: Cc:"Julian Coleman" Sent:Mon, 06 Aug 2018 18:07:38 +1000 Subject:curses bug - incorrect curx at end of line Hi folks, Every now and then I've seen vi report

Re: Pressure sensors

ars and just > duck the occasional brickbat from metrication nuts. > Hmmm... 3 countries in the world don't use the metric system. U.S.A, Libria and Myanmar...says a lot really :P -- Brett Lymn "We are were wolves", "You mean werewolves?", "No we were wolves, now we are something else entirely", "Oh"

Re: namespace pollution by curses

is allowed for but  I have never tested it and I wouldn't be surprised if it failed spectacularly. - Original Message - From: "Valery Ushakov" To: Cc:"Brett Lymn" , "Rin Okuyama" Sent:Tue, 12 Mar 2019 13:25:13 +0300 Subject:Re: namespace pollution by curses On

Re: Add curses_version() in curses(3)

Sorry for the top post... I agree with Roy here, if we add the call we should spit out the version of the curses lib.  If someone tries to interpret the contents of the return without consulting the man pages and derives false information then that is their issue - really the call name should be

Re: Add curses_version() in curses(3)

. > Sadly, matching the somewhat egregious behaviours of ncurses does result in fewer PRs of the ilk "it works this way in ncurses..." -- Brett Lymn -- Sent from my NetBSD device. "We are were wolves", "You mean werewolves?", "No we were wolves, now we are something else entirely", "Oh"

Re: Solving the syslogd problem

at, on my laptop my /home is separate so I can run cgd on it. I just don't think that getting a machine up in single user is anything great, if the machine is not doing what it was set up to do then it is not up. -- Brett Lymn -- Sent from my NetBSD device. "We are were wolves"

Re: Solving the syslogd problem

are checked and mounted. So, so what if you get / first and then have to wait for the rest of the fsck's to happen vs a fsck of a single large file system? At the end of the day it will take about the same amount f time to get the machine to a usable state. -- Brett Lymn -- Sent from my NetBSD

Re: recent terminfo changes

K they don't apply to our curses. > > I only discovered the breakage when I fixed PR lib/23910 and Thomas reported > it was still broken with his terminal .. screen-256color. > OK, good to know. We may actually add different terminal types as part of GSOC - will wait and see if

Re: recent terminfo changes

d. > You know, from a personal perspective, I am a bit disappointed that the libcurses ATF didn't fail :( I know that sounds odd but it was supposed to catch this sort of thing. -- Brett Lymn -- Sent from my NetBSD device. "We are were wolves", "You mean werewolves?", &q

Re: toor shell

lt just in case pkgsrc or b0rked or other such travesties. Not a recommendation, just what I do :) -- Brett Lymn -- Sent from my NetBSD device. "We are were wolves", "You mean werewolves?", "No we were wolves, now we are something else entirely", "Oh"

Re: inetd enhancements - config syntax

is large enough then a legitimate configuration will work but an include loop will error out quickly. -- Brett Lymn -- Sent from my NetBSD device. "We are were wolves", "You mean werewolves?", "No we were wolves, now we are something else entirely", "Oh"

Re: Waiting for Randot (or: nia and maya were right and I was wrong)

On Fri, Jan 15, 2021 at 12:21:24AM +, Taylor R Campbell wrote: > > What about them? Systems without usable microphone noise are no worse > off than they would have been without nia's suggestion. > If we have network of some sort can we leverage packet timing jitter somehow? --

Re: Importing aiomixer to src

if libcurses hijacked the signal. -- Brett Lymn -- Sent from my NetBSD device. "We are were wolves", "You mean werewolves?", "No we were wolves, now we are something else entirely", "Oh"

Re: inetd tests failing

haps extend kevent to snoop on the setting of socket options on the daemon socket and replicate those settings on an incoming connection. Waving hands even faster, this may not work for all daemons, make it optional so if it blows up then just go back to the exec per connection method. -- Brett Ly

Re: inetd tests failing

f services? If > so, my apologies; that was not clear to me. > I believe so, it would be an option to pre-fork. -- Brett Lymn -- Sent from my NetBSD device. "We are were wolves", "You mean werewolves?", "No we were wolves, now we are something else entirely", "Oh"

Re: inetd tests failing

akes a lot of sense if the daemon is slow to start up and does not keep state between requests - simply putting the daemon instance back on the prefork queue saves time and load. The apache http daemon has been doing this for a long time... -- Brett Lymn -- Sent from my NetBSD device. &

Re: inetd tests failing

gt; > Unless you are thinking the forked children should stop themselves > instead of exiting and then *somehow* learn the new connection and exec > path for the next thing inetd wants to use them for? That's a lot more > moving parts and a lot more fragility than just letting the existing > chil

Re: ZFS - mounting filesystems (Was CVS commit: src/etc)

g - that nobody built a shim to fix it. > That would be one of the first things I would do if I were setting up > such a thing.) > There is no need - you can set a property on the file system not to automatically mount and perform a "legacy" mount in /etc/fstab if you so choos

to bump or note to bump

ange. Should I mark this with a libcurses major bump? I don't think it necessary but I am putting it out there for discussion... -- Brett Lymn -- Sent from my NetBSD device. "We are were wolves", "You mean werewolves?", "No we were wolves, now we are something else entirely", "Oh"

Re: to bump or note to bump

se it would be especially given that NetBSD libcurses is a fairly niche offering in a sea of ncurses I cannot see it getting much, if any, use. -- Brett Lymn -- Sent from my NetBSD device. "We are were wolves", "You mean werewolves?", "No we were wolves, now we are something else entirely", "Oh"

Re: Controlling Daemons (inetd or aunchd or relaunchd?)

in the true spirit of open source :) -- Brett Lymn -- Sent from my NetBSD device. "We are were wolves", "You mean werewolves?", "No we were wolves, now we are something else entirely", "Oh"

Re: Rationale for some rules in style guide

ly, scan down the declarations stopping on each line when past the sorted order, easier than an exhaustive search. -- Brett Lymn -- Sent from my NetBSD device. "We are were wolves", "You mean werewolves?", "No we were wolves, now we are something else entirely", "Oh"

Re: flock(2): locking against itself?

ronment. Yes, the refresh code is the hairiest part of the code and was the primary reason for writing the atf code. This is the code that you will be dealing with and it is deeply embedded. > > I have two use cases already, and I have two more which are vulnerable > to the same issue but

Re: flock(2): locking against itself?

e tied > to the OS that libcurses imposes? > No. I am not really sure what general use it would be. Sure, you have a very specific need, that I can understand but struggle with a generalised concept. > (c) If not, would there be any interest in such a thing? > Not from me. -- Brett Lymn

Re: flock(2): locking against itself?

d to a callback. That would address my use cases with a much less > intrusive change. > Have a look at cputchar.c - that is where all the output happens. -- Brett Lymn -- Sent from my NetBSD device. "We are were wolves", "You mean werewolves?", "No we were wolves, now we are something else entirely", "Oh"

Re: Rationale for some rules in style guide

re sorted and you are looking for "indicator" then you can stop after "height". You can be confident you have not missed the variable in the noise. -- Brett Lymn -- Sent from my NetBSD device. "We are were wolves", "You mean werewolves?", "No we were wolves, now we are something else entirely", "Oh"

Re: inetd(8): cmdif as builtin

ket to control inetd. I am not sure that inetd having a configuration service listening on the network is a really good idea - to me, it sounds dangerous and I am dubious that there are many situations that require remote configuration of inetd. -- Brett Lymn -- Sent from my NetBSD device. &quo

Re: [RFC] inetd(8) changes proposal

On Thu, Jun 01, 2023 at 09:08:52AM +0200, tlaro...@polynum.com wrote: > > But for now, it will be far simpler to only modify the NetBSD source > without trying to merge something external. > It isn't external - the mods were made to the NetBSD source code. -- Brett Lymn -- Sent fr

Re: [RFC] inetd(8) changes proposal

e able to use some of that code. -- Brett Lymn -- Sent from my NetBSD device. "We are were wolves", "You mean werewolves?", "No we were wolves, now we are something else entirely", "Oh"

Re: pulling in changes to nsswitch from FreeBSD?

source tree seems to reference NS_RETURN nor NS_CONTINUE... not even the nss source so I am left wondering what their role is. -- Brett Lymn -- Sent from my NetBSD device. "We are were wolves", "You mean werewolves?", "No we were wolves, now we are something else entirely", "Oh"

Re: Lua binding for curses

that I would make changes to the refresh code and would then be able to objectively check the refresh code was working. -- Brett Lymn -- Sent from my NetBSD device. "We are were wolves", "You mean werewolves?", "No we were wolves, now we are something else entirely", "Oh"

Re: Lua binding for curses

red by writing blanks to every cell instead of issuing a clear screen code then the output looks the same but there is a huge difference in the amount of characters emitted... which is part of the aim of curses. -- Brett Lymn -- Sent from my NetBSD device. "We are were wolves", "

pulling in changes to nsswitch from FreeBSD?

I am happy to do the work if it is deemed useful. -- Brett Lymn -- Sent from my NetBSD device. "We are were wolves", "You mean werewolves?", "No we were wolves, now we are something else entirely", "Oh"

Re: sysinst username length limit

ames either. I recall setting up a sunos 4 network in the early 90's and there definitely was a hard limit of 8 characters back then. I don't know if it ever changed because we adopted a user naming scheme that truncated the usernames to 8 characters until well after nis was gone from the network.

Re: GSOC - Inetd enhancements

of years ago. There was some progress made, particularly on a userland tool to control inetd. There is still plenty to be done but, perhaps, the previous code could be used as a starting point. -- Brett Lymn -- Sent from my NetBSD device. "We are were wolves", "You mean werewolves?&q

Re: Using mmap(2) in sort(1) instead of temp files

mory it might not even > actually > touch swap space. > Why not stat the input file and decide to use in memory iff the file is small enough? This way sort will handle large sorts on small memory machines automatically. -- Brett Lymn -- Sent from my NetBSD device. "We are were wol

Re: Using mmap(2) in sort(1) instead of temp files

time to perform the sort algorithm far outweighs the i/o time as has been noted by others. -- Brett Lymn -- Sent from my NetBSD device. "We are were wolves", "You mean werewolves?", "No we were wolves, now we are something else entirely", "Oh"