Pi, not Pie.

Don't like this at all, since it introduces commands here where there were none before in a way that's impossible for non-root users to override.

To be honest I don't quite like that it either, but don't know any better place to put this. /root/{.profile,.login} perhaps?

Putting it there would be better.

I like this, but (although I'm leery of bikesheds) I think it would be best to mention it on -current or -hackers first.
As an aside it would be useful for resizewin(1) or a .Xr manpage to explain where/how the kernel window size is used.

Isnt this caused by a missing entry in /etc/ttys for the serial console? This should be coming from there, not from .dot files.

In D10642#225577, @rgrimes wrote:

Isnt this caused by a missing entry in /etc/ttys for the serial console? This should be coming from there, not from .dot files.

No. It's impossible to solve that way. You can't do anything but set the terminal type, which doesn't set the size.

I am having difficulty with this then as my raspberry pie is just fine and dandy over serial when logging into the console:
root@rpi3:~ # stty -a
speed 115200 baud; 24 rows; 80 columns;
uname -a
FreeBSD rpi3 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r313109M: Thu Feb 2 16:16:39 MST 2017 raspberry@hive.raspbsd.org:/usr/home/brd/rpi3/crochet/work/obj/arm64.aarch64/usr/src/sys/GENERIC arm64
root@rpi3:~ # grep ttyu0 /etc/ttys
ttyu0 "/usr/libexec/getty 3wire" vt100 onifconsole secure

There are no resizewin or stty magic anyplace I can find.

So, first of all, your terminal size is wrong. :-) Terminals are much larger these days, and people generally expect the stuff on the screen to use the available space.

Second - apart from being small, it's still wrong. Experiment: using the 80x24 size with a large (say, 208x67) tty window, type in an overlong command, like this one:

addr2line /extra/postgres/bin/postgres 0x120b69d28 1206dae48

... and try to use history (up arrow). For me, it ends up with this:

1206dae48-cheri128-en322:~ # addr2line /extra/postgres/bin/postgres 0x120b69d28

All the line editing is messed up. Using less(1) results in something even weirder. The solution seems to be to set the terminal size to the actual size, returned by the terminal emulator.

You do have a point, though: it definitely _should_ be possible to set terminal size in termcap, and it would be a nice thing to have as a backup. I have no idea why it's not working for me. Machine #1:

root@qemu-cheri128-en322:~ # stty -a
speed 9600 baud; 0 rows; 0 columns;
lflags: icanon isig iexten echo echoe -echok echoke -echonl echoctl
        -echoprt -altwerase -noflsh -tostop -flusho -pendin -nokerninfo
        -extproc
iflags: -istrip icrnl -inlcr -igncr ixon -ixoff ixany imaxbel -ignbrk
        brkint -inpck -ignpar -parmrk
oflags: opost onlcr -ocrnl tab3 -onocr -onlret
cflags: cread cs8 -parenb -parodd hupcl clocal -cstopb -crtscts -dsrflow
        -dtrflow -mdmbuf
cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = <undef>;
        eol2 = <undef>; erase = ^?; erase2 = ^H; intr = ^C; kill = ^U;
        lnext = ^V; min = 1; quit = ^\; reprint = ^R; start = ^Q;
        status = ^T; stop = ^S; susp = ^Z; time = 0; werase = ^W;
root@qemu-cheri128-en322:~ # uname -a
FreeBSD qemu-cheri128-en322 12.0-CURRENT FreeBSD 12.0-CURRENT #0 48af37d24d0(syscall_timing2): Tue May 23 14:43:09 BST 2017     en322@thyme.cl.cam.ac.uk:/usr/home/en322/cheri/build/cheribsd-obj-128/mips.mips64/usr/home/en322/cheri/cheribsd/sys/CHERI128_MALTA64  mips
root@qemu-cheri128-en322:~ # grep ttyu0 /etc/ttys
ttyu0   "/usr/libexec/getty 3wire"      vt100   onifconsole secure

Machine #2:

root@pine64:~ # stty -a
speed 115384 baud; 0 rows; 0 columns;
lflags: icanon isig iexten echo echoe -echok echoke -echonl echoctl
        -echoprt -altwerase -noflsh -tostop -flusho -pendin -nokerninfo
        -extproc
iflags: -istrip icrnl -inlcr -igncr ixon -ixoff ixany imaxbel -ignbrk
        brkint -inpck -ignpar -parmrk
oflags: opost onlcr -ocrnl tab3 -onocr -onlret
cflags: cread cs8 -parenb -parodd hupcl clocal -cstopb -crtscts -dsrflow
        -dtrflow -mdmbuf
cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = <undef>;
        eol2 = <undef>; erase = ^?; erase2 = ^H; intr = ^C; kill = ^U;
        lnext = ^V; min = 1; quit = ^\; reprint = ^R; start = ^Q;
        status = ^T; stop = ^S; susp = ^Z; time = 0; werase = ^W;
root@pine64:~ # uname -a
FreeBSD pine64 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r312006M: Thu Jan 12 21:05:06 MST 2017     raspberry@hive.raspbsd.org:/usr/home/brd/rpi3/crochet/work/obj/arm64.aarch64/usr/src/sys/GENERIC  arm64
root@pine64:~ # Jan  1 00:05:02 pine64 ntpd[595]: error resolving pool 0.freebsd.pool.ntp.org: hostname nor servname provided, or not known (8)
grep ttyu0 /etc/ttys
ttyu0   "/usr/libexec/getty 3wire"      vt100   onifconsole  secure

This is starting to sound like a terminal emulation type vs term= miss match perhaps? My term size was quiet correct, that is what a standard Putty serial terminal size comes up as.

Other possible problem is are you booting to single user or some how not using getty to login?

I have seen command line recall issues with line length and wrap that are usually an emulation bug or term= miss match.

No, this is just an ordinary getty. It works the same with literally everything I've tested it with. Terminal mismatch is possible, kind of - but that wouldn't explain why rows/cols are zero, even though the termcap entry for vt100 hardcodes them.

In D10642#226038, @rgrimes wrote:

This is starting to sound like a terminal emulation type vs term= miss match perhaps? My term size was quiet correct, that is what a standard Putty serial terminal size comes up as.

No. It's an entirely different issue. terminal type does not define terminal size.

Other possible problem is are you booting to single user or some how not using getty to login?

Single user this is an issue, but you have lots of issues with single user.

It's not not using getty to login. Since terminal type that's in /etc/ttys cannot possibly define the size of a terminal, except in the degenerate case, it's not relevant.

I have seen command line recall issues with line length and wrap that are usually an emulation bug or term= miss match.

True. You need to have the width set approximately correctly for it to work. But that's true of more systems than just FreeBSD. And it's easy to do in single user.

The fundamental problem that this addresses is that there's terminal protocols to communicate the size of the actual terminal (a size that changes with time), and there's no support in the getty / /etc/ttys mechanism to make use of it. this change is the least-intrusive change possible to pull those protocols into the system.

FreeBSD's resizewin takes no arguments or options, please remove -z from commands.

I did some addition digging and found why I see size and trasz does not, these values are preserved across login/getty so the fact that I had set them at some time in the pass meant they stayed set, arguable that is also a bug, or it is a bug that we dont set them in getty at login, since getty already does a bunch of Termios stuff.

I still do not like the idea of this in these files which have been void of this type of stuff for 30 years.

From resizewin(1):

-z  Do nothing unless the current kernel terminal size is zero.  This is
    useful when run from a user's profile (shell startup) scripts: query-
    ing the window size is required for serial lines, but not when log-
    ging in over the network, as protocols like TELNET or SSH already
    handle the terminal size by themselves.

In D10642#226822, @emaste wrote:

From resizewin(1):

-z  Do nothing unless the current kernel terminal size is zero.  This is
    useful when run from a user's profile (shell startup) scripts: query-
    ing the window size is required for serial lines, but not when log-
    ging in over the network, as protocols like TELNET or SSH already
    handle the terminal size by themselves.

Okay, so I should not trust man on freefall.... added May 8th, 2017. This makes this change slightly more palatable as resize/resizewin has been known to eat input if commands are typed over an ssh/telnet session while the login scripts are still running causing both the resize operattion and the typed command to fail, I am still leary of this, but dont object to it being committed.

Hm, that's a good point. On the other hand I'm not quite happy about moving stuff into getty(8).

One thing I'm not sure about is: shouldn't getty reset the terminal state when logging out? After all, we have this /dev/ttyuX.init node. I'd expect this to also include the terminal size.

So, while the problem pointed by Rod is real, I don't really see no easy way to fix it. Meanwhile, this patch improves stuff a lot for the common case and shouldn't make matters any worse in the other case. So, I think I'll just commit it, noting the potential problem with resizing after logging in.