Re: Preferred TERM for pkg_add

>From a quick look it will happily fall back to carriage return and space if the capabilities it would prefer (el and hpa/RI) are not present, so probably anything would do. Or you could check if the terminfo entry existed with something like "tput el >/dev/null 2>&1" before running pkg_add.

Re: [patch 2/3] towards TERM=xterm

Reply inline. On Sun, 8 Jan 2023 at 21:38, Crystal Kolipe wrote: > On Sun, Jan 08, 2023 at 08:55:46PM +0000, Nicholas Marriott wrote: > > This is still too big for one go so I think it needs split further. I > > suggest that first we get three diffs with the very easy stuff: >

Re: [patch 2/3] towards TERM=xterm

This is still too big for one go so I think it needs split further. I suggest that first we get three diffs with the very easy stuff: 1) The two bug fixes 2) HPA/VPA/INDN/RIN Some other comments on the larger diff: - Why do you change RS_SCROLLBACK_SCREENS? - Wouldn't it be better to make

Re: Making wscons a bit more like xterm

Jan 07, 2023 at 11:09:00AM +0000, Nicholas Marriott wrote: > > As far as SGR 38/48 with anything except 2 and 5 goes - the only > terminals > > I have at hand do not discard but I think either of discarding or not > > discarding would be reasonable. What does xterm do h

Re: Making wscons a bit more like xterm

is brighter would be possible, although I haven't seen any terminals that do that. On Fri, 6 Jan 2023, 18:42 Crystal Kolipe, wrote: > On Fri, Jan 06, 2023 at 06:21:41PM +0000, Nicholas Marriott wrote: > > You should strictly only discard the following two arguments or stuff >

Re: Making wscons a bit more like xterm

or not discarding would be reasonable. What does xterm do here? It would probably be best to do the same. On Fri, 6 Jan 2023, 18:42 Crystal Kolipe, wrote: > On Fri, Jan 06, 2023 at 06:21:41PM +0000, Nicholas Marriott wrote: > > You should strictly only discard the following two

Re: Making wscons a bit more like xterm

You should strictly only discard the following two arguments or stuff like SGR 38;5;100;1 won't work. This is why some people prefer the : form but the ship has rather sailed on that. On Fri, 6 Jan 2023, 11:52 Crystal Kolipe, wrote: > This version of the patchset updates a few things since

Re: Making wscons a bit more like xterm

Hi It is a good idea to make wscons more like xterm, at least so far as setting TERM to xterm will not cause major problems for most programs. Hardly anything uses blinking and the lack of it will bother nobody so TBH I wouldn't worry too much about it. Your diff looks good to me, although it

Re: Patch: ksh: fix input handling for 4 byte UTF-8 sequences

Looks good to me, ok nicm On Wed, Jun 02, 2021 at 09:00:16PM +0200, Ingo Schwarze wrote: > Hi, > > feeling hesitant to commit into ksh without at least one proper OK, > i'm resending this patch here, sorry if i missed private feedback. > > What the existing code does: > It tries to make sure

Re: adjfreq(2): limit adjustment to prevent overflow during tc_windup()

10^12 was the old definition of billion in the UK also, although in the last few decades it has become rare and 10^9 is now the norm. https://en.wikipedia.org/wiki/Long_and_short_scales has quite a bit about it. On Tue, 7 Jul 2020 at 00:27, Scott Cheloha wrote: > On Mon, Jul 06, 2020 at

Re: top: Fill last character in process line

Actually I've got them the wrong way round here, but others have already explained them anyway :-). On Wed, Jun 03, 2020 at 05:04:43PM +0100, Nicholas Marriott wrote: > xenl (xm) only matters for the last line - you can't write into the very > bottom right position without causing the te

Re: top: Fill last character in process line

xenl (xm) only matters for the last line - you can't write into the very bottom right position without causing the terminal to scroll. No xenl is a pain and most applications solve it by just leaving that position always empty. The only terminal still about without xenl that I am aware of is the

Re: Ncurses: issue with "rep" capability and --enable-bsdpad (BSD_TPUTS)

Hi I have applied this now, thanks! > Is there a specific reason why OpenBSD still uses an old ncurses-based > version? Updating ncurses in OpenBSD takes quite a lot of time because it is big and quite integrated - so for example the file layout is where OpenBSD would put stuff not where

Re: new option -S for uptime(1)

You could do: expr `date +%s` - `sysctl -n kern.boottime` On Fri, 20 Mar 2020 at 12:54, Alex Naumov wrote: > > Hi, > > this patch adds a new option to uptime(1) that allows to see the length of > time the system has been up in seconds. > Patch includes documentation (man-page) update. > >

Re: sys/cdefs.h: fix __predict_false fallback implementation

Looks like the existing code is OK, you still want to test the original expression even if you are predicting it is false, no? On Tue, Feb 11, 2020 at 07:33:19PM +0100, Jeremie Courreges-Anglas wrote: > > Found while looking at __ISO_C_VISIBLE. I'm not sure which compilers > would be

Re: pretty borders for slitherins

in there as well. If you are using DRM you can set TERM to pccon0 which is a variant with ASCII line drawing and ncurses will use ASCII for line drawing. On Wed, Sep 25, 2019 at 05:02:17PM -0500, Scott Cheloha wrote: > On Wed, Sep 25, 2019 at 08:29:47PM +0100, Nicholas Marriott wrote: > > It will u

Re: pretty borders for slitherins

It will use either UTF-8 characters or the ACS characters from TERM. The way it decides which is somewhat confusing and it looks like it is choosing to use UTF-8 even when I wouldn't expect it to so I'm not sure it is actually working correctly in our ncurses version. I don't think UTF-8 line

Re: tmux: cannot select pane after prefix-b q

Hi You have the right idea general idea of the problem. display-panes blocks the queue until it is finished, so the key press isn't processed until then, which is too late. But your change defeats the purpose, the idea is that new key presses should be queued after the commands inserted by

Re: libevent: endless loop on excessively large buffers

ok nicm On Thu, May 02, 2019 at 06:59:33PM +0200, Tobias Stöckmann wrote: > It is possible to trigger an endless loop or out of boundary write > on 64 bit systems with evbuffer_readline calls for buffers which > exceed 4 GB (i.e. overflow uint). > > for (i = 0; i < len; i++) > >

Re: libevent: remove non-monotonic compat code

Looks good to me. On Tue, 30 Apr 2019, 19:32 Jeremie Courreges-Anglas, wrote: > On Tue, Apr 30 2019, Nicholas Marriott > wrote: > > Oh, event_err typically uses __func__ so I would do that here too. > > Indeed my proposal doesn't match the pattern used here. >

Re: libevent: remove non-monotonic compat code

Oh, event_err typically uses __func__ so I would do that here too. On Tue, Apr 30, 2019 at 06:48:13PM +0100, Nicholas Marriott wrote: > ok for both > > > On Tue, Apr 30, 2019 at 07:13:55PM +0200, Jeremie Courreges-Anglas wrote: > > On Tue, Apr 30 2019, Jeremie Courr

Re: libevent: remove non-monotonic compat code

ok for both On Tue, Apr 30, 2019 at 07:13:55PM +0200, Jeremie Courreges-Anglas wrote: > On Tue, Apr 30 2019, Jeremie Courreges-Anglas wrote: > > libevent contains a fallback path in case clock_gettime(CLOCK_MONOTONIC) > > fails. The fallback path tries to cope with time going backwards and > >

Re: cu(1)/remote(5): add and document support for escape character capability

I personally think -E is enough, I don't know why you would need to configure this per-host. On Sun, Mar 24, 2019 at 04:18:58AM +0200, Artturi Alm wrote: > Hi, > > for completeness, would anything like the diff below be acceptable? > > I might begin using /etc/remote soon, and I found the

Re: Option for alternative escape character with cu(1)

I will commit this in the next few days unless I hear objections. On Mon, Mar 18, 2019 at 07:39:45AM +, Nicholas Marriott wrote: > > This is OK with me, anyone else? > > > On Fri, Mar 15, 2019 at 06:56:31PM +0200, Artturi Alm wrote: > > On Fri, Mar 15, 201

Re: Option for alternative escape character with cu(1)

This is OK with me, anyone else? On Fri, Mar 15, 2019 at 06:56:31PM +0200, Artturi Alm wrote: > On Fri, Mar 15, 2019 at 02:43:04PM +0000, Nicholas Marriott wrote: > > . > > Another couple of minor changes below, with those it looks good to > > me. Any OK for this? > &

Re: Option for alternative escape character with cu(1)

On Fri, Mar 15, 2019 at 09:43:56AM -0600, Todd C. Miller wrote: > Wouldn't it be less error-prone to make escape_char u_char instead > of int? Maybe, I don't mind either way. However this in stream_read would still need a cast as ptr is signed: if (state_change && (u_char)*ptr ==

Re: Option for alternative escape character with cu(1)

. Another couple of minor changes below, with those it looks good to me. Any OK for this? On Fri, Mar 15, 2019 at 01:49:52PM +0200, Artturi Alm wrote: > On Thu, Mar 14, 2019 at 10:18:57AM +0000, Nicholas Marriott wrote: > > Thanks, comments inline. > > > > The diff looks m

Re: Option for alternative escape character with cu(1)

Thanks, comments inline. > diff --git a/usr.bin/cu/command.c b/usr.bin/cu/command.c > index c07fe73aeca..e225fb544be 100644 > --- a/usr.bin/cu/command.c > +++ b/usr.bin/cu/command.c > @@ -30,6 +30,7 @@ > #include > #include > #include > +#include > > #include "cu.h" > > @@ -223,6

Re: Option for alternative escape character with cu(1)

Why only % rather than have -e take an argument like ssh? On Wed, Mar 13, 2019 at 02:35:06PM +0200, Artturi Alm wrote: > Hi, > > i don't have issues with tilde when using locally, but i mostly ssh to > reach cu, and too many times i've forgotten to configure ssh/use -e, > with this cu(1)

Re: start cleaning up UTF-8 processing in less(1)

Looks good, ok nicm On Tue, Feb 26, 2019 at 02:39:14AM +0100, Ingo Schwarze wrote: > Hi Todd, > > Todd C. Miller wrote on Mon, Feb 25, 2019 at 01:06:02PM -0700: > > On Mon, 25 Feb 2019 19:43:36 +0100, Ingo Schwarze wrote: > >> Todd C. Miller wrote on Mon, Feb 25, 2019 at 09:45:12AM -0700: >

Re: start cleaning up UTF-8 processing in less(1)

> During the upcoming cleanup steps, let use retain full support for > the first (ESC-[) syntax and lets us completely delete support for > the second and third CSI syntaxes (single-byte CSI and UTF-8 > single-character two-byte CSI). > > If you are OK with that plan, i'll send diffs implementing

Re: file(1) better ideas to recognize rust language code?

our file(1) would probably be to make our libc regex engine faster... On Tue, Jan 15, 2019 at 07:27:15AM +, Nicholas Marriott wrote: > Hi > > I think I would avoid adding more of these at the moment, especially > ones that aren't very specific (why is "package&quo

Re: file(1) better ideas to recognize rust language code?

Hi I think I would avoid adding more of these at the moment, especially ones that aren't very specific (why is "package" Go and not Java?) and for languages that haven't been around very long, unless it is solving a specific problem. Original file has moved these into the magic files and made

Re: update magic file for qcow

This looks OK and is probably the easiest thing to do. Note that string/b does not have the same meaning for us because in original file some eejit decided to change "b" to "w" and then use "b" to mean something else, but I think it is harmless here. They have split this out into a "virtual"

Re: Add bufferevent_setwatermark(3) to manual

ok nicm On Sat, Sep 22, 2018 at 10:15:21AM +0200, Anton Lindqvist wrote: > On Fri, Sep 21, 2018 at 06:36:54PM -0700, Geoff Hill wrote: > > Hello tech, > > > > I noticed the event(3) manual pages don't mention the > > bufferevent_setwatermark(3) function and glosses over the details of > >

Re: ksh "clear-screen" editing command

Never mind, should have finished reading the later emails ;-). On Sat, Jun 23, 2018 at 09:02:24AM +0100, Nicholas Marriott wrote: > Hi > > I think you should not pass NULL to the last argument of setupterm(), > from terminfo(3): > > If errret is null, setupterm prints an

Re: ksh "clear-screen" editing command

Hi I think you should not pass NULL to the last argument of setupterm(), from terminfo(3): If errret is null, setupterm prints an error message upon finding an error and exits. On Sat, Jun 16, 2018 at 04:16:57PM -0600, Todd C. Miller wrote: > On Sat, 16 Jun 2018 14:50:40

Re: fix file(1) memory leak

I think this is better? Index: magic-test.c === RCS file: /cvs/src/usr.bin/file/magic-test.c,v retrieving revision 1.25 diff -u -p -r1.25 magic-test.c --- magic-test.c18 Apr 2017 14:16:48 - 1.25 +++ magic-test.c

Re: tmux fix when renaming session with no client attached

Fixed, thanks! On Tue, Apr 10, 2018 at 04:31:38PM -0700, Ryan Freeman wrote: > Hey, > > After upgrading OpenBSD 6.2 -> 6.3, a program I am building for $DAYJOB > started malfunctioning. > > Basically, we use tmux to manage running sessions of this program, which > does automated work on

Re: less(1): `!' command

I don't think we should bring ! back. I wanted to remove v and | (and some other stuff) shortly afterwards, but several people objected. I did suggest having a lightweight less in base for most people and adding the full upstream less to ports for the stuff we don't want to maintain (like we do

Re: document capability dc in remote(5)

IIRC dc was removed and then added back. ok nicm On Mon, Oct 30, 2017 at 11:44:28PM +0100, Remi Locherer wrote: > Hi, > > in 2015 remote(5) was trimmed down when tip was removed. It looks like > documentation for capability "dc" was also removed by accident. cu(1) still > supports this

Re: magic.5: Add missing types

Hi On Thu, Jun 29, 2017 at 09:29:57PM +0200, Klemens Nanni wrote: > While reading file(1)'s code in #openbsd-daily mulander noted that the > 'name' and 'use' types were missing from magic(5). > > I'm not entirely sure yet whether this is complete, so here's what I > did: > > magic(5) provided

Re: file: replace fgetln with getline(3)

Brilliant, looks good to me, ok nicm On Sun, Jul 02, 2017 at 06:23:35PM +0200, Ingo Schwarze wrote: > Hi Nic, > > Nicholas Marriott wrote on Sun, Jul 02, 2017 at 08:48:28AM +0100: > > > Possibly fgetln(3) CAVEATS could benefit from some of what you have > > written

Re: file: replace fgetln with getline(3)

Possibly fgetln(3) CAVEATS could benefit from some of what you have written here, although it is all in the manual already just in several places. Or at least a link to getline(3)? On Sun, Jul 02, 2017 at 12:26:19AM +0200, Ingo Schwarze wrote: > Hi, > > Nicholas Marriott wrote on Sa

Re: file: replace fgetln with getline(3)

I'm not wild about magic_load calling err(), but it is probably more pain to do nicely than it is worth it for now. This is fine, ok nicm On Sun, Jul 02, 2017 at 01:03:13AM -0400, Bryan Steele wrote: > On Sat, Jul 01, 2017 at 08:48:18PM -0400, Bryan Steele wrote: > > On Sat, Jul 01, 2017 at

Re: file: replace fgetln with getline(3)

er than "the way file is using fgetln is not safe" but that was not clear to me. On Sun, Jul 02, 2017 at 12:26:19AM +0200, Ingo Schwarze wrote: > Hi, > > Nicholas Marriott wrote on Sat, Jul 01, 2017 at 09:48:08PM +0100: > > > Safer how? > > 1. fgetln(3) retu

Re: file: replace fgetln with getline(3)

Right but we are already taking that into account, that is not a problem here. Anyway, change it if you like, it is shorter anyway. On Sat, Jul 01, 2017 at 05:03:41PM -0400, Bryan Steele wrote: > On Sat, Jul 01, 2017 at 09:48:08PM +0100, Nicholas Marriott wrote: > > Safer how? >

Re: file: replace fgetln with getline(3)

Safer how? I don't mind too much, but you will also need to initialize size to 0 (it is currently uninitialized) before calling getline(). On Sat, Jul 01, 2017 at 04:35:39PM -0400, Bryan Steele wrote: > On Sat, Jul 01, 2017 at 09:27:47PM +0100, Nicholas Marriott wrote: > >

Re: file: close fd after test_file

I'm not sure I see much point in this but do it if you like. It will potentially close STDIN_FILENO though, I think that is harmless at the moment - or perhaps prepare_input should dup() it. On Sat, Jul 01, 2017 at 03:26:27PM -0400, Bryan Steele wrote: > I think I lost this part in my larger

Re: file: replace fgetln with getline(3)

What is the point of doing this? fgetln works fine. On Sat, Jul 01, 2017 at 02:47:25PM -0400, Bryan Steele wrote: > Seems to work, does this look right? > > -Bryan. > > Index: magic-load.c > === > RCS file:

Re: small patch for file(1)

ok nicm, it should not fclose this because it didn't open it On Sat, Jul 01, 2017 at 10:19:32AM -0400, Bryan Steele wrote: > magic_load() is only called in main and fcloses magicfp immediately, > this removes a redundant fclose. > > Index: magic-load.c >

Re: fix stdin input for file(1)

Ouch. ok nicm You can add this regress test as well: Index: regress/usr.bin/file//Makefile === RCS file: /cvs/src/regress/usr.bin/file/Makefile,v retrieving revision 1.7 diff -u -p -r1.7 Makefile --- regress/usr.bin/file//Makefile

Re: Attempt to simplify file(1)

Thanks. Comments inline. On Tue, Jun 27, 2017 at 06:28:57AM -0400, Bryan Steele wrote: > On Tue, Jun 27, 2017 at 01:20:59AM -0400, Bryan Steele wrote: > > On Tue, Jun 27, 2017 at 12:26:08AM -0400, Bryan Steele wrote: > > Some unintentional changes crept in, here's another diff.. > > Sorry, last

Re: ksh(1): don't output invalid UTF-8 characters

u8len(); and I would want to test the other calls to x_e_getc(), such as in x_search_char_forw() -- but I the general idea seems reasonable. On Sat, May 20, 2017 at 12:04:35AM +0100, Nicholas Marriott wrote: > On Fri, May 19, 2017 at 09:29:06PM +0200, Ingo Schwarze wrote: > > On a sid

Re: ksh(1): don't output invalid UTF-8 characters

On Fri, May 19, 2017 at 09:29:06PM +0200, Ingo Schwarze wrote: > On a side note, i don't think gnome-terminal and konsole are relevant. > I never installed them before and did so now for the first time for > testing, but they installed so many libraries that i feel uncomfortable > and unsafe using

Re: ksh(1): don't output invalid UTF-8 characters

Hi On Fri, May 19, 2017 at 10:23:08PM +0200, Ingo Schwarze wrote: > Hi Nicholas, > > Nicholas Marriott wrote on Fri, May 19, 2017 at 07:04:53PM +0100: > > > Perhaps I haven't understood what you are saying correctly, > > What matters most is that sending an incomplete c

Re: ksh(1): don't output invalid UTF-8 characters

with shells). FWIW bash seems to do the replacement to U+FFFD itself before it sends it to the terminal, which means it is (more) predictable. I don't know if this is a sensible option for ksh. On Fri, May 19, 2017 at 07:04:53PM +0100, Nicholas Marriott wrote: > Hi > > Perhaps

Re: ksh(1): don't output invalid UTF-8 characters

Hi Perhaps I haven't understood what you are saying correctly, but I don't think it is possible to send control characters or any other invalid UTF-8 bytes inside UTF-8 characters and safely predict what the terminal will do. How about these examples: printf '\343\203\010\217a\n' printf

Re: event(3): mention bufferevent_setwatermark

I think it needs some text as well, there isn't much point in just listing the function. bufferevent_settimeout is also missing a description. I'm away for the next two weeks but I'll look when I get back. On Mon, May 15, 2017 at 07:41:57PM +0200, Anton Lindqvist wrote: > Hi, > The

Re: less(1): plug memory leak

looks good, ok nicm On Mon, May 01, 2017 at 10:35:59AM +0200, Tobias Stoeckmann wrote: > Hi, > > On Mon, May 01, 2017 at 09:15:45AM +0200, Anton Lindqvist wrote: > > While freeing tag entries, make sure to free the copied strings. > > this patch looks good to me. > > Have you reported this

Re: Better error output for readlink(1)

On Tue, Apr 04, 2017 at 05:03:26PM -0500, Scott Cheloha wrote: > > On Apr 4, 2017, at 4:46 PM, Nicholas Marriott <nicholas.marri...@gmail.com> > > wrote: > > > > readlink is explicitly documented to silently exit 1 if run without -f, > > and GNU readlink behav

Re: Better error output for readlink(1)

Hi readlink is explicitly documented to silently exit 1 if run without -f, and GNU readlink behaves the same way. I doubt that should change. On Tue, Apr 04, 2017 at 04:40:19PM -0500, Scott Cheloha wrote: > This patch replaces a custom error message in readlink.c with err(3). > The custom

Re: vmd 4/5: replace openpty(4) with a local function

Hi I think putting these in libutil is a good idea. tmux could use them. I'd like to have openptmfd() as you suggest as well - it'd be nice to hide PATH_PTMDEV as well as the PTMGET. Life would be a lot easier for portable if there was fdforkpty() as well. On Mon, Feb 27, 2017 at 07:00:03PM

Re: ksh tab completion: ^_: unexpected `^'

ol > elol_ > ~ > current $ cat /tmp/foo.c > #include > > int main(int argc, char** argv) { > if (isalnum(argv[1][0] )) printf("%s", argv[1]); else printf ("NOP\n"); > } > > On Thu, Sep 8, 2016 at 6:08 AM, Stuart Henderson <s...@spaceho

Re: ksh tab completion: ^_: unexpected `^'

Yeah we probably shouldn't bother to look for commands that aren't [A-Za-z0-9_-]: Index: edit.c === RCS file: /cvs/src/bin/ksh/edit.c,v retrieving revision 1.56 diff -u -p -r1.56 edit.c --- edit.c 7 Sep 2016 04:42:31 -

Re: tmux(1): dealing with broken wcwidth(3)

On Thu, Apr 28, 2016 at 06:49:58PM +0200, Ingo Schwarze wrote: > Hi Nic, > > Nicholas Marriott wrote on Thu, Apr 28, 2016 at 01:11:44PM +0100: > > > tmux is not some sort of terminal firewall. Of course we try to avoid > > anything obviously stupid, but we also want

Re: tmux(1): dealing with broken wcwidth(3)

Hi On Thu, Apr 28, 2016 at 01:47:27PM +0200, Ingo Schwarze wrote: > Hi Nic, > > Nicholas Marriott wrote on Wed, Apr 27, 2016 at 03:36:25AM -0600: > > > CVSROOT:/cvs > > Module name:src > > Changes by: n...@cvs.openbsd.org2016/04/27 03

Re: Any reason there's no way to persist pledge(2) state across exec?

Hi What's the use for this? What program could use it? On Sun, Apr 10, 2016 at 08:48:08AM -0700, Brennan Vincent wrote: > Subject basically says it all. I think some could find it useful to have > `pledge` promises optionally persist even after the process calls > execve. This could, for

Re: [file] file -i doesn't detect epub correctly

The only thing I see that we do not support is the indirect on the last line, I suggest just commenting it. On Fri, Mar 04, 2016 at 07:01:57PM +, Stuart Henderson wrote: > On 2016/03/04 19:50, Dmitrij D. Czarkoff wrote: > > Jiri B said: > > > file -i *.epub returns

Re: [patch] add UTF-8 support to column(1)

Hi I don't know why it is off in xterm but oxtabs is the default in ttydefaults.h and appears to on for mostly everything else, including ssh and tmux (which just uses what forkpty gives it). Hi Martijn, Martijn van Duren wrote on Sat, Feb 27, 2016 at 01:22:53PM +0100: > Here's my attempt to

Re: tmux/window-copy.c - copy mode scroll behaviour

Hi On Thu, Feb 11, 2016 at 08:05:54PM +0100, Michal Mazurek wrote: > Hello, > > I know the code is now locked, but I'd like to ask for comments on the > following diff. > > I believe that page-up and halfpage-up should have the same effect as > running scroll-up (^Y) the equivalent number of

Re: I have a program I wish to submit for the base

Firstly, I don't think we need this in base and I think there is little to no chance of it being taken, even if the code is improved. Secondly: - The code is still miles off style(9) and isn't really a consistent style within itself either. - Forking uname(1)? What? No offence, but that is

Re: Don't wrap the cursor in tmux in copy mode

Hi tmux copy mode is not meant to work like vi, it is meant to work like emacs, but emacs does do this so we can change it. However, your diff is wrong. It prevents the cursor moving back when it is at 0,0 _on screen_. But if there is more than one screen worth of history, a left at 0,0 on

Re: Simplify less(1) off_t formatting

I like the idea, but I don't like calling them ap_off_t and offttoa, I'd just keep ap_pos and postoa and remove the linenum functions. On Tue, Jan 12, 2016 at 11:50:51PM -0500, Michael McConville wrote: > I'm working on bigger simplifications for less's string formatting, but > this is a good

Re: Simplify less(1) off_t formatting

Looks good, ok nicm On Wed, Jan 13, 2016 at 05:42:56PM -0500, Michael McConville wrote: > Nicholas Marriott wrote: > > I like the idea, but I don't like calling them ap_off_t and offttoa, > > I'd just keep ap_pos and postoa and remove the linenum functions. > >

Re: ksh another home/end pair

tmux is doing the right thing and changing what it generates would break other programs. ksh should use terminfo to work out what to expect, but we have always resisted linking ksh against ncurses. Your change is the best we can do without making ksh use ncurses. On Wed, Dec 30, 2015 at

Re: ksh rename global e

yes please, ok nicm On Tue, Dec 29, 2015 at 12:15:25PM -0500, Ted Unangst wrote: > I'm slowly trimming down some of the -Wshadow warnings in bin and one big > offender is ksh. Namely, it has a local variable e that shadows a global e. > > -struct env *e; > +struct env *genv; > >

Re: utf8 input in el_gets(3)

Go for it, IIRC there are a few new strcpy that will need care to change to strlcpy but otherwise it should be easy enough. On Thu, Dec 24, 2015 at 04:30:37PM -0500, Christian Heckendorf wrote: > * Michael McConville [24.12.2015. @16:19:03 -0500]: > > > Christian

Re: less.1: Update for LESSCHARSET removal

On Mon, Nov 23, 2015 at 11:58:19AM +0100, Theo Buehler wrote: > On Mon, Nov 23, 2015 at 01:19:28AM -0500, Michael Reed wrote: > > [...] > > .Nm > [...] > > +will determine the character set to use from the environment (see > > +.Xr locale 1 ) . > > I don't think this is correct. > > The only

Re: lesskey.1: Don't mention email address

ok nicm On Mon, Nov 23, 2015 at 11:45:28AM +0100, Theo Buehler wrote: > On Mon, Nov 23, 2015 at 01:24:19AM -0500, Michael Reed wrote: > > This was already done for less.1, as OpenBSD's less(1) differs > > substantially from upstream. > > > Agreed. While there, I think we should also remove the

Re: less.1: Update for LESSCHARSET removal

sure, ok nicm On Mon, Nov 23, 2015 at 12:56:14PM +0100, Theo Buehler wrote: > On Mon, Nov 23, 2015 at 11:39:55AM +0000, Nicholas Marriott wrote: > > On Mon, Nov 23, 2015 at 11:58:19AM +0100, Theo Buehler wrote: > > > On Mon, Nov 23, 2015 at 01:19:28AM -0500,

Re: int -> size_t in ksh

Just look at the trouble changing one int->size_t is causing in lex ;-). On Sun, Nov 22, 2015 at 08:18:55AM +0000, Nicholas Marriott wrote: > On Sun, Nov 22, 2015 at 01:59:07AM +, B?hler Theo wrote: > > > It seems apparent that they never go negative. All ins

Re: less.1: secure mode is not a compile-time option

I just applied it actually, thanks On Sun, Nov 15, 2015 at 09:04:58PM +, Nicholas Marriott wrote: > ok nicm > > > On Sun, Nov 15, 2015 at 03:56:12PM -0500, Michael Reed wrote: > > From https://github.com/gdamore/less-fork/blob/master/CHANGES#L35-L37 > > >

Re: less.1: secure mode is not a compile-time option

ok nicm On Sun, Nov 15, 2015 at 03:56:12PM -0500, Michael Reed wrote: > From https://github.com/gdamore/less-fork/blob/master/CHANGES#L35-L37 > > * SECURE mode (limited features) is removed - this version of less is always >fully featured. (It was a compile-time option.) Download

Re: More less(1)

ok nicm On Wed, Nov 11, 2015 at 11:45:07PM -0500, Michael McConville wrote: > That helper function I just tweaked has a total of one usage. Maybe just > inline it? > > > Index: opttbl.c > === > RCS file:

Re: more utf8 less ebcdic

How about just lose chardef[] entirely now? Index: charset.c === RCS file: /cvs/src/usr.bin/less/charset.c,v retrieving revision 1.16 diff -u -p -r1.16 charset.c --- charset.c 7 Nov 2015 18:06:38 - 1.16 +++ charset.c

Re: [PATCH] add F13-F24 and colour support to console terminfo

Perhaps it should go in FAQ section 7, or somewhere else, I don't know where. Note pccon is only for some platforms. On Mon, Nov 09, 2015 at 08:50:12AM +, Tati Chevron wrote: > On Mon, Nov 09, 2015 at 08:23:08AM +0000, Nicholas Marriott wrote: > >On Sun, Nov 08, 2015 at 09:01:5

Re: [PATCH] add F13-F24 and colour support to console terminfo

On Sun, Nov 08, 2015 at 09:01:52PM +, Tati Chevron wrote: > Hi, > > On Sun, Nov 08, 2015 at 08:18:55PM +, Nicholas Marriott wrote: > >Hi > > > >I think it should be Shift-F1 etc, but since this is a general problem > >with the xterm entry not just

Re: less(1) cleanup

ok nicm On Sun, Nov 08, 2015 at 11:42:27PM -0500, Michael McConville wrote: > Here, I: > > 1) remove a useless comment > 2) remove a needless void* cast > 3) remove a bunch of NULL-checks for free() > 4) simplify a little associated logic > > Call me a one trick pony. > > ok? > > >

Re: unify xmalloc (was Re: [patch] cvs: retire xfree())

Hmm yes you are right, in that case, go for it. On Sun, Nov 08, 2015 at 02:00:17PM +0100, Joerg Sonnenberger wrote: > On Sun, Nov 08, 2015 at 08:36:52AM +0000, Nicholas Marriott wrote: > > On Sat, Nov 07, 2015 at 08:42:14PM -0500, Ted Unangst wrote: > > > Tobia

Re: [PATCH] add F13-F24 and colour support to console terminfo

If this is different from pccon*, you should fix those or add a variant rather than adding completely new entries. On Sun, Nov 08, 2015 at 11:55:23AM +, Tati Chevron wrote: > The terminfo entries used for X and for the console by a default install, > are broken for keyboards with function

Re: [PATCH] add F13-F24 and colour support to console terminfo

On Sun, Nov 08, 2015 at 04:12:18PM +, Tati Chevron wrote: > On Sun, Nov 08, 2015 at 02:09:03PM +0000, Nicholas Marriott wrote: > >If this is different from pccon*, you should fix those or add a variant > >rather than adding completely new entries. > > OK. The attached di

Re: [PATCH] add F13-F24 and colour support to console terminfo

08, 2015 at 04:50:21PM +0000, Nicholas Marriott wrote: > >Can you please send these upstream to Thomas Dickey or > >bug-ncur...@gnu.org? > > Done. > > >>* Add a new entry, 'pcconX', that adds F13-F24 to the standrd xterm entry > > > >Not this though - pccon

Re: unify xmalloc (was Re: [patch] cvs: retire xfree())

This is fine with me, I think it was better without errno, but using it can't do any harm. It is an extension TO set it, not to not set it, but I am pretty sure it only happens on platforms I don't care about :-). I suggest you check with djm or dtucker for ssh in case they do care, or there are

Re: unify xmalloc (was Re: [patch] cvs: retire xfree())

On Sat, Nov 07, 2015 at 08:42:14PM -0500, Ted Unangst wrote: > Tobias Stoeckmann wrote: > > Is this okay for ssh and tmux, which are out to be very portable? > > Nicholas mentioned that malloc is not required to set errno. I've also > > checked the standard and it's just an extension. Although at

Re: unify xmalloc (was Re: [patch] cvs: retire xfree())

Hi On Sat, Nov 07, 2015 at 04:39:09PM -0500, Michael McConville wrote: > Nicholas Marriott wrote: > > Looks good, ok nicm > > Reviewing now, generally looks good. > > A few things: > > I don't understand the motive for all the err() -> errx() and fatal() -> >

Re: more utf8 less ebcdic

ok nicm On Fri, Nov 06, 2015 at 10:40:19PM -0500, Ted Unangst wrote: > Ted Unangst wrote: > > Oops, that was the big bomb diff. We want to keep the nl_langinfo and some > > charset support. Just remove the environment variable and pare down some of > > the stranger charsets. > > here's better

Re: save less

Hmm I thought this was deliberate but looking at where estrdup is used it is obviously not. ok nicm On Fri, Nov 06, 2015 at 11:07:26PM -0500, Ted Unangst wrote: > less has a peculiar estrdup function. unlike ecalloc etc., it only prints an > error but doesn't quit. But the callers don't seem

Re: save less

On Sat, Nov 07, 2015 at 12:12:55AM -0500, Michael McConville wrote: > Ted Unangst wrote: > > less has a peculiar estrdup function. unlike ecalloc etc., it only > > prints an error but doesn't quit. But the callers don't seem to check > > for null. And in many places they call a function called

Re: [patch] cvs: retire xfree()

Applied, thanks. I don't know why cvs and rcs xmalloc.c has ended up so different. On Thu, Nov 05, 2015 at 11:50:51AM +0800, Michael W. Bombardieri wrote: > Hi tech@, > > Function xfree() was previously removed from rcs, so drop it from > opencvs too... > >

  1   2   3   4   >