gww@aphasia.UUCP (George Williams) (01/01/70)
> Hmph.
Well I seem to have been a bit hasty in my `Hmph', but one point I have not
seen answered is: the commands I give to one program don't look much like the
commands to another (ie history from my text editor is not likely to be useful
for csh (these being the two programs I tend to interact with most)). The nice
thing about keeping history in csh is that I can see the last 200 commands
without having to look at the last 500 pages of editing. This is very useful.
Much more useful (I would think) than the occasional need to get something
out of my editing session.
Also terminals tend to have limited memory (even 68k terminals with hard disks
will be hard pressed to keep around enough text to store the last 200 csh
commands).
On the rare occasions when I startup csh on a pty in my editor, I find I tend
to uses csh's history rather than moving around in the window. Fewer keystrokes
are involved (perhaps this is a comment on my editor, but I don't think so).
Anyway the gist of this is I want history from different programs separate,
I want a mechanism that is at least as terse as csh.
George Williams
decvax!frog!aphasia!gwwjohnl (09/07/82)
I hear that %r is gone from System III because Dennis Ritchie felt it was excessively unportable. It pretty much assumes that if you pass the wrong number of arguments to a function, they're matched up left to right, and that you can treat the arguments to a function as a vector. At INTERACTIVE Systems, when we cranked up System III we missed %r enough that we added new stdio functions that give you pretty much the same power but use the more portable va_args stuff. Others might want to do the same. John Levine, decvax!cca!ima!johnl, harpo!esquire!ima!johnl (uucp) Levine@YALE (Arpa), 617-491-5450 (desperation) --------
davis@hplabs.UUCP (Jim Davis) (08/08/83)
Steven J Holmes <sjh@csnet-purdue> writes: > You cannot always use rm -i *. I have accidentally > created a file named '-mab' which causes an unkown > option message from rm when rm -i * is tried. However, 'rm -i ./*' should work fine. It does on this system(Berkeley 4.1). % ls -mab % rm -i * rm: unknown option -mab % rm -i ./* rm: remove ./-mab? y % -- Jim Davis (James W Davis) ...!ucbvax!hplabs!davis davis.HP-Labs@UDel-Relay ----------------------------------------------------------------
tim@callan.UUCP (Tim Smith) (03/09/85)
Well, I just tried everything on a System III sh. This is even stranger. Let 'parent' be a command that prints the result of getppid(). Then the command if true then parent parent parent fi < /dev/null shows the first two 'parent' commands are run from a subshell, while the third is run from the main shell! What IS going on? -- Duty Now for the Future Tim Smith ihnp4!wlbr!callan!tim or ihnp4!cithep!tim
johnl@ima.UUCP (03/12/85)
> if true > then > parent > parent > parent > fi < /dev/null > > shows the first two 'parent' commands are run from a subshell, while the > third is run from the main shell! What IS going on? Glad you asked. In fact, all three of the "parent" programs are run from a subshell. There is, however, a longstanding hack in the shell such that the lexically last command in a subshell is exec'ed directly without an extra fork, which saves a little time. This is what you're seeing. All this goes to show that although the shell is a thing of wonder, its semantics are not well specified. (The C Shell is even worse, lest people think I'm biased.) The semantics I'd like to see would promise that all variable setting be (effectively) in the top shell unless explicitly put in a subshell by enclosing a sequence in parens. I realize this would be tricky to implement, but it sure would make shell programming easier. John Levine, ima!johnl
thomas@utah-gr.UUCP (Spencer W. Thomas) (03/15/85)
In article <508@ima.UUCP> johnl@ima.UUCP writes: >The semantics I'd like to see would promise that all >variable setting be (effectively) in the top shell unless explicitly put in >a subshell by enclosing a sequence in parens. I realize this would be >tricky to implement, but it sure would make shell programming easier. And what would foo=spam | foo=vegemite | foo=peanut_butter_and_jelly do? -- =Spencer ({ihnp4,decvax}!utah-cs!thomas, thomas@utah-cs.ARPA) "The truth remains that, after adolescence has begun, `words, words, words,' must constitute a large part, and an always larger part as life advances, of what the human being has to learn". -William James
rogers@dadla.UUCP (Roger Southwick) (04/24/85)
[No matter where you go..... there you are. Buckaroo Banzai]
Dear Fellow Gurus,
I realize I'll probably get lots of flames for
asking this observation (question) and making a (minor) suggestion,
but here goes:
It seems to me that (when this was bandied about on the net
a few weeks ago) there never was a EASY method for determining
which version of UN*X a program was being compiled under.
I seem to remember a few suggested methods, but I don't ever
recall ONE method which would work under all cases (or did
I miss this?).
Anyway, given that there (probably) wasn't one submitted,
I'd like to make the below suggested method for you all
to consider, and make comment on. Please send me mail
(don't post to the net) and I'll (try to) summarize and
make a final posting later.
What I'm proposing is for ALL UN*X systems to have a single
(additional) include file: /usr/include/unix.h, which would
contain something like:
/*
* This file contains a definition for the type
* of Unix this machine is running under.
*
* There are defines for most known types of Unix
* and then the UNIX define is set up in terms
* of this.
*/
#define V6 0
#define PWB 1
#define V7 2
#define SYS3 3
#define 32V 4
#define BSD2_8 5
#define BSD4_1 6
#define SYS5 7
#define BSD2_9 8
#define BSD4_2 9
#define ULTRIX 10
#define P1003 11 /* /usr/group standard */
...
#define UNIX BSD4_2
Anyway, you get the idea. Then all programs would have to do
is to include this file, then have lines like:
#if UNIX == BSD4_2
I've tried (in the above) to basically stick to a cronological
order as best as I can remember, (forgive me if I've got them
out of order a bit) and I think this may be as good as any
approach to future defines.
Anyway, what do you all think?
-Roger
UUCP: ...!tektronix!dadla!rogers
CSnet: rogers%dadla@tektronix
ARPAnet: rogers%dadla%tektronix@csnet-relay
BELLnet (phone): (503)-629-1911
SNAILnet (U.S. Mail): Roger Southwick
Tektronix, Inc.
P.O. Box 4600, D.S. 92-731
Beaverton, Oregon 97075gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (04/25/85)
How about getting rid of the unnecessary differences visible to applications altogether. That is the point of the standardization effort.
lmc@denelcor.UUCP (Lyle McElhaney) (04/29/85)
> What I'm proposing is for ALL UN*X systems to have a single > (additional) include file: /usr/include/unix.h, which would > contain something like: > > #define V6 0 > #define PWB 1 > #define V7 2 > #define SYS3 3 > #define 32V 4 > #define BSD2_8 5 > #define BSD4_1 6 > #define SYS5 7 > #define BSD2_9 8 > #define BSD4_2 9 > #define ULTRIX 10 > #define P1003 11 /* /usr/group standard */ > ... > > #define UNIX BSD4_2 It would be nice if all Unicies had the same user interface, but hardware considerations and sheer inertia guarantee that the problem will be with us a while longer yet. Dave Yost published a piece in this forum stating the above solution won't work, and presenting the solution he uses to make the E (Rand, INed) editor work in different environments. Without further ado, take it, Dave.... Subject: #defines for portable code From: day@kovacs.UUCP (David Yost) Date: Thu, 2-Aug-84 01:02:57 MDT I have been developing and porting the Rand Editor to different machines and systems for five years now. (If you are interested in the significant recent developments, mail or call 213-650-1089.) #defined names that tell you the version of the system, such as SYS5_2 or V7 are not the solution. Among other problems, there are too many hacked kernels out there, and many of the hacks are needed, so you want your program to know they are there. A large, sophisticated piece of software needs to know things about the machine, the compiler, the library functions, and the system calls. My solution to the porting issues has been to use two include files: "c_env.h" for the machine and the compiler, and "localenv.h" for the library and the kernel. Most of what follows should be pretty obvious, but the Regx stuff needs explanation. Briefly, since the compiler assigns registers in the order that it encounters the declarations, if you just declare lots of registers in case the machine has enough, you can lose big on machines with fewer registers than the number you declared. Instead, I declare them Reg1, Reg2, ... in the order of importance, and the c_env #define's take care of the rest. === c_env.h /* * C Environment. * Information about the machine and the compiler. * * VAX 4.1bsd & 4.2bsd */ /* * In the #define's that follow, define the first n to 'register' * and the rest to nothing, where 'n' is the number of registers * supported by your compiler. */ #define Reg1 register #define Reg2 register #define Reg3 register #define Reg4 register #define Reg5 register #define Reg6 register #define Reg7 #define Reg8 #define Reg9 #define Reg10 #define Reg11 #define Reg12 #define CHARMASK 0xFF #define CHARNBITS 8 #define MAXCHAR 0x7F #define SHORTMASK 0xFFFF #define SHORTNBITS 16 #define MAXSHORT 0x7FFF #define LONGMASK 0xFFFFFFFF #define LONGNBITS 32 #define MAXLONG 0x7FFFFFFF #define INTMASK 0xFFFFFFFF #define INTNBITS 32 #define MAXINT 0x7FFFFFFF #define BIGADDR /* text address space > 64K */ /* fine ADDR64K /* text and data share 64K of memory (no split I&D */ #define INT4 /* sizeof (int) == 4 */ /* fine INT2 /* sizeof (int) == 2 */ #define PTR4 /* sizeof (char *) == 4 */ /* fine PTR2 /* sizeof (char *) == 2 */ /* unsigned types supported by the compiler: */ #define UNSCHAR /* unsigned char */ #define UNSSHORT /* unsigned short */ #define UNSLONG /* unsigned long */ /* fine NOSIGNEDCHAR /* there is no signed char type */ #define STRUCTASSIGN /* Compiler does struct assignments */ #define UNIONS_IN_REGISTERS /* compiler allows unions in registers */ /* fine void int /* Fake the new 'void' type to an int */ /* Byte order: */ #define SHORT_10 /* pdp11, vax, 16000, 8086, 8080, ... */ #define LONG_3210 /* vax, 16000, 8086, 8080, ... */ /* fine LONG_0123 /* ibm, perkin-elmer, 68000, pyramid, ... */ /* fine LONG_1032 /* pdp11 */ === localenv.h /* * System Environment * Information about the system call interface and the C library. * * 4.2bsd - vax & pyramid so far */ /* fine index strchr /* */ /* fine rindex strrchr /* */ /* fine NOIOCTL_H /* there is no ioctl.h */ /* fine RDNDELAY /* read call has NDELAY capability */ #define EMPTY /* can implement empty(fd) subroutine call */ #define LINKS /* file system has links */ #define CANFORK /* system has fork() */ #define VFORK /* system has vfork() */ #define ABORT_SIG SIGILL /* which signal does abort() use */ #define SIGARG /* signal catch routine has sig num as arg */ #define SIG_INCL <signal.h> #define SGTT_INCL <sgtty.h> #define TTYNAME /* use ttyname function */ /* define TTYN /* use ttyn function */ #define SHORTUID /* uid is a short, not a char (v7+) */ #define ENVIRON /* getenv() is implemented */ #define VAX_MONITOR /* use monitor() routine for vax */ #define SIGNALS /* system has signals */ #define SYMLINKS /* 4.2 symbolic links */ #define NDIR /* 4.2 dirrectory routines */ #define SYSMKDIR /* use mkdir(name, mode) system call */ #define SYSRMDIR /* use rmdir(name) system call */ #define SYSFCHOWN /* use fchown(fd, ...) system call */ #define SYSFCHMOD /* use fchmod(fd, ...) system call */ #define CLR_SUID_ON_WRITE /* modifying a file clrs suid and sgid bits */ #define SYSSELECT /* system has berkeley select system call */ #define WAIT_UNION /* include <sys/wait.h> */ #ifdef WAIT_UNION #define WAITARG union wait #else WAIT_UNION #define WAITARG int #endif WAIT_UNION /* fine MALLOC0OK /* has NULL return arena corruption fix */ === end -- Lyle McElhaney {hao, stcvax, brl-bmd, nbires, csu-cs} !denelcor!lmc
jsdy@hadron.UUCP (Joseph S. D. Yao) (05/07/85)
> [No matter where you go..... there you are. Buckaroo Banzai] > > It seems to me that (when this was bandied about on the net > a few weeks ago) there never was a EASY method for determining > which version of UN*X a program was being compiled under. > ... > What I'm proposing is for ALL UN*X systems to have a single > (additional) include file: /usr/include/unix.h, which would > contain something like: > -Roger [Southwick] > UUCP: ...!tektronix!dadla!rogers Many but not all UNIces already have an include file <local/uparm.h>. It does not bother to define a value for each type of UNIX, but just tries to: #define BSD4_1 /* N O T BSD.4.1 !!! */ or #define SYSVR2 or whatnot, and then use: #ifdef BSD4_1 ... #endif BSD4_1 /* So who likes the ANSI restriction? */ Thus, you need not have a global update of all machines' uparm.h's: just make sure that your symbol is a universally agreed-on one. (What good is #ifdef BSD41 above?) You may wish to define several for particular things available on your machine (#define BSD4_2; #define SCCS; #define RCS). If you want to mess anybody who isn't in your list of machines: #ifdef SYSVR1 ... # elif BSD4_1 /* well, I do like most of ANSI. */ ... # else THIS WILL UPSET THE COMPILER! #endif SYSTEMS /* but not all. */ Anybody want to contribute the symbols for their machine that they like best? Joe Yao hadron!jsdy@seismo.{ARPA,UUCP}
faustus@ucbcad.UUCP (05/09/85)
Personally, I don't like the idea of having an include file to tell the program what version of UNIX you are on -- if you have a large program with a makefile, it is probably better to do the define there. That way, if you want to #define around some block of code that will work on one unix but not on another, you can just define the one you are not currently using and make sure that things work ok (i.e, you didn't #define around anything that should be in both versions by accident...) Also, this works if you want your program to compile on non-unix systems that will probably not have nice #include files sitting around to tell you what is going on... But then you don't have make, so... Wayne
lwall@sdcrdcf.UUCP (Larry Wall) (05/16/85)
No, No, NO! "Which Unix?" is almost always the WRONG question to be asking
in the first place. "Which machine?" is usually the wrong question too.
**********************
*** Which feature? ***
**********************
is the right question to ask if you really and truly want to write portable
code. If you use machine names and OS names in your #ifdefs, you are
probably only portable to the machines in use today, and then only to the
ones you know about, and then only to the ones that haven't been hacked on
by somebody. There is SO much hybridization and cross-fertilization (did I
hear someone say "bastardization"?) going on right now in the Unix world that
a list of machine and Unix types that differentiated all the features would
stretch from here to Pioneer 1. Instead of saying
#if defined(bsd) || defined(pyr) || defined(vms) || defined(sun)
write something like
#ifdef CANDOIT
and then define CANDOIT in a config.h sort of file. BUT, you say, then
I have to depend on the turkey at the other end of the wire to define or
undefine CANDOIT.
Wrongo.
Write yourself a little shell script (well, may not so little) that goes
out and checks for the feature you're interested in and writes the config.h
file itself. This has several advantages:
1) You don't have to depend (so much) on the turkey at the other end of
the wire to correctly edit your config.h or (yikes!) your program.
2) You don't have to depend on the turkeys who wrote the system to have
gotten their whatami.h files set up right.
3) You don't have to try and remember which systems do or don't what.
4) Your system will be portable to all kinds of systems you've never even
heard of.
5) You'll get lots of compliments on how clever you are.
6) You get the fun of figuring out how to write the shell script, unless
you cheat and look at Configure from the rn kit, in which case you
get the fun of looking at Configure.
7) You get to write funny notes like this one to those who don't know
better.
You might be surprised how much you can find out from inside a shell script.
It's really the only way to go. Check it out.
Larry Wall
{allegra,burdvax,cbosgd,hplabs,ihnp4,sdcsvax}!sdcrdcf!lwallgww@aphasia.UUCP (George Williams) (09/28/85)
From various responces I have managed to piece together what happens. >Every now and then after I have been logged in for a while I will try to >su, have su ask the password, and then it sits for a bit and exits. It >does not generate any error messages, the exit status is 0. After this >has happened it will keep happening until I log out, I have always been >able to su immediately after logging in. Actually this isn't su it's the csh (sh does not have this problem). When csh starts up it looks at the directory tree above it (somehow) if . is protected everything works fine, if .. or ../.. (and I assume ......./..) are protected against the new user then it dies. I poked around in csh but could not find an obvious reason for this, I assume it does a pwd type thing and checking . is a special case. I have tweaked su to attempt to open ../../.. before execing the shell, and have it give a warning message if it fails.