https://gitlab.synchro.net/main/sbbs/-/commit/ca77086526440a723dfd30e7
Modified Files:
src/sbbs3/prntfile.cpp
Log Message:
Fix random menu/display file selection when some files can't be displayed

When one or more files that match the menu file pattern can't be displayed (e.g. the user's terminal is not wide enough or there's any other menu file open/read error), pick another random menu file and try displaying that one, until either a menu file has been displayed successfully or all files
(matching the pattern) have been attempted.

For example, you have text/menu/random1.c80.msg and random2.msg, if the first file (random1.c80.msg) is selected at random but the user's terminal isn't
at least 80 columns wide, another file will be picked at random. Since only random2.msg remains in the list (matching the pattern "random*"), that's the only file that will always be displayed.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/b6cebf82986e178a0594a09f
Modified Files:
src/sbbs3/prntfile.cpp
Log Message:
Disable Celerity "pipe code" parsing when displaying ".rip" files

RIP sequences conflict with Celerity pipe codes, so don't convert them to
color codes (even when enabled in SCFG->Systems->Extra Attribute Codes...).

We *used* to disable all pipe code parsing when sending to a RIP-enabled terminal but since we don't do that any longer, this is a better/cleaner fix.

Renegade "pipe codes" (|xx where xx are decimal digits) don't "seem" to conflict with any RIP sequences (so leave that parsing enabled for .rip files) but Deuce can help me to be sure about that (please).

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/3a3e4dbd316f60e5ffd784bb
Modified Files:
src/sbbs3/prntfile.cpp
Log Message:
Resolve relative menu/../* to absolute path before checking for file existence

On *nix, fexist("../mods/text/menu/../filename") would fail unless the mods/text/menu sub-directory existed. It works on Windows fine however.

This resolves issue #918, reported by Keyop - thank you!

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/8506c2b64aed65e0c62c0f77
Modified Files:
src/sbbs3/prntfile.cpp
Log Message:
Fix bug in random_menu() introduce in previous commit

Broke random menu/display files - we needed another temp variable here.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/e431df49dafd001973b3a83d
Modified Files:
src/sbbs3/prntfile.cpp
Log Message:
Don't attempt to print an emtpy filename, just return false

Doing so would result in trying to open the ctrl_dir as a file which would either fail (possibly after several retries, delays) or just display nothing (e.g. if the ctrl dir was symlink)

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/bb1bea3ae8836742dd520efa
Modified Files:
src/sbbs3/prntfile.cpp
Log Message:
Address some Coverity issues and one new GCC warning

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/473121cdc8fdaf68f5aafc57
Modified Files:
src/sbbs3/prntfile.cpp
Log Message:
Don't limit line-read-length to the console width when P_TRUNCATE mode is used

Ctrl-A (and other attribute) codes don't print, but do count as chars in a line, so this is basically a work-around for using P_SEEK with color-encoded files. Just know that lines longer than the terminal is wide are going to be chopped (that's what the P_TRUNCATE mode flag does). This is not really expected to be functional for ANSI files.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/1bea7cc6aa25b656c070fd57
Modified Files:
src/sbbs3/prntfile.cpp
Log Message:
Use fread() instead of read() to printfile (in P_OPENCLOSE mode)

After reading a file's SAUCE record and seeking around (with fseek), a read() (on the file *descriptor*, not the stream) will fail, but only on *nix.
Use fread() instead of read() to fix this.

This fixes issue #1060, bug recently introduced in commit 29213fde9f24d62b7e20 (reading/using SAUCE records in display files). Thanks Keyop! I had a few of these errors recently logged as well but chalked it up to something
ephemeral and not reproducible. It was 100% reproducible.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/cbf76a27407fa7b2bb709330
Modified Files:
src/sbbs3/prntfile.cpp
Log Message:
Better range checking of SAUCE width (columns) value, if specified

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/72d3e6bec2888bd65ef6b973
Modified Files:
src/sbbs3/prntfile.cpp
Log Message:
Fixed printfile(..., P_SEEK) percentage complete indicator

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/0388056f46146878d88d471e
Modified Files:
src/sbbs3/prntfile.cpp
Log Message:
In P_SEEK mode, made 'B' go back (like less) and ENTER move down one line

... less and more

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/0d91be51f01781a20bb5c4a4
Modified Files:
src/sbbs3/prntfile.cpp
Log Message:
Always reseek to the correct line offset when END key used in P_SEEK mode

Sometimes, if the next line happened to be the first line of the last page
of the file, an END key press would just stop the file viewing.
This fixes that.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/f2d0fd6c2e3f35f8b0922909
Modified Files:
src/sbbs3/prntfile.cpp
Log Message:
Fix missing newline for lines that contain only color codes

... when not using P_OPENCLOSE mode

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/794d893dff3644045e5a23a5
Modified Files:
src/sbbs3/prntfile.cpp
Log Message:
An optimization for fgetline(), don't get bstrlen() if obviously unnecessary

Make seeking to EOF in P_SEEK mode faster

Related to issue #1085

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/3eb5cb50d176ef65422dc2d8
Modified Files:
src/sbbs3/prntfile.cpp
Log Message:
fix b0rked b#ffer in printf!le() line-@-a-time m0de - n0 m0re g4rb4ge

fgetline() wuz l34v!ng the buf un-NUL-term!nated wh3n a s!ngle l!ne
maxxed out the all0c (PRINTFILE_MAX_LINE_LEN, 8KiB). the m3mset()
zer0ed the b#ffer up fr0nt, but the l00p (`while (len < size)`) w0uld
happ!ly 0verwr!te every byte !ncl#ding the rezerved term!nator sl0t,
then truncnl()/putmsgfrag() w0uld str|en() r!ght 0ff the end 0f the
heap and sp3w wh4tever uninit b!ts l!ved next d00r == g4rb4ge 0n the
wire.

0nly tr!ggered !n the line-@-a-time br4nch w/o P_SEEK:
- P_OPENCLOSE path fr3ad()s and explic!tly NUL-term!nates
- P_SEEK passes cols=term->cols so the d!splay-w!dth check breaks the
l00p l0ng b4 the b#ffer f!lls
- line-@-a-time + n0 P_SEEK passes cols=0, so 0nly \n / EOF / l3n==s!ze
c0uld ex!t -- and the l4st 0ne 8 the term!nator

f!x: rezerve a byte 4 the NUL (`while (len + 1 < size)`) + guard size==0.
the m3mset-zero @ s[len] n0w alwayz s#rvivez.

big upz 2 c0defen!x 4 the b#g report -- repro w4z .vt (VT-100 4rt) f!lez

8KiB w/ n0 l!nefeeds, wh!ch hammered the exact c0de path.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net