<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>
<font size="2">> Sure, we </font>disagree<font size="2"> there. Both me and the xpdf author agree it is a shell issue, </font><br><div>> shells should not accept random commands from random outputs, if they do, well <br>> it's their fault.<br>> poppler tries to be as resilient as possible to broken pdf and not crash, <br>> shells should do the same and be resilient to broken inputs.<br></div><div><br></div><div>How can a shell protect against it?</div><div><br></div><div>If bash piped the stdout and stderr of every command through a filter, programs like emacs could never work.</div><div><br></div><div>If a program wrote a huge amount of garbage and bash or xterm broke and started sending pushing some of the garbage into stdin, then I would agree that it would clearly be a shell bug.</div><div>My old vt100 clone http://williambader.com/museum/cit101/cit101.html did that on occasion, and the only thing that saved me was the verbosity required in VAX/VMS to do anything useful.</div><div><br></div><div>The case that I meant is that a program would send codes that made xterm redefine a key.  When the user later presses the key at a shell prompt, the shell has no way to know that the text came from a redefined key instead of from a human typing.</div><div><br></div><div>In the old days, some users ran our programs through a vt100 emulator (or kermit) on a PC running MSDOS, and we had small script that they could run to customize the function keys to generate commands for our systems.</div><div><br></div><div>William</div><div><br></div>                                     </div></body>
</html>