Re: [AD] xmessage broken pipe

[Peter Wang <tjaden@xxxxxxxxxx>]

Chris wrote:

> Peter Wang wrote:
>
> > I thought of a slight problem with this approach.  If the message is 
> > "-print", "-center" or "-nearmouse" (and perhaps other options in 
> > future) then xmessage will think it is an option argument.  A 
> > workaround is to put an extra space at the end of the message string 
> > (say, after the uconvert) before passing it to xmessage.
>
>
> This patch fixes allegro_message itself to make this impossible to 
> happen. The Allegro docs neglect to mention whether or not you need a 
> trailing \n character, even though when it prints to the console 
> you'll get improper lining without it (printing a string without the 
> trailing \n and then quitting, for example, will cause the shell 
> prompt to append to the very end of the printed message). And because 
> of the prevalence of Windows and now X using xmessage, it might not be 
> apparent that you'd need it.


> +   if ((ugetc(buf+len-ucwidth('\n')) != '\n') && (len < ALLEGRO_MESSAGE_SIZE-ucwidth('\n')-ucwidth('\0'))) {
>  

Wait, this code is wrong.  You probably want `ugetat'.

But I don't like this whole thing.  Some drivers really don't need to 
have the trailing newline tacked on, and drivers that require the 
newline can probably do it much more simply than by mucking around with 
inserting a newline character into a unicode string buffer (e.g. they 
can just fputc after an fputs).

Peter