[PATCH] wall: wrap message header when it exceeds 79 characters

[PATCH] wall: wrap message header when it exceeds 79 characters

[Sami Kerola]

Header truncation started to happen more often after commit
d81c30553f4fb49173d38f69edff4b0b67a18b65 that made the header to be
longer.

Signed-off-by: Sami Kerola <kerolasa@iki.fi>
---
 term-utils/wall.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/term-utils/wall.c b/term-utils/wall.c
index 598e9f2..acada29 100644
--- a/term-utils/wall.c
+++ b/term-utils/wall.c
@@ -202,6 +202,8 @@ static char *makemsg(char *fname, char **mvec, int mvecsz,
 		char *whom, *where, *date;
 		struct passwd *pw;
 		time_t now;
+		ssize_t len;
+		int i;
 
 		if (!(whom = getlogin()) || !*whom)
 			whom = (pw = getpwuid(getuid())) ? pw->pw_name : "???";
@@ -232,7 +234,10 @@ static char *makemsg(char *fname, char **mvec, int mvecsz,
 		fprintf(fp, "\r%*s\r\n", TERM_WIDTH, " ");
 		sprintf(lbuf, _("Broadcast message from %s@%s (%s) (%s):"),
 			      whom, hostname, where, date);
-		fprintf(fp, "%-*.*s\007\007\r\n", TERM_WIDTH, TERM_WIDTH, lbuf);
+		len = strlen(lbuf);
+		for (i = 0; 0 < len; i++)
+			len -= fprintf(fp, "%-*.*s\007\007\r\n", TERM_WIDTH, TERM_WIDTH,
+				       lbuf + (i * TERM_WIDTH)) + 4;
 		free(hostname);
 		free(date);
 	}
-- 
2.0.3

Re: [PATCH] wall: wrap message header when it exceeds 79 characters

[Karel Zak]

On Sun, Jul 27, 2014 at 08:01:06PM +0100, Sami Kerola wrote:
> Header truncation started to happen more often after commit
> d81c30553f4fb49173d38f69edff4b0b67a18b65 that made the header to be
> longer.

 Well, I did the change to be compatible with wall from sysvinit. The
 original (BSD) wall header format was

  Broadcast Message from %s@%s
           (%s) at %d:%02d ...

 it means two lines.

> +		len = strlen(lbuf);
> +		for (i = 0; 0 < len; i++)
> +			len -= fprintf(fp, "%-*.*s\007\007\r\n", TERM_WIDTH, TERM_WIDTH,
> +				       lbuf + (i * TERM_WIDTH)) + 4;

 Now you want to reintroduce the old behavior (more lines for the header),
 but with a completely random split... I don't think it's a good idea.

 If we don't want the sysvinit header then it would be better to
 compose nice proper header than depend on for (i = 0; 0 < len;
 i++)...

    Karel


-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: [PATCH] wall: wrap message header when it exceeds 79 characters

[Sami Kerola]

On 29 July 2014 08:44, Karel Zak <kzak@redhat.com> wrote:
> On Sun, Jul 27, 2014 at 08:01:06PM +0100, Sami Kerola wrote:
>> Header truncation started to happen more often after commit
>> d81c30553f4fb49173d38f69edff4b0b67a18b65 that made the header to be
>> longer.
>
>  Well, I did the change to be compatible with wall from sysvinit. The
>  original (BSD) wall header format was
>
>   Broadcast Message from %s@%s
>            (%s) at %d:%02d ...
>
>  it means two lines.
>
>> +             len = strlen(lbuf);
>> +             for (i = 0; 0 < len; i++)
>> +                     len -= fprintf(fp, "%-*.*s\007\007\r\n", TERM_WIDTH, TERM_WIDTH,
>> +                                    lbuf + (i * TERM_WIDTH)) + 4;
>
>  Now you want to reintroduce the old behavior (more lines for the header),
>  but with a completely random split... I don't think it's a good idea.
>
>  If we don't want the sysvinit header then it would be better to
>  compose nice proper header than depend on for (i = 0; 0 < len;
>  i++)...

Sounds like the options are

1. change to header format
2. add to documentation header might not have always all information
if it is too long

After reading Karel's advice I am thinking the second option is more acceptable.
I will wait couple days before sending a patch just in case someone has opinion
in against or in favor of the option 2.

-- 
Sami Kerola
http://www.iki.fi/kerolasa/

Re: [PATCH] wall: wrap message header when it exceeds 79 characters

[Dale R. Worley]

Hmmm...  It seems to me that there's an interface issue.  If you're
*sure* that the message will always be consumed by a human, wrapping
is the nice thing to do.  But if the message will sometimes have to be
extracted by an automaton, write the message without line breaks,
because it's a lot easier for a human to visually reassemble a long
line (wrapped by whatever the display container is) than it is for a
program to discern that two lines are part of the same message.

Dale