[OS X TeX] Recent allegations about tcsh

Gerben Wierda Sherlock at rna.nl
Thu Sep 12 13:47:35 CEST 2002



Gary, please relate this to Jordan (though I must have his card/address 
somewhere here) and by all means also read this yourself.



I never said that Apple should have kept Fred Sanchez or whoever's 
personal compilcated setting (I personally kind of dislike that whole 
complicated setup myself). The damage Apple did was a) shipping a system 
where /usr/local/bin is not part anymore of the PATH of a non-root 
default setup and b) the instructions (Fred's?) in tcsh examples/README. 
Many Open Source projects rely on having stuff available through the 
PATH mechanism (scripts as part of software projects like ghostscript 
for instance). And many open software projects use /usr/local/bin as 
their location. Not having /usr/local/bin in the default PATH forces 
peopel to change PATH settings, or in other words, change settings at 
all (and all those private settings are playing havoc with any attempt 
at support).

It cannot be denied that partly as a result of Apple trimming the PATH, 
partly because they rightly moved from Fred's complicated setup to 
something more standard, a miriad of solutions have sprung up for a 
problem that was formerly not there, amongst the worst of which is sadly 
the suggestion made in the examples/README, worst because those example 
settings are good for /etc/csh.login but not for ~/.login as they 
*replace* settings instead of *augment* them.

The result of all of this is that I am confronted with many users, all 
now having *different* personal settings, which all in some way 
influence the behaviour of their software. Instead of a single 
system-wide setup, I now have to deal with debugging personal settings 
at a distance, and that is way beyond my means. When the follow the 
instructions in tcsh's examples/README they will not have valid PATHs 
nor will they inherit system-wide settings I can set for them. This is 
the result of the changes between 10.1 and 10.2 and that cannot be 
denied.

(If you ask me, not having /usr/local/bin in the default non-root cli 
PATH is a unix no-no as well, I cannot remember having used a unix 
system where /usr/local/bin was not part of the default PATH, but my 
memory may fail me here, nor have I had access to all the unix flavours 
around).

In short:
1. the lack of /usr/local/bin forces many more people to change their 
settings from the system-wide version amking it more difficult for me to 
support them (and that is a *fact*, not apocalyptic).
2. there are solutions out there that make matters even worse, and the 
one in tcsh's examples/README is one of them.

G

PS. My frustration about the fact that I might have to drop support 
because of all of this may have shone through in my postings on the 
mailing list, but bear in mind that I bear the brunt of the problems 
that result from the changes, not Jordan or anyone else at Apple. 
Therefore, though there is some parity between me being frustrated about 
Apple on the list and Jordan calling me 'apocalyptic' in public, I do 
feel a bit miffed about the fact that I am providing this effort free of 
charge and my reward from Apple is being called names in public. I would 
have been chique if Jordan would have communicated with me first so we 
could have had our facts/position straightened out.

Below a few comments and also below some quotes form me from the list so 
Jordan can see what I actually did write (things about Apple having 
'good reasons' to do what they did, something he clearly missed)

On Thursday, September 12, 2002, at 12:50 , Gary L. Gray wrote:

> Jordan K. Hubbard of Apple asked me to post this to the list for him.
>
> ==============================
> I'm not sure why this discussion is occurring on a mailing list about 
> *TeX*

Clearly. Well, for your information, things have stopped working and 
things have become more complex, mainly for people like me who do not 
want to copy fink's 'imperialistic' style in PATH management and who do 
want to have an as default as possible solution for open source ports.

> , but just to address some of the misconceptions recently expressed 
> about the tcsh defaults, I thought I'd make a few points:
>
> 1. The default behavior of tcsh is now the *default* behavior, which is 
> to say that tcsh behaves under Mac OS X 10.2 as it does on every other 
> Unix system which ships tcsh.  Depending on customizations in any 
> scripts you may write or even in documentation you may provide to 
> end-users is a real mistake since it only results in confusion when 
> those scripts or procedures are attempted on another Unix system.  This 
> is one of the reasons that tcsh was "stripped down" to its defaults 
> again in the standard configuration, it then being a deliberate act on 
> the user's part if they want to change those defaults and hopefully 
> something which will stick better in that user's memory.
>
> It's sort of like remapping your keyboard to a dvorak layout.  Sure, 
> there are a lot of people who say that's a superior layout and that 
> there's a huge body of evidence to support the assertion that the 
> qwerty layout is rather deliberately sub-optimal, but would you ship an 
> OS with the default keyboard map set to dvorak?  No, you set the 
> default behavior according to the most common denominator for what 
> people assume it's going to be, and there are probably just as many 
> "Linux switchers" using Mac OS X now as there are people who jumped 
> aboard with 10.[01] and upgraded to 10.2, so it's even hard to argue 
> that the "weight of assumption" falls clearly on the side of the 
> previous default behavior.  In any case, it's easy to restore that 
> default behavior for those people who liked it, and that brings us to 
> our next point.
>
> 2. We ship /etc/csh.* essentially "empty" as it is, so whether you 
> source the old defaults in from /etc/csh.login or $HOME/.login, you're 
> going to get the same behavior.  If you've already added a bunch of 
> customizations of your own to either /etc/csh.* or $HOME/.login then 
> you're clearly a power user and you don't WANT to blindly suck in the 
> old defaults anyway given that they'll potentially conflict with your 
> own settings (no matter where you source them from).  You'll want to 
> read through the examples (which is why we called them "examples") and 
> pick and choose the bits you like best, just as you probably did back 
> when you came up with your original .login contents by looking over 
> your buddy's shoulder (so to speak) and stealing bits you liked best 
> from his or her defaults.
>
> It's widely held that the only .login file written completely from 
> scratch was probably Ken Thomson's, everyone else having derived theirs 
> from someone else's and then customized it to their own tastes.  This 
> is only right, and where Fred Sanchez got it wrong was in making his 
> *personal* defaults the system-wide defaults, which is a real no-no 
> from a Unix perspective.

Agreed.

> Some of us like Fred's choices and some of us don't, my group at Apple 
> probably receiving an equal number of flames and praise for the 
> previous set of "defaults", and since individual preferences are as 
> varied as their individual genetic codes, the right thing to have done 
> from the start would probably have been to canvas the Unix community 
> for 5 or 6 different "interesting user profiles" and provided them as 
> examples for reference, not exhibiting any preference for one over the 
> other.

I am amongst teh people that do *not* like Fred's setup very much (far 
too complicated). Tha various profiles is an interesting idea.

> In any case, Gerben has made the situation sound far more apocalyptic 
> and dire than it really is, and the fact of the matter is that if 
> you're a naive user who will never customize your settings further but 
> like being Fred Sanchez, you can simply follow the README letter for 
> letter and nothing bad will happen to you beyond bearing a sudden 
> uncomfortable resemblance to Fred.

Here you are missing a point. For software maintainers and supporters 
like me, those kind of personal settings are disastrous because they 
*override* instead of *augment* the system-wide setting. In other words, 
*I* can only support system-wide settings, but the examples/README 
instructions create a situation where the link between system-wide and 
personal settings is damaged. Since now many more people are creating 
personal setups, the support situation for me deteriorates.

> If you're a power user, you don't NEED to blindly follow in Fred's 
> footsteps since you'll undoubtedly derive a lot more value from simply 
> reading through his examples and incorporating those bits you like by 
> hand, undoubtedly laughing and shaking your head at the rest.

I am not interested at all in power users. They can fix their own 
problems. What I am intereste in is the not-so-power user (say a 
mathematician at a university) who sometimes needs command line access 
(because not all functionailty is covered by the GUI's) and who doesn't 
know anything about unix (nor, as an Apple-user should he need to know. 
I think Jordan gave an excellent speech on this issue during the Nluug 
conference last November.

G

 From earlier messages on the list:

>> From Gerben's statements, there seems to be a reason for not having 
>> this login file where it was. Is that right?
>
> No, it does not really matter.
>
>> It's also a secret matter of some sort for Apple, or Gerben is simply 
>> protecting idiots like me from ourselves. ;)
>
> No, I heard the reason (in itself a good reason, but the result has 
> disadvantages I think they underestimated) for this decision from 
> someone inside Apple. As I do not know if this is public knowledge 
> (e.g. has been discussed on the public darwin lists that I do not read 
> myself), I consider this information given to me in good faith and 
> without permission to replicate to the world.
>
>> Within a three days I have seen as many solutions. My fears are coming 
>> true. How much trouble it will be for me in the end is yet unknown.




More information about the macostex-archives mailing list