kevin@msa3b.UUCP (Kevin P. Kleinfelter) (10/17/89)
I am porting ksh to AIX. The only thing which prevents a trivial port is that AIX has both SYSV and BSD features. The make for ksh tries to work in either a SYSV or a BSD environment, and in a few places has a little trouble because it is in BOTH. After I get a clean compile and link, I fire-up ksh and get a prompt. Then I type pg foo and I get pg: cannot reopen stdout I have seen this message before, in particular on a 3B2 at an AT&T System Administration class. What does it mean (aside from the obvious)? What do I do about it? -- Kevin Kleinfelter @ Management Science America, Inc (404) 239-2347 gatech!nanovx!msa3b!kevin
ekrell@hector.UUCP (Eduardo Krell) (10/18/89)
I suggest you get the '88 version of ksh, which doesn't depend on BSD
vs. System V but instead configures itself according to certain
functionality in the operating system and C library (ie, it doesn't
assume either 100% System V nor 100% 4.3 BSD).
Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ
UUCP: {att,decvax,ucbvax}!ulysses!ekrell Internet: ekrell@ulysses.att.comjohnny@edvvie.at (Johann Schweigl) (10/20/89)
From article <1156@msa3b.UUCP>, by kevin@msa3b.UUCP (Kevin P. Kleinfelter): > ksh and get a prompt. Then I type > pg foo > and I get > pg: cannot reopen stdout > Hi Kevin! I've experienced the same problem. Its not related to pg in any way. I suspect ksh closes the wrong files under certain circumstances before forking and execing a child proc for piping. Maybe ksh is playing around with the CLOSE_ON_EXEC flag in a way AIX doesn't like. I'll check out that. Under AIX PS/2 ksh is running fine, just compile with all the BSD defines. -- This does not reflect the | Johann Schweigl | DOS? opinions of my employer. | johnny@edvvie.at | Kind of complicated I am busy enough by talking | | bootstrap loader ... about my own ... | EDVG Vienna |
guy@auspex.auspex.com (Guy Harris) (10/22/89)
>> pg: cannot reopen stdout >> > >Hi Kevin! I've experienced the same problem. Its not related to pg in any >way. I suspect ksh closes the wrong files under certain circumstances >before forking and execing a child proc for piping. In the S5R3.1 source, that message comes if "pg" can't do an "freopen" on "stdout" with "/dev/tty". I suspect this dates back to S5R2. Perhaps "ksh" is setting things up so that the child process doesn't have a controlling tty? Seems more likely than some problem with some file getting improperly closed....
kevin@msa3b.UUCP (Kevin P. Kleinfelter) (10/22/89)
johnny@edvvie.at (Johann Schweigl) writes: >From article <1156@msa3b.UUCP>, by kevin@msa3b.UUCP (Kevin P. Kleinfelter): >> ksh and get a prompt. Then I type >> pg foo >> and I get >> pg: cannot reopen stdout >> >Under AIX PS/2 ksh is running fine, just compile with all the BSD defines. The "88b" version of ksh sources, now distributed by the toolchest, self-configures. This means I cannot just tell it that I am "BSD" or "SYSV". The source of this problem is that the ksh configure decides that "setpgrp" should be used to create a process group, and creates a #define to do this. Since setpgrp loses /dev/tty, one must "#define" this to "setpgid(0,0)". This brings me to the following list of changes necessary to make the "88b" version of ksh sources work properly on AIX PS/2 V1.1: 1) Change #define in include/sh_config to #define setpgrp to setpgid(0,0). 2) Edit "include/io.h" to remove "#undef O_NDELAY" and edit "sh/io.c" to change "#ifdef O_NDELAY" to "#ifndef FNDELAY". The problem here is that ksh #undefs O_NDELAY, but later uses FNDELAY, and in AIX FNDELAY is #defined using O_NDELAY. 3) "#undef dirent" before "#include sys/dir.h" in "sh/expand.c" because dir.h defines dirent too (so you get 2 definitions of dirent). 4) Edit "install/config" to echo "#undef SIG_NORESTART". The configure process decides that AIX does not restart I/O to the tty on interrupts. It is wrong, it does. I post this because several other people have indicated trouble in porting ksh to AIX. These comments probably apply only to 88b ksh and to AIX PS/2 V1.1. With these changes it seems to work pretty well, although I have only tested the features that I use. Lotsa luck to other porters. I have an email address for David Korn, and after I use ksh a little longer, I will email these problems to him, so perhaps ksh will work better with AIX in the future. -- Kevin Kleinfelter @ Management Science America, Inc (404) 239-2347 gatech!nanovx!msa3b!kevin