TVR%CCRMA-F4@SAIL.Stanford.EDU (02/15/87)
* Embedding some form of the machine name in your password when dealing large numbers of machines sounds like the most practical and humane suggestion i've heard in quite some time for the problem of people with lots of accounts. Then, those of us who tend to get passwords hardwired into our fingers from frequent use can keep the number of machines with identical passwords down to a bare minimum, on machines that are relatively secure. * I agree the environment variable, SHELL, should not affect 'make' for the reasons stated; it will tend to break things unpredictably. I would suggest another variables, such as MAKE_SHELL, to become the default variable for SHELL in 'make'. This would allow knowledgable people to explicitly change the shell for 'make' without problems for the rest of the users who may not understand the ramifications and/or want their 'makefile's to be portable. On the other hand, those users who care can simply explicitly include a SHELL variable in their 'makefile's and save someone else alot of grief further down the line who has to figure out why 'make foo' doesn't work for him/her. * Be very careful about changing what 'long' and 'int' mean. Using a certain, otherwise quite decent, Macintosh 'c' compilers which defines 'int' as 'short', has cost me phenomenal amounts of debugging time, even more than Apple's (shall we say) *unusual* memory management scheme. On the other hand, we do need to address the issue of longer word sizes. For someone responsible for a PDP-10 system, 32 bit longs hardly seem very long; having not hacked UNIX in the 11/40 days, i might naively expect a 'long' to be something on the order of 72 bits! The other assumption you'd better be careful about is what a pointer is. How many people still use '(long)' when that should be saying '(char *)'? Hopefully everyone at least says '(long)' and not '(int)' [c.f. Mac].