Hello, It appears your guess was correct. I tried to figure out how to do that, and came up with the attached patch (against ast-ksh.2009-05-05.tgz). I'm sorry I could not understand how to do this using the build system. It does remove the dmesg log spamming problem. But is it a good solution?
Thank you for explaining the .exe and expected crashes. I guess it is in the documentation, but I missed it. JGH On 3/7/10, Glenn Fowler <[email protected]> wrote: > > On Sun, 7 Mar 2010 05:36:45 +0700 BuraphaLinux Server wrote: >> Hello, > >> Every time I start ksh I get a strange message you can see when you >> run dmesg. The messages look like this: > >> ioctl32(ksh:10707): Unknown cmd fd(0) cmd(0000530f){t:'S';sz:0} >> argb(ffd1c74) on /dev/tty1 > > can you see if this > ioctl(fd,I_PEEK,&pbuf) > corresponds to the dmesg trace > >> This happens both with ksh-20090505 and ksh-20100301. I also get >> messages about Fzapp2407.exe in my system logs when I build ksh, even >> though this is a linux system where .exe files won't run, but they say >> on pipe:[####] and on socket:[#####] instead of on /dev/ttyX or >> /dev/pts/X. > > to avoid confilicts with systems that may or may not require .exe, > the iffe and probe scripts just punt and throw .exe on every test executable > > the .exe a.out's probe local system features, so you can expect anomalous > behaviour from them, up to and including core dumps -- with a core dump > possibly being an expected outcome > >
peek.patch
Description: Binary data
_______________________________________________ ast-users mailing list [email protected] https://mailman.research.att.com/mailman/listinfo/ast-users
