OT from the original post but this is actually pretty easy with a shell scrit and ncftp. I log onto my BBS to get the QWK packet, but almost always upload the REP using a script. Once it is set up, it is easy
and a lot faster.
Yeah, after reading yours and a couple other responses, I can see this
being a good thing, didn't know that could be done.
Mind sharing a look at the script? (assuming Linux). Thanks.
Yeah, after reading yours and a couple other responses, I can see this
being a good thing, didn't know that could be done.
Mind sharing a look at the script? (assuming Linux). Thanks.
Sure. It changes to the "DOS drive" that Multimail/SLMR would have
I am now seeing the value of this method...
Would you mind sharing the scripts? (don't need the MultiMail one).
NOTE that the lines that start with a '+' are line wrapped!
Dumas Walker wrote to GAMGEE <=-
OT from the original post but this is actually pretty easy with a shell scrit and ncftp. I log onto my BBS to get the QWK packet, but almost always upload the REP using a script. Once it is set up, it is easy and a lot faster.
Yeah, after reading yours and a couple other responses, I can see this
being a good thing, didn't know that could be done.
Mind sharing a look at the script? (assuming Linux). Thanks.
Sure. It changes to the "DOS drive" that Multimail/SLMR would have accessed the QWK packets in, tests for whether or not the packet name
got written out in all CAPS or all lower case, and acts accordingly.
NOTE that the lines that start with a '+' are line wrapped!
#!/bin/bash
cd /opt/DRIVE_E/KERM231
test -e /opt/DRIVE_E/KERM231/CAPCITY2.REP
if (( $? == 0 )) ;
then
ncftpput -u "Dumas Walker" -p 448fmr -DD -E -d stdout
+ capitolcityonline.net / /opt/DRIVE_E/KERM231/CAPCITY2.REP
fi
test -e /opt/DRIVE_E/KERM231/capcity2.rep
if (( $? == 0 )) ;
then
ncftpput -u "Dumas Walker" -p 448fmr -DD -E -d stdout
+ capitolcityonline.net / /opt/DRIVE_E/KERM231/capcity2.rep
fi
cd ~
#
##END
Accession wrote to Gamgee <=-
I am now seeing the value of this method...
Would you mind sharing the scripts? (don't need the MultiMail one).
Sure thing. As long as your on a personal computer, and don't share it with others:
getpkt:
#!/bin/bash
cd /home/user/mmail/down
wget --ftp-user=<username> --ftp-password=<password> ftp://<yourBBSaddress>/<BBSID>.qwk
cd /home/user/mmail
putpkt:
#!/bin/bash
cd /home/user/mmail/up
ftp -nv <<EOF
open <yourBBSaddress>
user <username> <password>
bin
put <BBSID>.rep
quit
EOF
rm <BBSID>.rep
cd /home/user/mmail
Technically you could use the FTP method for both transfers (using
'get' instead of put), but I did the script with 'wget' first, and soon after realized 'wput' was a thing at some point, but isn't maintained anymore and isn't in my distro's repositories.
Change your paths to match your system, fill in your authentication information, make them executable, and you're off to the races!
FYI, I don't remove the QWK packet, because I can do that in Multimail once I'm done reading/replying. But I do remove the .REP packet after I send it, otherwise the next time I run that script it'll send it again, probably causing dupes. Unless there's some fancy numbering of .REP packets Multimail does that I don't yet know about (I didn't read the docs, I just figured MM out by mashing buttons, lol).
Regards,
Nick
Sure. It changes to the "DOS drive" that Multimail/SLMR would have
Um... you may want to change your password now?
NOTE that the lines that start with a '+' are line wrapped!
..and completely disregard the password, too! :D
Regards, Nick
Yes, understood. The "put" direction makes good sense to me. I have a question about the "get" side though - What causes the BBS to know to
pack up all the new messages into a QWK packet though? Does just the
act of requesting <BBSID>.qwk cause that to happen?
I was thinking I'd
have to somehow "tell" the BBS to create the new QWK packet, and *then*
grab it with wget/ftp.
Yes, understood. The "put" direction makes good sense to me. I have a question about the "get" side though - What causes the BBS to know to
pack up all the new messages into a QWK packet though? Does just the
act of requesting <BBSID>.qwk cause that to happen? I was thinking I'd
have to somehow "tell" the BBS to create the new QWK packet, and *then*
grab it with wget/ftp.
Appreciate you taking the time to send/explain this! Thanks.
No, it happens on demand. The *.qwk file that appears in the FTP
directory listing is just a virtual file. A "get" (RETR) of the file actually signals the sbbs event thread to create the packet, on demand,
so there is a bit of delay before the file transfer actually starts
(which is fine).
Accession wrote to Gamgee <=-
Yes, understood. The "put" direction makes good sense to me. I have a question about the "get" side though - What causes the BBS to know to
pack up all the new messages into a QWK packet though? Does just the
act of requesting <BBSID>.qwk cause that to happen? I was thinking I'd
have to somehow "tell" the BBS to create the new QWK packet, and *then*
grab it with wget/ftp.
I think either when you connect or when there is a new message(s), Synchronet creates the QWK packet and puts it in that location automatically. I'm not sure on exactly how it works, but it's there
every time I grab it, and it's an updated packet each time.
Rob would have to explain that better, but I'll just call it 'magic'.
:)
Digital Man wrote to Gamgee <=-
Re: Re: NNTP(S) via Thunderbi
By: Gamgee to Accession on Fri Nov 07 2025 09:15 pm
Yes, understood. The "put" direction makes good sense to me. I have a question about the "get" side though - What causes the BBS to know to
pack up all the new messages into a QWK packet though? Does just the
act of requesting <BBSID>.qwk cause that to happen?
Yes, correct.
I was thinking I'd
have to somehow "tell" the BBS to create the new QWK packet, and *then*
grab it with wget/ftp.
No, it happens on demand. The *.qwk file that appears in the FTP
directory listing is just a virtual file. A "get" (RETR) of the file actually signals the sbbs event thread to create the packet, on demand,
so there is a bit of delay before the file transfer actually starts
(which is fine).
On Fri, 07 Nov 2025 11:31:18 -0500, you wrote:
NOTE that the lines that start with a '+' are line wrapped!
..and completely disregard the password, too! :D
NOTE that the lines that start with a '+' are line wrapped!
..and completely disregard the password, too! :D
Regards, Nick
too bad he didnt post the system pass, i could have fixed some stuff.
See, Gamgee? Magic! :)
Regards, Nick
Regards, Nick
too bad he didnt post the system pass, i could have fixed some stuff.
Just because *you* don't like it doesn't make it broken.
Not sure how that's any easier than logging in with Syncterm
and just getting the QWK packet the normal way, and then
repeating for the .REP. Seems harder, actually.
It's pretty handy here, I don't know if a lot of sysops open FTP on
their firewalls though.
Sure. It changes to the "DOS drive" that Multimail/SLMR would
have accessed the QWK packets in, tests for whether or not the
packet name got written out in all CAPS or all lower case, and
acts accordingly.
NOTE that the lines that start with a '+' are line wrapped!
#!/bin/bash
cd /opt/DRIVE_E/KERM231
test -e /opt/DRIVE_E/KERM231/CAPCITY2.REP
if (( $? == 0 )) ;
then
ncftpput -u "Dumas Walker" -p 448fmr -DD -E -d stdout
+ capitolcityonline.net / /opt/DRIVE_E/KERM231/CAPCITY2.REP
fi
test -e /opt/DRIVE_E/KERM231/capcity2.rep
if (( $? == 0 )) ;
then
ncftpput -u "Dumas Walker" -p 448fmr -DD -E -d stdout
+ capitolcityonline.net / /opt/DRIVE_E/KERM231/capcity2.rep
fi
cd ~
#
##END
Regards, Nick
too bad he didnt post the system pass, i could have fixed some stuff.
Just because *you* don't like it doesn't make it broken.
yeah ooookay. i just dont like broken things.
As I said, just because you don't like it doesn't make it broken.
As you are the only one whose ever complained, I would suggest the
problem is elsewhere -- and very much not mine.
OTOH, I originally had Synchronet set up so that all the message
areas were grouped by network -- which is how you like it -- and
users (plural) did complain because they couldn't find the "echoes
When a user isn't either pissed at the network admins, or banned by
then, which networks you want/need to avoid isn't an issue.
OTOH, I originally had Synchronet set up so that all the message areas were grouped by network -- which is how you like it -- and users
(plural) did complain because they couldn't find the "echoes about (subject)" that they were used to participating in on the predecessor
BBS.
predecessor BBS.
can message areas not be grouped in more than one way? i don't
recall. perhaps in a(n unpleasant) way where two areas listed in two
groups use the same files?
can message areas not be grouped in more than one way? i don't recall. perhaps in a(n unpleasant) way where two areas listed in two groups use the same files?
can message areas not be grouped in more than one way? i don't recall. perha > in a(n unpleasant) way where two areas listed in two groups use the same filThat would certainly be unpleasant. ;)
can message areas not be grouped in more than one way? i don't recall. perhaps in a(n unpleasant) way where two areas listed in two groups use t > > same files?
They actually can be, by having a sub-board with the same internal code in m > than one message group. This means you can't use the "internal code prefix"
feature, but it is doable. Some oddity with message scan config / pointers might occur also, I don't recall.
| Sysop: | Heisenberg |
|---|---|
| Location: | Kalgoorie, Western Australia |
| Users: | 4 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 92:52:44 |
| Calls: | 3 |
| Calls today: | 1 |
| Messages: | 10,704 |