lubkin@cs.rochester.edu (Saul Lubkin) (05/22/91)
In <ERIC.91May21141836@femto.mks.com>, it is noted that: >Doing "__setostype(0)" will change an -Xp application from POSIX.1 to System V >behaviour. If all you want is job control I believe you can use -lcposix >instead of -Xp. I've tried both previously. Using "-lposix" without "-Xp" produces an executable bash -- that hangs on invocation, with the message, "stopped tty input" (or "output", I don't remember which). It needs the startup code pulled in by "-Xp" (perhaps for proper signal handling, or terminal handling, or both), when linked with "-lposix". Using "-Xp" and starting with "__setostype(0)" has the same effect. Probably some subset of the startup code ("/lib/crt0p.o", or some such thing) would do the trick. But which subset (would allow the shell to work properly, while not setting up _POSIX_NO_TRUNC and _POSIX_CHOWN_RESTRICTED ? Actually, I'm beginning to "get hooked" on some of the POSIX features. For example, when extracting a tar archive with the usual sysv semantics, unless you are root, you cannot extract files (without using options) that belong to a numerical id not in /etc/passwd (which is the usual case). POSIX semantics extracts the file, making you the owner. If I could just figure out how to turn off _POSIX_NO_TRUNC and _POSIX_CHOWN_RESTRICTED ... (or, failing that, work out some subset of the posix startup code that would be enough to support job control) ... In the meantime, I've compiled the gnu fileutilities, including a prerelease of "chown", each utility starting in "main" with "__setostype(0);", so that all POSIX features are automatically turned off during the duration of their execution. And I've edited "uucleanup", so that uucico usually doesn't have to create new directories (since the "chown" system call that uucico will then make, will fail, when uucp was executed under bash. The ultimate way to do this, actually, would be to replace uucico with a binary that first calls "__setostype(0);" and then execs the standard uucico. I've created an experimental such "sh", as well (named it "svsh", since it always uses svr3 semantics, rather than posix, no matter how it's been called)). Sincerely yours, Saul Lubkin
peter@ficc.ferranti.com (Peter da Silva) (05/25/91)
In article <1991May22.012236.5854@cs.rochester.edu> lubkin@cs.rochester.edu (Saul Lubkin) writes: > Actually, I'm beginning to "get hooked" on some of the POSIX features. For > example, when extracting a tar archive with the usual sysv semantics, unless > you are root, you cannot extract files (without using options) that belong > to a numerical id not in /etc/passwd (which is the usual case). POSIX > semantics extracts the file, making you the owner. I'm sorry, I can't figure out what you're talking about. Perhaps you can elaborate. The "usual sysv semantics" don't say squat about chown not working if the uid isn't in /etc/passwd. I do this all the time with no problem. -- Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180; Sugar Land, TX 77487-5012; `-_-' "Have you hugged your wolf, today?"