Discussion:
tin: article stubs one line short
(too old to reply)
Anton Shepelev
2024-09-19 18:06:58 UTC
Permalink
When I post a new message in Tin 2.6.3, after I enter the subject
and press Enter, Tin generates the "stub" of a new article and opens
it in my editor (nvi) with `+7', which complains:

-c option, 1: illegal address: only 6 lines in the file

And indeed, there are only six lines in the generated file:

--------------------------------- Cut ----------------------------------
From: Anton Shepelev <***@gmail.moc>
Subject: Russian encodings KOI8-RU and KOI8-R
Newsgroups: misc.test
Summary:
Keywords:

--------------------------------- Cut ----------------------------------

whereas I think there should be seven, because one empty line
separates the headers from the body, and one begins the body. It
is rather unlikely that the error should be in Tin, but perhaps
something is wrong in my environment preventing the second empty
line in the generated stubs?

I used the following primitive wrapper script to log the process:

--------------------------------- Cut ----------------------------------
echo $* >> ~/invoke.txt
cp $2 ~/art.txt
vi $*
--------------------------------- Cut ----------------------------------
VanguardLH
2024-09-20 04:03:26 UTC
Permalink
Post by Anton Shepelev
When I post a new message in Tin 2.6.3, after I enter the subject
and press Enter, Tin generates the "stub" of a new article and opens
-c option, 1: illegal address: only 6 lines in the file
--------------------------------- Cut ----------------------------------
Subject: Russian encodings KOI8-RU and KOI8-R
Newsgroups: misc.test
--------------------------------- Cut ----------------------------------
whereas I think there should be seven, because one empty line
separates the headers from the body, and one begins the body. It
is rather unlikely that the error should be in Tin, but perhaps
something is wrong in my environment preventing the second empty
line in the generated stubs?
--------------------------------- Cut ----------------------------------
echo $* >> ~/invoke.txt
cp $2 ~/art.txt
vi $*
--------------------------------- Cut ----------------------------------
Haven't been a *NIX user for decades, but you sure the error is
generated by tin, and not by nvi? You say tin opens the editor, and
then you see the error which makes it appear the editor issues the
error.

Tried getting tin to switch to vim as the editor?
Anton Shepelev
2024-09-20 16:23:46 UTC
Permalink
Post by VanguardLH
Post by Anton Shepelev
When I post a new message in Tin 2.6.3, after I enter the subject
and press Enter, Tin generates the "stub" of a new article and opens
-c option, 1: illegal address: only 6 lines in the file
--------------------------------- Cut ----------------------------------
Subject: Russian encodings KOI8-RU and KOI8-R
Newsgroups: misc.test
--------------------------------- Cut ----------------------------------
whereas I think there should be seven, because one empty line
separates the headers from the body, and one begins the body. It
is rather unlikely that the error should be in Tin, but perhaps
something is wrong in my environment preventing the second empty
line in the generated stubs?
--------------------------------- Cut ----------------------------------
echo $* >> ~/invoke.txt
cp $2 ~/art.txt
vi $*
--------------------------------- Cut ----------------------------------
Haven't been a *NIX user for decades,
Well, both `tin' and `vim' are available on Windows and Mac OS X.
Post by VanguardLH
but you sure the error is generated by tin, and not by nvi?
I wrote that the error message quoted above is from `nvi', but it
indicates that `tin' may be invokig it incorrectly /or/ generating
an incorrect stub for the article.
Post by VanguardLH
You say tin opens the editor, and then you see the error which makes
it appear the editor issues the error.
It does, and I have reproduced the error by calling
Post by VanguardLH
nvi +7 6l.txt
where 6l.txt is a file with six lines.
Post by VanguardLH
Tried getting tin to switch to vim as the editor?
The classic `vi' is the standard editor on my system, but I have
installed vim and tested with it, and there is no error message.
`tin', however, inokes the configured editor with +7 even though
the pre-generated file has only six lines. Both the editors move
the cursor to the last (sixsth) line of the file, but `nvi'
additionally issues an error message, whereas `vim' stays quiet.
I think `nvi' is correct here, because it is asked to position the
cursor on the senventh line in a six-line file.

It is not a bug in the editor, because regarless of the editor `tin'
2.6.3 on FreeBSD 14.1 pre-generates an article with /only one/ empty
line at the end instead of two. `tin' 2.6.2 (on a remote system I
use) pre-genenerates articles with two empty lines at the end. I
think it is an error in `tin' 2.6.3. Or can this have been changed
intentionally?
VanguardLH
2024-09-21 08:27:51 UTC
Permalink
Post by Anton Shepelev
Post by VanguardLH
Post by Anton Shepelev
When I post a new message in Tin 2.6.3, after I enter the subject
and press Enter, Tin generates the "stub" of a new article and opens
-c option, 1: illegal address: only 6 lines in the file
--------------------------------- Cut ----------------------------------
Subject: Russian encodings KOI8-RU and KOI8-R
Newsgroups: misc.test
--------------------------------- Cut ----------------------------------
whereas I think there should be seven, because one empty line
separates the headers from the body, and one begins the body. It
is rather unlikely that the error should be in Tin, but perhaps
something is wrong in my environment preventing the second empty
line in the generated stubs?
--------------------------------- Cut ----------------------------------
echo $* >> ~/invoke.txt
cp $2 ~/art.txt
vi $*
--------------------------------- Cut ----------------------------------
Haven't been a *NIX user for decades,
Well, both `tin' and `vim' are available on Windows and Mac OS X.
Post by VanguardLH
but you sure the error is generated by tin, and not by nvi?
I wrote that the error message quoted above is from `nvi', but it
indicates that `tin' may be invokig it incorrectly /or/ generating
an incorrect stub for the article.
Post by VanguardLH
You say tin opens the editor, and then you see the error which makes
it appear the editor issues the error.
It does, and I have reproduced the error by calling
Post by VanguardLH
nvi +7 6l.txt
where 6l.txt is a file with six lines.
Post by VanguardLH
Tried getting tin to switch to vim as the editor?
The classic `vi' is the standard editor on my system, but I have
installed vim and tested with it, and there is no error message.
`tin', however, inokes the configured editor with +7 even though
the pre-generated file has only six lines. Both the editors move
the cursor to the last (sixsth) line of the file, but `nvi'
additionally issues an error message, whereas `vim' stays quiet.
I think `nvi' is correct here, because it is asked to position the
cursor on the senventh line in a six-line file.
It is not a bug in the editor, because regarless of the editor `tin'
2.6.3 on FreeBSD 14.1 pre-generates an article with /only one/ empty
line at the end instead of two. `tin' 2.6.2 (on a remote system I
use) pre-genenerates articles with two empty lines at the end. I
think it is an error in `tin' 2.6.3. Or can this have been changed
intentionally?
Look at the file with a hex editor. Could the 7th line just be a
newline? I don't know if nvi has a mode to show non-printable chars.
Anton Shepelev
2024-09-21 09:24:10 UTC
Permalink
Post by VanguardLH
Post by Anton Shepelev
It is not a bug in the editor, because regarless of the editor `tin'
2.6.3 on FreeBSD 14.1 pre-generates an article with /only one/ empty
line at the end instead of two. `tin' 2.6.2 (on a remote system I
use) pre-genenerates articles with two empty lines at the end. I
think it is an error in `tin' 2.6.3. Or can this have been changed
intentionally?
Look at the file with a hex editor. Could the 7th line just be a
newline? I don't know if nvi has a mode to show non-printable chars.
No. I have examined this file with nvi and vim, output it to the console
with `cat', counted its lines with `wc', and now I have uploaded the
generated article stub here:

<https://freeshell.de/~antonius/file_host/art.txt>

I am sure it has six lines instead of seven.
Urs Janßen
2024-09-21 09:58:18 UTC
Permalink
Post by Anton Shepelev
It is not a bug in the editor, because regarless of the editor `tin'
2.6.3 on FreeBSD 14.1 pre-generates an article with /only one/ empty
line at the end instead of two. `tin' 2.6.2 (on a remote system I
use) pre-genenerates articles with two empty lines at the end. I
think it is an error in `tin' 2.6.3. Or can this have been changed
intentionally?
kinda, just tested it with an editor which doesn't complain _and_ jumps
one line _past_ the last line if called with +N > lines_in_file (e.g.
nano, joe, ...). I'll revert that change (= adding an additional
\n to the stub):

=== modified file 'src/post.c'
--- old/src/post.c 2024-09-17 13:26:24 +0000
+++ new/src/post.c 2024-09-21 09:52:00 +0000
@@ -2895,6 +2895,7 @@

start_line_offset = msg_write_headers(fp) + 1;
msg_free_headers();
+ fprintf(fp, "\n"); /* add a newline to keep vi from bitching */

start_line_offset += msg_add_x_body(fp, group->attribute->x_body);



meanwhile you might be able to use something like (depends on your $SHELL)
editor_format=%E +$((%N - 1)) %F
Anton Shepelev
2024-09-21 10:43:04 UTC
Permalink
Post by Urs Janßen
Post by Anton Shepelev
It is not a bug in the editor, because regarless of the editor `tin'
2.6.3 on FreeBSD 14.1 pre-generates an article with /only one/ empty
line at the end instead of two. `tin' 2.6.2 (on a remote system I
use) pre-genenerates articles with two empty lines at the end. I
think it is an error in `tin' 2.6.3. Or can this have been changed
intentionally?
kinda, just tested it with an editor which doesn't complain _and_ jumps
one line _past_ the last line if called with +N > lines_in_file (e.g.
nano, joe, ...). I'll revert that change (= adding an additional
Thank you, Urs. Of cousre, Tin should generate a correct stub rather
than rely on an editor to "fix" it. This means the stub should have
conclude with two empty lines, in order that the user may simply
start typing at the end of the stub to produce a correct article.
Post by Urs Janßen
=== modified file 'src/post.c'
--- old/src/post.c 2024-09-17 13:26:24 +0000
+++ new/src/post.c 2024-09-21 09:52:00 +0000
@@ -2895,6 +2895,7 @@
start_line_offset = msg_write_headers(fp) + 1;
msg_free_headers();
+ fprintf(fp, "\n"); /* add a newline to keep vi from bitching */
Yeah, but the comment :-) vi is in the right protesting against
positioning the cursor on a non-existant line in the file.
Post by Urs Janßen
meanwhile you might be able to use something like (depends on your $SHELL)
editor_format=%E +$((%N - 1)) %F
Thank you, I can adapt this to my shell. I am not sure, however,
it will work with follow-ups, because they are OK as is. At least,
I can simply ignore the error and be glad that you fixed the bug
upsteam.
Urs Janßen
2024-09-21 10:47:19 UTC
Permalink
Post by Anton Shepelev
Yeah, but the comment
was there for 2 decades and now is back (and was added not by me and fits
to the comments on the other locations).
Post by Anton Shepelev
positioning the cursor on a non-existant line in the file.
which could be handeled noiseless ...

EOT
Joerg Mertens
2024-09-21 14:09:09 UTC
Permalink
Post by Anton Shepelev
Post by Urs Janßen
meanwhile you might be able to use something like (depends on your $SHELL)
editor_format=%E +$((%N - 1)) %F
Thank you, I can adapt this to my shell. I am not sure, however,
it will work with follow-ups, because they are OK as is. At least,
I can simply ignore the error and be glad that you fixed the bug
upsteam.
You can also tell nvi to jump to the last line with

# vi +'$' file

or

# vi -c'$' file

So you can just ignore the %N.

Joerg
Joerg Mertens
2024-09-21 14:17:53 UTC
Permalink
Post by Joerg Mertens
Post by Anton Shepelev
Post by Urs Janßen
meanwhile you might be able to use something like (depends on your $SHELL)
editor_format=%E +$((%N - 1)) %F
Thank you, I can adapt this to my shell. I am not sure, however,
it will work with follow-ups, because they are OK as is. At least,
I can simply ignore the error and be glad that you fixed the bug
upsteam.
You can also tell nvi to jump to the last line with
# vi +'$' file
or
# vi -c'$' file
So you can just ignore the %N.
... wich also won't work with followups, by the way. Sorry for the noise.

Joerg
Anton Shepelev
2024-09-21 14:23:09 UTC
Permalink
Post by Joerg Mertens
Post by Joerg Mertens
Post by Anton Shepelev
Post by Urs Janßen
meanwhile you might be able to use something like (depends on your $SHELL)
editor_format=%E +$((%N - 1)) %F
Thank you, I can adapt this to my shell. I am not sure, however,
it will work with follow-ups, because they are OK as is. At least,
I can simply ignore the error and be glad that you fixed the bug
upsteam.
You can also tell nvi to jump to the last line with
# vi +'$' file
or
# vi -c'$' file
So you can just ignore the %N.
... wich also won't work with followups, by the way.
Sorry for the noise.
I love this noise and am glad to meet a vi user online. Have you
noticed that its -c option is documented as if accepting the command
after a space: -c <cmd> ? This form does not work for me, and I
have to use it without the inervening space: -c<cmd> . Is it an
error in the man page, or I am missing someting?
Joerg Mertens
2024-09-21 18:03:38 UTC
Permalink
Post by Anton Shepelev
Post by Joerg Mertens
Post by Joerg Mertens
You can also tell nvi to jump to the last line with
# vi +'$' file
or
# vi -c'$' file
So you can just ignore the %N.
... wich also won't work with followups, by the way.
Sorry for the noise.
I love this noise and am glad to meet a vi user online. Have you
noticed that its -c option is documented as if accepting the command
after a space: -c <cmd> ? This form does not work for me, and I
have to use it without the inervening space: -c<cmd> . Is it an
error in the man page, or I am missing someting?
It works here with both the system nvi (OpenBSD) and the nvi from ports.
The former is version 1.79 and the ports nvi is 2.2.1.

For example:

# vi -c '/^$/' file

starts on the first blank line of the file,

# vi -c '/^$/++' file

starts two lines after the first blank line of the file and so on.

Seems like your FreeBSD has its own version.
Anton Shepelev
2024-09-21 19:39:16 UTC
Permalink
Post by Joerg Mertens
Post by Anton Shepelev
I love this noise and am glad to meet a vi user online. Have you
noticed that its -c option is documented as if accepting the command
after a space: -c <cmd> ? This form does not work for me, and I
have to use it without the inervening space: -c<cmd> . Is it an
error in the man page, or I am missing someting?
It works here with both the system nvi (OpenBSD) and the nvi from ports.
The former is version 1.79 and the ports nvi is 2.2.1.
# vi -c '/^$/' file
starts on the first blank line of the file,
Yes, you are right.
I had blundered, by trying -c '+3'.
Urs Janßen
2024-09-21 15:04:44 UTC
Permalink
Post by Joerg Mertens
Post by Joerg Mertens
# vi -c'$' file
So you can just ignore the %N.
... wich also won't work with followups, by the way.
Sorry for the noise.
vim -c":silent! +%N" %F

should work for vim/nvi
Urs Janßen
2024-09-21 15:05:34 UTC
Permalink
Post by Joerg Mertens
Post by Joerg Mertens
# vi -c'$' file
So you can just ignore the %N.
... wich also won't work with followups, by the way.
Sorry for the noise.
vim -c":silent! +%N" %F

should work for vim/nvi
Anton Shepelev
2024-09-21 19:53:20 UTC
Permalink
Post by Urs Janßen
Post by Joerg Mertens
Post by Joerg Mertens
# vi -c'$' file
So you can just ignore the %N.
... wich also won't work with followups, by the way.
Sorry for the noise.
vim -c":silent! +%N" %F
should work for vim/nvi
vim has it, but nvi does not, so perhaps the original vi did neither.
In nvi, which claims include a bug-for-bug reimplementation of vi,
`silent' is not documented and does not work.
Anton Shepelev
2024-09-21 11:10:55 UTC
Permalink
Post by Urs Janßen
+ fprintf(fp, "\n"); /* add a newline to keep vi from bitching */
By the way, I can't help but commend your coice of comment delimiters,
for these are the true C comments.
// unlike the rest-of-line comments of C++.

Gald to see thigs are still being written in C.
Anton Shepelev
2024-09-21 20:06:38 UTC
Permalink
Post by Urs Janßen
Post by Anton Shepelev
It is not a bug in the editor, because regarless of the editor `tin'
2.6.3 on FreeBSD 14.1 pre-generates an article with /only one/ empty
line at the end instead of two. `tin' 2.6.2 (on a remote system I
use) pre-genenerates articles with two empty lines at the end. I
think it is an error in `tin' 2.6.3. Or can this have been changed
intentionally?
kinda, just tested it with an editor which doesn't complain _and_ jumps
one line _past_ the last line if called with +N > lines_in_file (e.g.
nano, joe, ...). I'll revert that change (= adding an additional
Somewhat related to this problem, is another, when Tin passes 0 for
%N, whereas the lines are numbered from unity (1). Consequently,
nvi complains that an address of zero is wrong.
Urs Janßen
2024-09-22 01:37:59 UTC
Permalink
Post by Anton Shepelev
Somewhat related to this problem, is another, when Tin passes 0 for
%N, whereas the lines are numbered from unity (1). Consequently,
nvi complains that an address of zero is wrong.
%N should always >= 1, can you state how to reproduce this?
Anton Shepelev
2024-09-22 11:54:35 UTC
Permalink
Post by Urs Janßen
Post by Anton Shepelev
Somewhat related to this problem, is another, when Tin passes 0 for
%N, whereas the lines are numbered from unity (1). Consequently,
nvi complains that an address of zero is wrong.
%N should always >= 1, can you state how to reproduce this?
Yes. When when I invoke a postponed article by ^O, tin invokes:

vi +0 /home/ant/.tin_dir/.article.2109
Urs Janßen
2024-09-22 15:27:09 UTC
Permalink
Post by Anton Shepelev
vi +0 /home/ant/.tin_dir/.article.2109
oic, I forgot that we didn't bother to check where the body starts
for postponed articles. quick fix: adjust the last arg. of post_loop()
in post.c:post_postponed_article() from 0 to 1.

I'll calculate to correct offset to the fist line in the body for
the next release.
Anton Shepelev
2024-09-22 15:51:50 UTC
Permalink
Post by Urs Janßen
Post by Anton Shepelev
vi +0 /home/ant/.tin_dir/.article.2109
oic, I forgot that we didn't bother to check where the body starts
for postponed articles. quick fix: adjust the last arg. of post_loop()
in post.c:post_postponed_article() from 0 to 1.
I'll calculate to correct offset to the fist line in the body for
the next release.
Thank you, Urs.
Instead of rebuilding Tin,
I can write a shamefully dumb wrapper around vi
that replaces +0 with +6...
Anton Shepelev
2024-09-22 18:09:57 UTC
Permalink
Post by Urs Janßen
Post by Anton Shepelev
vi +0 /home/ant/.tin_dir/.article.2109
oic, I forgot that we didn't bother to check where the body starts
for postponed articles. quick fix: adjust the last arg. of post_loop()
in post.c:post_postponed_article() from 0 to 1.
I'll calculate to correct offset to the fist line in the body for
the next release.
Or you can simply find the first empty line, and place the cursor
after that, including by means of `vi +<cmd>' .

John McCue
2024-09-20 17:51:45 UTC
Permalink
Post by Anton Shepelev
When I post a new message in Tin 2.6.3, after I enter the subject
and press Enter, Tin generates the "stub" of a new article and opens
-c option, 1: illegal address: only 6 lines in the file
Very odd. What is VISUAL set to ?

Do you have an empty ~/.signature File ? Maybe that is why.
Try creating a ~/.signature with 1 'real' line and see what
happens. Or maybe delete file ~/.signature

Also check ~/.tin/tinrc and see if there is simething odd in
that.

<snip>

HTH
--
csh(1) - "An elegant shell, for a more... civilized age."
- Paraphrasing Star Wars
Anton Shepelev
2024-09-20 18:23:18 UTC
Permalink
Post by John McCue
Post by Anton Shepelev
When I post a new message in Tin 2.6.3, after I enter the subject
and press Enter, Tin generates the "stub" of a new article and opens
-c option, 1: illegal address: only 6 lines in the file
Very odd. What is VISUAL set to ?
vi, invoking nvi on this system. I have tried vim as well,
but the pre-generated stub article was not affected.
Post by John McCue
Do you have an empty ~/.signature File ? Maybe that is why.
Try creating a ~/.signature with 1 'real' line and see what
happens. Or maybe delete file ~/.signature
The error is observed with either:

a. sigfile=
b. sigfile=--none (tin's convention for no sig)

in my tinrc. With a path to an non-empty text file,
the behavior is correct. With an empty signature file,
there is no error, but the article stub ends with a
signature delimiter -- Tin is obeying its rc file to
the letter.

The problem is in whatever component is responsible for
generating the stub artile, for it /fails/ to end it with
two empty lines with `sigfile=--none' .
Post by John McCue
Also check ~/.tin/tinrc and see if there is simething odd in
that.
Duh...
Loading...