Best way to set environment?

[Titanium Man]

I've been reading a lot here about using .cshrc or .tcshrc or ~/Library/init/tcsh/rc.mine to change environment prefs. I'll admit it, I'm confused. Which way is best? I thought setting prefs in rc.mine was best since you didn't get into the .tcshrc-file-being-read-before-the-.chsrc-file stuff, but I've seen other things recommended here too. What are your thoughts?

DOH! I just caught the tail end of the "Terminal mods" thread and it starts talking about this very thing, so sorry for posting this. I'd love to hear more ideas, though.

[mervTormel]

homer, TiMan,

perhaps what is needed is a real world test and examination.

i propose the following:

create a new user, and setup the vanilla tcsh shell as proscribed in the

/usr/share/init/tcsh/README

[ we'll do tcsh first, then bash ]

edit each script in the chain to broadcast it's name so that we can see the chain of command when we login and/or open new shell windows.

add the subsequent .[proscribedShellrc] to username's ~ and run again, examining behavior.

perhaps we will discover what we need to know about startup that is not evident in the doc's, or a bug will be uncovered, or otherwise, we will know what not to do.

suggestions?

[sao]

MervTormel,

Here we go, finally the thread we wanted started, great!

Timan, good choice.

Can we slowly cover all of the .mine files?

What are the functions of and what goes inside:

aliases.mine
completions.mine
environment.mine
rc.mine
path

and then from:

~/.tcshrc
~/.login
~/.logout

Cheers...

[ebow]

I've been having trouble with stuff contained within environment.mine and rc.mine not working. However, aliases.mine and path seem to work just fine. So I'd love to see a thread that goes thru the whole tcshrc thang.

[Titanium Man]

Merv, I love your idea: the scientific approach, and sao, that would be GREAT if we could go over those files; it's been confusing me for a while. Ok, so I started up a new user and checked out /usr/share/init/tcsh/README. Now the FIRST part says to do this:

echo "source /usr/share/init/tcsh/rc" > ~/.tcshrc
echo "source /usr/share/init/tcsh/login" > ~/.login
echo "source /usr/share/init/tcsh/logout" > ~/.logout

but just AFTER that it says:

To do this system-wide, do the same instead to /etc/csh.cshrc, /etc/csh.login, and /etc/csh.logout.

So I checked out my /etc/csh.cshrc, /etc/csh.login, and /etc/csh.logout files, and they already had "source /usr/share/init/*" where * stands for rc in cshrc, login in chs.login, and logout in csh.logout. Hmm. Ok NOW the README says:

In order to customize tcsh:

mkdir ~/Library/init/tcsh

and create the following files there as necessary:

aliases.mine - shell aliases
completions.mine - completions
environment.mine - environment
rc.mine - run commands
path - command search path

Now don't get me wrong; I'm sure there are MANY ways to customize, but since I'm not even an OSX "poweruser" much less any kind of Unix wizard, I'm trying to find out the BEST way (even if it's not the easiest). Ebow, I don't know what's going on with your rc.mine or environment.mine. I haven't had any problems whatsoever, but the only thing in my rc. mine is my terminal prompt customization:

set prompt="%{\033[0;1;32m%}[%{\033[37m%}%t %n %{033[32m%}%{\033[33m%}%c3%{\033[32m%}]%{\033[0m%}%# "

and all I have in my environment.mine is that little thingy to make the autocomplete non case sensitive (and yes "little thingy" is the proper Unix term):

set complete=enhance

(I'm still not sure that's where it goes, but it works). Oh I just caught something; in the above examples of my rc.mine and environment.mine files those don't exist yet in my test user directory that I created to experiment with, only in my usual day to day user directory. So what now Dr Tormel? Is it pass me that butter knife and we'll see what makes this baby tick? (Sorry for such a long post)

[mervTormel]

sorry, gentlemen, my time's been usurped elsewhere and haven't been able to attend to this proposition. but i see TiMan has picked up the ball, so...

this may be a complete waste, but how about editing each script in the user's custom scriptage to broadcast it's name so that we can see the chain of command for the shell.

i think the objective of this is to see what is run on the initial shell window versus new shell windows and every command entered on the shell command line.

perhaps there may be some surprises.

e.g.

% cat .login
# ~/.login

echo "-----------------------------"
echo "well, here we are in ~/.login"
echo "-----------------------------"
echo ""

date

exit

something like that in all the .mine startup scripts.

[sao]

mervTormel, great you are here, I look forward to your posts about this subject.

Please, allow me, I want just to give a little bit of information for beginners who don't know what we are talking about.

The shell is known as "login shell" when it is a shell which is not launched by another. For example, when I open the terminal window a new login shell is launched (in the default configuration of Terminal.app).

When we execute the command tcsh, it launches a new Shell which is not a login Shell.
We say it is an "interactive shell" when it has a prompt where to type commands.


The standard Starting files of /bin/tcsh :

When you login, the files are read in this order:

/etc/csh.cshrc (*)
/etc/csh.login
~/.tcshrc (*)
(~/.cshrc) (*)
~/.login
~/.history
~/.cshdirs
/etc/csh.logout
~/.logout

When the shell is not a login shell only the files marked (*) are read.

The file ~/.cshrc is read only if the file ~/.tcshrc is not found.
The files /etc/csh.logout and ~/.logout are read only when we exit the login shell.
The files ~/.history and ~/.cshdirs are not really configuration files but files that preserve constant data from one session to another.

In MacOS X, the files /etc/csh.cshrc , /etc/csh.login and /etc/csh.logout, call upon files located in /usr/share/init/tcsh/. These new files define a new hierarchy of starting files.

In all, we have the following files in this starting order

/etc/csh.cshrc
/usr/share/init/tcsh/rc
/usr/share/init/tcsh/environment
~/Library/init/tcsh/environment.mine
/usr/share/init/tcsh/tcsh.defaults
~/Library/init/tcsh/rc.mine
/usr/share/init/tcsh/aliases
~/Library/init/tcsh/aliases.mine
/usr/share/init/tcsh/completions
~/Library/init/tcsh/completions.mine
/etc/csh.login
/usr/share/init/tcsh/login
~/Library/init/tcsh/path
~/Library/init/tcsh/login.mine
~/.tcshrc
(~/.cshrc)
~/.login
~/.history
~/.cshdirs
/etc/csh.logout
/usr/share/init/tcsh/logout
~/Library/init/tcsh/logout.mine
~/.logout


The order these files are read, depends if the shell is a login shell or not.
(Some of these files are not read when the shell is not an interactive shell.)
Of course, we can customize the scripts to modify the order and behaviour.

My advice is to become familiar with the default, system-defined environment before making customizations (study). And customizations should be done in the .mine files (like aliases.mine), not in the startup files themselves.

For example we can copy /usr/share/init/tcsh/aliases to ~/Library/init/tcsh aliases.mine, customize aliases.mine and then check for any conflicts with the default environment.

We must make sure that our changes do not conflict with the system defined environment variables and aliases.
If you find that something is "wrong" in your environment, first remove your customizations and see if they are causing a conflict with the system-defined environment.

And using common sense if we want to modify path, we should add additional directories to the existing path and not redefine the path.

(Please, mervtormel, correct me if I wrote something wrong.)

Cheers...

[ebow]

Great idea, tagging each dot-file. I tagged the following files:

~/Library/init/tcsh/aliases.mine
~/Library/init/tcsh/completions.mine
~/Library/init/tcsh/environment.mine
~/Library/init/tcsh/path
~/Library/init/tcsh/rc.mine
~/.login
~/.tcshrc
/usr/share/init/tcsh/aliases
/usr/share/init/tcsh/tcsh.defaults
/usr/share/init/tcsh/rc
/usr/share/init/tcsh/environment
/usr/share/init/tcsh/login
/usr/share/init/tcsh/completions
/etc/csh.cshrc
/etc/csh.login

This is the order they show up when I start Terminal, or open a new terminal window:

/etc/csh.cshrc
/usr/share/init/tcsh/rc
/usr/share/init/tcsh/environment
/usr/share/init/tcsh/tcsh.defaults
~/Library/init/tcsh/rc.mine
/usr/share/init/tcsh/aliases
~/Library/init/tcsh/aliases.mine
/usr/share/init/tcsh/completions
~/Library/init/tcsh/completions.mine
/etc/csh.login
/usr/share/init/tcsh/login
~/Library/init/tcsh/path
~/.tcshrc
/usr/share/init/tcsh/rc
/usr/share/init/tcsh/tcsh.defaults
~/Library/init/tcsh/rc.mine
/usr/share/init/tcsh/aliases
~/Library/init/tcsh/aliases.mine
/usr/share/init/tcsh/completions
~/Library/init/tcsh/completions.mine
~/.login
/usr/share/init/tcsh/login
~/Library/init/tcsh/path

That's precisely the order, duplications and all. Notice that the following is not being processed:

~/Library/init/tcsh/environment.mine

I don't know what a "login shell" is, so I can't comment on that. Two other things I've noticed are that when I do a "source .tcshrc" which is the way I learned way back when to process changes to these dot-files, I get the following order:

~/Library/init/tcsh/rc.mine
/usr/share/init/tcsh/aliases
~/Library/init/tcsh/aliases.mine
/usr/share/init/tcsh/completions
~/Library/init/tcsh/completions.mine

When I "su" into my username from my prompt, I get the following:

/etc/csh.cshrc
/usr/share/init/tcsh/rc
/usr/share/init/tcsh/tcsh.defaults
~/Library/init/tcsh/rc.mine
/usr/share/init/tcsh/aliases
~/Library/init/tcsh/aliases.mine
/usr/share/init/tcsh/completions
~/Library/init/tcsh/completions.mine
~/.tcshrc
/usr/share/init/tcsh/rc
/usr/share/init/tcsh/tcsh.defaults
~/Library/init/tcsh/rc.mine
/usr/share/init/tcsh/aliases
~/Library/init/tcsh/aliases.mine
/usr/share/init/tcsh/completions
~/Library/init/tcsh/completions.mine

So it seems like everything's getting processed twice (and hence the long post - sorry!), except for environment.mine which isn't getting processed at all. I just checked the global environment file, and it has the "Read user's environment" statement, which looks proper. Nothing appears abnormal about the permissions or formatting of environment.mine.
Oh well, enough exploring for now.... If anyone has a flash of insight into my problem, perhaps having seen this before, I'd appreciate the feedback.

-ebow-

[mervTormel]

sao, thanks for the excellent post.

in a cursory examination, i see that

/usr/share/init/tcsh/rc

will only call

/usr/share/init/tcsh/environment

if it's the top most shell, interactive or an Xsession, and

if the shell is non-interactive, no calls are made to

/usr/share/init/tcsh/aliases
/usr/share/init/tcsh/completions


so, there are several branches taken depending on if it's the first shell, interactive or not, xsession or not, hmmmm, what else?

note: shell scripts are run in a subshell unless you use source or . commands to start the script.

let's continue to examine this and what is meant by login shells, non-login shells, non-interactive shells, sub-shells, and their ilk.


and does this illuminate anything about macubergeek's startup problem?

http://forums.macosxhints.com/showthread.php?s=&postid=3644

[mervTormel]

ebow, you slipped in there right before my post.

excellent job. that's what i want to see ( without fiddling with my accounts :D

remember, the environment script is only run once, for the top shell, and that environment is inherited (?) by subsequent shells.

something nags at me about a bug in /usr/share/init/tcsh/environment that i fixed here for some version of tcsh.

eyeball that script and see that it makes the correct ref about your environment.mine.

edit: -ebow-, try this:

% exec tcsh -l

that'll get you a fresh login shell, like the first terminal window (?) perhaps you'll see your call to environment.mine ?

[ebow]

FWIW, here's the meaningful contents of my /usr/share/init/tcsh/environment:


setenv ENV_SET # avoid repeat

umask 022 # files created are -rw-r--r--

##
# Read user's environment
##
if (-r "${tcsh_initdir}/environment.mine") then
source "${tcsh_initdir}/environment.mine"
endif


The if...then...endif statements has exactly the same structure as any other such file.

[ebow]

mervTormel -

No luck with the "exec tcsh -l" command. I get the same sequence as when opening a new window or starting terminal, but without *any* environment files.

[this message board software needs a good "hmm" face :) ]

Thanks for the ideas!

[mervTormel]

ebow, try this:

% unsetenv ENV_SET
% exec tcsh -V

...

unset the ENV_SET variable and exec the shell with verbosity on, then you can trace what happens in .../tcsh/rc when it checks ENV_SET


also, i am wrong about environment getting inherited in new shell windows.

for each new terminal window, i get

---
welp, here we are in ~/Library/init/tcsh/environment.mine
---

:mad:

[ebow]

Don't get too frustrated over obscure settings problems on a stranger's computer... :cool:

I tried unsetting the variable and doing a verbose exec. The part of interest went as follows:


if ( ! $?ENV_SET ) then
if ( -r "${default_tcsh_initdir}/environment" && ( $?prompt || $?XSESSION ) ) then
source "${default_tcsh_initdir}/environment"
echo "processing /usr/share/init/tcsh/environment"
processing /usr/share/init/tcsh/environment

[several blank lines]

setenv ENV_SET

umask 022

[several blank lines]

if ( -r "${tcsh_initdir}/environment.mine" ) then
source "${tcsh_initdir}/environment.mine"
endif
endif
else


The second time it gets to "if ( ! $?ENV_SET ) then" (because /usr/share/init/tcsh/rc has been called again) it just skips over the section (which makes sense). It seems like it wouldn't even print the "source "${tcsh_initdir}/environment.mine" line if it didn't intend to do it, so that means that environment.mine is getting sourced, but not getting sourced.

UPDATE/edit: The fact that the file never properly got sourced made me think there must be something wrong with the *file* itself, as opposed to the path, filename, contents, etc. So, I renamed environment.mine to ___.BACKUP, and then pasted the contents into a new textfile in BBEdit. I saved it with Unix line breaks, opened a new terminal window, and voila! It's in the loop.

Something that might be significant. The Finder reports that all files in ~Library/init/tcsh, except the new one, are "Apple SimpleText Document"s. Since pico, vi, BBEdit, and TextEdit opened them all the same (escape sequences made in vi the exception) I figured it was just report "text file" as "SimpleText Document". The fact that *every other* file worked properly further reinforced that notion. However, something must have been not quite right with the environment.mine file.

Thanks for prompting this exploration! I'm going to make sure all my files are "proper" unix text files now... While BBEdit can't create escape sequence characters (such as ^V^[ in vi) it seems to respect them, so I'm going to stick with that as my editor for at least my own tcsh settings files.

[mervTormel]

not frustrated, but we're developing some good troubleshooting skills here.

how to investigate this further...

what happens when you just:

% source "${tcsh_initdir}/environment.mine"

how about starting a verbose sub-shell and running it...

% tcsh -V
...
argle-bargle
...

% source "${tcsh_initdir}/environment.mine"

[mervTormel]

ebow wrote:
--
UPDATE/edit: The fact that the file never properly got sourced made me think there must be something wrong with the *file* itself, as opposed to the path, filename, contents, etc. So, I renamed environment.mine...
--

way to go. that's what i was poking at you about. get down in there and find the truth. investigate the atomic elements of a thing and the skills are developed in course.

now, where were we?

regards, mt

[Titanium Man]

Wow, I missed a lot while I was asleep! Great work ebow! So, what does all this mean? If source /usr/share/init/tcsh/* is already in all the appropriate files (/etc/csh.cshrc, /etc/csh.login, and /etc/csh.logout) as per the instructions for system wide use in share/init/tcsh/README, we should be set just modifying the .mine files right (not creating ~/.tcshrc, ~/.login, and ~/.logout files)? Unless we're on a big network and DON'T want to make system wide changes? (Sorry I'm really not that dense, just new to Unix).

[ebow]

Yeah, aside from figuring out about text file formatting, I got the impression that setting up a ~/.tcshrc file was redundant. I'm not sure about the .login and .logout as I have no (current) use for them, but they seem to be in the same boat.

[sao]

From the tcsh manual pages online in:

http://www.tcsh.org/Home

<< A login shell begins by executing commands from the system files /etc/csh.cshrc and /etc/csh.login.
It then executes commands from files in the user's home directory: first ~/.tcshrc (+) or, if ~/.tcshrc is not found, ~/.cshrc, then ~/.history (or the value of the histfile shell variable), then ~/.login, and finally ~/.cshdirs (or the value of the dirsfile shell variable) (+). >>

But also says:

<< Users who need to use the same set of files with both csh(1) and tcsh can have only a ~/.cshrc which checks for the existence of the tcsh shell variable (q.v.) before using tcsh-specific commands, or can have both a ~/.cshrc and a ~/.tcshrc which sources (see the builtin command) ~/.cshrc.>>

Well, the point here is to say that it's possible to have both " both a ~/.cshrc and a ~/.tcshrc which sources (see the builtin command) ~/.cshrc." as explained above.

As long as your ~/,tcshrc "source ~/.cshrc".

At the same time, much better to keep it simple and use ~Library/init/tcsh and ~/.cshrc

About ~/.login and ~/.logout the manual says:

<<Commands like stty(1) and tset(1), which need be run only once per login, usually go in one's ~/.login file.>>

<<~/.login
Read by login shells after ~/.tcshrc or ~/.history. The shell may be compiled to read ~/.login before instead of after ~/.tcshrc and ~/.history; see the version shell variable. >>

<<~/.logout
Read by login shells at logout after /etc/csh.logout or its equivalent.>>

I don't use this files myself but just as information:

~/.login file
Hardly anyone needs to have a personal ".login" file. If you do need one, put commands inside which only need to happen at login time.

What Goes Inside a ".login" File?

You can define a special prompt which is seen only in your login window.
You can run special file maintenance commands which only need to happen once, when you login.

~/.logout file
You use if you want to perform special commands at logout time

What Goes Inside a ".logout" File?

Remove unnecessary object files from your login directory.
Remove unsafe entries.


Cheers...

[pmccann]

Let me just bow before the true hard-liners here: sao, and ebow in particular. Your stamina, resolve resourcefulness are enormously impressive!

One clarification: sao wrote...


~/.login file
Hardly anyone needs to have a personal ".login" file. If you do need one, put commands inside which only need to happen at login time.


I disagree, and feel that pretty much everyone *should* have a .login file, but instead they tend to creatively abuse their ~/.cshrc or ~/.tcshrc or ~/Library/init... (you get the idea!). I'm far from immune to this disease. As you point out, the .login is for commands that only need be executed *once* per "session" (ie once for the set of processes initiated by and including the login shell. Sorry, that's an ugly sentence!).

So what sort of things need to be executed only once per session? Well, definitely any environment declarations. So if you've got any "setenv" lines in your .cshrc or (I give up!) other equivalent file you're guilty as charged; not that it really matters, but if we're going to be doing things the "right" way... Of course the whole idea of an environment is that it propagates to subprocesses, including shells in shells etc.

Anyway, as a dirty old recalcitrant I'm going to take a lot of convincing to give up my simple ".cshrc and .login" twosome. Full stop. I appreciate the intent behind the separation of files into environment/login/logout/rc/completions/aliases, but to be honest, it ain't gonna happen! I'll just separate out the bits and pieces within those files.

Familiarity breeds content! (isn't that the saying? Oh...)

Ignore as necessary...

Paul

[stetner]

Originally posted by ebow

UPDATE/edit: The fact that the file never properly got sourced made me think there must be something wrong with the *file* itself, as opposed to the path, filename, contents, etc. So, I renamed environment.mine to ___.BACKUP, and then pasted the contents into a new textfile in BBEdit. I saved it with Unix line breaks, opened a new terminal window, and voila! It's in the loop.
.

For what it is worth, I went through this a while ago (read: too long to remember what I discovered!) and ended up leaving this comment in my environment.mine file:

# This gets over written by sys defaults. put stuff in rc.mine



Now, if I could only remember what I meant by that cryptic little comment.....

UPDATE: I think I remember now... I was trying to set something standard like a 'MANPATH' maybe, and it was never showing up because one of the /usr/share/init/tcsh/... files was over riding my variable. Got ticked off and just reminded myself where I could set thing and not have them be over-ridden.

I do know I am setting my environment variables in my rc.mine file.


Personally, I think this is a case of 'trying to please everyone'. The fact that the initialization files have become this convoluted make them more of a hinderance than a help.

Ahh, if only I could find a ksh that lived up to my expectations.

Doug

[sao]

pmccann, glad you came...

Actually, I was thinking when will you come to join us here as I trust your experience and jugdement a lot.

I know, I know, and I agree with you. I'm all for the ".cshrc and .login" twosome" as you called them.

Problem is everywhere they glorify and teach you how to "creatively abuse their ~/.cshrc or ~/.tcshrc or ~/Library/init..."as you did say. And most of us finish by having a lot of probably unnecessary files.

Noboby explains or teach newcomers how to establish themselves just working with the:

".cshrc and .login"

I see this as a chance, we can all learn something.
Please, if you would just explain further how do you manage these two files, I will be very grateful.

Cheers...

[pmccann]

Hey, cut the flattery, sao!

Seriously, I really don't think there's very much I can say! [Update, on rereading this: doesn't seem to have stopped me from writing a lot!]

Anything that's in a .tcshrc file could just be chucked into a .cshrc file and the former deleted. That whole swag of files in ~/Library/init/tcsh are really only "sourced" as necessary, so you can similarly throw any such commands into one of the terrible twosome (.login / .cshrc).

Stepping back a little: obviously the whole philosophy behind the Apple arrangement (as explained in Fred Sanchez's README file in /usr/share/init/tcsh) is that you shouldn't need to think, for example, about where an alias command should be put: you just put all your aliases in

~/Library/init/tcsh/aliases.mine

and the existing scripts in /usr/share/init/tcsh will take care of loading them as required, as explored by you folk in great depth above. But part of the motivation for this seems to have been overridden by the default set-up: you'll notice that the README talks about throwing the scripts into your .tcshrc and .login and .logout files, but in fact they've already been installed system-wide, leaving the .cshrc/.tcshrc/.login/.logout files in your home directory effectively empty. Which is fine until someone else comes and *requires* you to be using those (as I think you mentioned with fink), and until you start talking to people who've used unix for a long time and just reel off "add this to your .cshrc" in response to any number of queries; and the reality of the current situation is that almost all unix experts that you encounter will have the vast majority of their experience in an environment *other* than Mac OS X.

I had wondered whether this system was adopted from, say, FreeBSD, but having just logged onto a FreeBSD box I can't see an equivalent set of files for users there: instead it's just the usual /usr/share/skel/ (ie "skeleton") files, "dot.cshrc", "dot.shrc", "dot.(whatever...)" that get copied into a new user's account. There's certainly nothing equivalent in Solaris either. Maybe one of the other BSD's?

Please note that I'm not saying there's anything wrong with following the letter of the README, it's just that you'll have something of a problem in translation if you do so. "So should that go in my 'completions.mine' file in my ~/Library/init/tcsh directory?" is not a question I've heard a lot! Admittedly that's a little unfair, in that completions are outrageously groovy, and not used nearly enough in other OS's I've known. But the fact that apple has *only* done this for tcsh (as far as I can tell; corrections welcome!) is somewhat telling: if it's a general strategy then surely it should be available to zsh users, for example. What do they do? Then bash users have to fit into this somehow as well. Seems weird to have tcsh singled out this way.

In short I think this might just be one of those wheels that didn't really need to be reinvented.

So where's this rambling nonsense taking us? NOT FAR! What "should" a .cshrc contain: well, aliases, "set" commands to the shell, and maybe (gulp!) a "source path_to_file" command or two, most probably including the one that fink inserts!

And a .login? Pretty much just environment variables *for me*. Your mileage should probably differ! There *is* a slightly skew aspect to OS X and Terminal.app that I'll quickly try to outline. If you log in to a Solaris box, say, the .cshrc executes, and then the .login executes. Just like OS X. But on other unices you then tend to open a whole slew of Xterm windows to "do your business". On OS X you open multiple terminal windows, *each* of which executes your .cshrc and .login. Slightly odd; I really wish Apple would put some more effort into making the terminal a nicer place to live. It's pretty awful at the moment (cf some of the other threads on these boards), and is also one of the things that receives really bad press among some of the new breed of OS X users; converts from other unix platforms. (Interesting aside: there's a small but steady drift of high-profile perl developers/maintainers who are either using OS X or are very interested in doing so. This can only be good for the OS. Already Perl 5.7.2 (a developer release) is reported to pretty much build out of the box, whereas 5.6.1 required quite a bit of tweaking to do the same. If other people observer similar drift for other projects it'd be nice to hear about it sometime.)

OK, that's me done. Best I can hope for here is that I didn't make the water *muddier* for anyone!

Regards,
Paul

[mervTormel]

'good times' paul, thanks. and thanks to doug.s for his story and POV. i think he's right, it's a 'trying to please everyone' thing, but i add, 'poorly'.

it seems to me that Fred Sanchez's startup methodology was thrown together to prevent the flood of calls from UNIX newcomers to apple about what goes where, as paul alluded. no thinking required, which is why we're stuck in this post-50's rut. nevermind. don't get me started.

by the way, paul

% bash --version
GNU bash, version 2.05.0(1)-release (powerpc-apple-darwin5.2)
Copyright 2000 Free Software Foundation, Inc.
...

/Volumes/foo/bash-2.05a/examples/startup-files/apple/README

is the same lead-filled snowshoe, er, footprint as Fred.S' tcsh startup, but there are other startup examples more traditional.

paul's other good point (among many) is that you should probably have a glancing familiarity how other unices work so you don't sound like a stuttering macolyte zombie at vaunted sysadmin cocktail parties. a veritable plea for a verbal de-pantsing.

-mt

--
i pine for the 50's and i wasn't even born then!

[sao]

(pmccann, this time I promise no flatery at all.)

What can I say, you wrote a great post.

Just think, about all the beginners and the others, that will be reading what we wrote, and that is good, the purpose is served.

By the way, MervTormel adviced me before in other thread that the subject was going to be "a considerable post with a lot of subjective bickering".

Then, I couldn't understand why. All I wanted was to clear up for beginners how to use the files they tell us to use.

Thanks to your post, I know better now how to implement and simplify things. Hope other people understand too.

By the way, I also noticed the perl developers moving slowly to OS X, and I think is great.

Cheers...

[sao]

After having a good night sleep, I read our posts again.

And there are some things that keep running around in my mind.

I can say "I'm not an old Unix hand". (Although I was already alive in the 50', born in 48)
But, have always been a loyal Macintosh user.

I started studying Unix from the time Apple released OS X Beta. I moved fast to XFree86 (actually, from tips learned in Macosxhints) and since then, continue studying every day.

Ater digesting what I learned, from what we wrote in the previous posts, I feel a little more can be done.

Many experienced Unix users had passed through this forum, but I haven't seen this approach explained before. Why?

How are the newcomers suppose to learn what's the best to do?
The hard way I suppose, then.

Wouln't be easier if we all put our knowledge to better use and really say what we think is best and why we think it's the best, so that everybody can learn, without the subjective touch?

In answer to MervTormel post at:*

http://forums.macosxhints.com/showthread.php?s=&threadid=591

I wrote:
<<And it will not turn always into subjective bickering if we keep it focused to the real beginner (somebody, who opens the term for the first time and says "and now what?")>>

So, I say it now, "and now what" ?

(Probably, I know a little more than a beginner to figure it out myself)
But that's not the case, with a true beginner. (And, this is, a Unix newcomers thread)

I would love to keep this thread alive, my intentions are pure, I want to learn, we all want to learn. If the situation is messy, let's clean it up.

But, I need your help guys, I'm not an old "Unix" hand. But of course, feel free to pick up the ball or not. Respectfully yours.

Cheers...

[Titanium Man]

You took the words out of my mouth, sao. I understand that the way proscribed in the /usr/share/init/tcsh/README might be easier for mac users new to Unix, since you don't have to determine what goes where, and that most Unix people apparently have only 2 files they modify, the ~/.cshrc and the ~/.login (that's if I've understood what was previously posted). So, since I'm eager to learn, is it maybe better then to move the contents of the .mine files to the ~/.cshrc and ~/.login files? Is this better if we want to modify environments in different shells (since it's a more "Unix" way?) I'm trying to learn how things work in bash, but now have NO idea where to put what. Thanks for all the help, this has been so informative already!

[sao]

Hi Timan,

I share your concern.

But let me tell you that I already deleted my ~/.tcshrc file and wrote my aliases, prompt, my source path to fink and some other things (fortune, etc.) in the ~/.cshrc file.

Is all working very smoothly. And I'm glad I made the changes.

I don't really know if this is more the "Unix way", but this is probably a much simpler way and I hope it's the message I could understand from pmccann.

Still, I have a lot to learn, and every day is two steps forward and one step back. But I'm really enjoying the ride.

The world of Unix is incredible interesting to me. Rgds and...

Cheers...

PS: Sorry I don't know anything about bash, maybe, MervTormel or pmccann can help us here. I probably will also install bash with fink.

[sao]

Thanks to a great tip from pmccann at the following thread:

http://forums.macosxhints.com/showthread.php?s=&threadid=842

I have now also add the following to my .cshrc file:

set histfile = .history

set savehist = ( 250 merge )

alias lo ' logout '

Cheers...

[Fritz]

I just want to say thanks for all your solid input here. I have searched and searched feeling all alone in my quest for information and people interested as I am in the underpinnings of OSX. I am Sooooo happy to have finally found you all.

Thanks for a great subject and outstanding input.
I am home...

Best regards
Fritz

[sao]

Hi there,

sorry for mixing threads, but I thought it was important to include the following in this one:

-----------------------------
Sao wrote:

pmccann,

thanks, it works like a charm, please tell me what else do you stick in your... .cshrc file?

Come on man, no more secrets here.

and also, pleaseeeee.... open up your .login file, we all want to know what you have inside.

thanks again...

------------------------------

pmccann wrote:

As for my .cshrc file: that's like asking to see my petticoat: errr, my stockings... ummm, my underwear. Phew: got there eventually.

I've just scoured the file in question and can't find anything that's incredibly interesting: maybe this bunch might be of general worth...

set complete=enhance
set color
alias lsc 'ls-F'
alias work 'ssh -L 2001:my.server.com:110 my.server.com'
alias vnc 'ssh -C -L5910:my.work.com:5901 my.work.com'
alias top 'top -u -s 10'

The first one was kicking around osxhints relatively recently: it just makes your tab completion in the shell case insensitive. That is, if you enter

cd /sy

and then hit the tab key it'll fill out the directory to /System (note the capitalization) and so on. I think the pros of this approach outweight the cons, (basically, if you have two files, say "makefile" and "Makefile.PL" to choose a decidedly loaded example you can't discriminate by entering the capital M, but enter m[tab] -> makefile -> makefile.[tab] if you can see what I mean.) Yep, on further consideration, it's definitely worth it: to get to the cgi directory, for example...

/l[tab]w[tab]c[tab][return]

instead of having to enter three capital letters. I have e e cummings' disease when it comes to entering commands. (And no, he's not from Adelaide either!)

The second and third are linked, and provide a colour coded directory listing in your terminal readout when you enter "lsc" (ie ls"coloured", but call it what you will. Not particularly stunning, but fine and possibly helpful if you don't have too many items in your directories.

The fourth is a command I run every time I connect with my modem. It just logs me on to my old work server using ssh, and tunnels port 2001 locally to port 110 (the pop port) on that machine. So in my email application I enter the server as 127.0.0.1 and the port as 2001, and my pop requests travel in an ssh tunnel to the server instead of my all-too-powerful password being thrown out there in the clear every time I collect my mail, which is a bit of a horrifying thought.

The fifth is almost identical, except that it connects me to a vnc server that's running on another machine, and again tunnels local requests to port 5910 through to port 5901 on the other machine. (vnc servers grab the first open port after 5900, and you need to know which one your server started on to get this right: I basically leave mine running all the time, so tying it down this way doesn't cause any difficulties.) The -C requests that compression should be used on the data travelling in that tunnel, which is worthwhile here because the *amount* of data that vnc must send back and forth is non-trivial.

The final one just calms "top" down. MacOSX and FreeBSD just crank up top with a refresh rate that's way too high for me (every second?), so I just modify the command so that it refreshes every ten seconds instead, and is sorted by cpu usage. Only (slight) downside of this command is due to what I think is a bug in the version of top on OSX: it starts out will all proc's consuming 0.00%, and doesn't give real results until the first refresh. Just hit space to invoke the refresh manually. Actually the top we get is terribly lame compared to the utility on other platforms (and don't mention the way that terminal. app draws the characters at the bottom of the screen: even the "q" that you enter to quit.)

For a short post this is awfully long. Enough...

Paul
-------------------------------

Cheers...

[sao]

When I joined this thread my ~/.cshrc file had only the following :

source /sw/bin/init.csh

Cleaning up other files and now my ~/.cshrc file looks like this:

source /sw/bin/init.csh
date
set prompt="[%{\033[32m%}%n%{\033[0m%}:%{\033[36m%}%/%{\033[0m%}]"
alias l 'ls -Ahl --color=always'
alias lh 'ls -Al --color=always'
alias ls 'ls -A --color=always'
alias m 'more'
alias lo 'logout'
alias top 'top -u -s 10'
set histfile = .history
set savehist = ( 250 merge )
set complete=enhance
fortune

Cheers...

[mervTormel]

c'mon sao, we know that's a fortune -o


okay, so paul convinced you to go back to the monolithic, one size fits none approach.

there are advantages to breaking out certain command types into their own files, such as aliases and the florid completions.

e.g., it's handy to have a tool to add new aliases as they become necessary...

here's a bash function:

# Function which adds an alias to the current shell and to
# the ~/.bash_aliases file.
add-alias ()
{
local name=$1 value="$2"
echo alias $name=\'$value\' >> ~/.bash_aliases
eval alias $name=\'$value\'
alias $name
}

resulting:

$ add-alias foo "argle bargle bliz \`blaz\` blah blah blah"
alias foo='argle bargle bliz `blaz` blah blah blah'

not so much "subjective bickering" as "respectfully submitted for your consideration"

[sao]

Welcome back, MervTormel,

Yes... I confess... it's a -o

Pmccann, has the taste, and it's great to learn from his posts...
Many things cleared up following his advice.
(pshhhh......don't tell him........he doesn't like flattery)

And, you MervTormel, you have the oustanding quality of a "great professor".
Not the kind that makes you sleepy...but that one who "awakes" you to many possibilities and slowly guide you to solve the problems by yourself.

I'm in good hands here.

Thanks for your tip to add aliases.

Can you also make it work for tcsh ?

(Haven't installed bash yet.)

Cheers...

[Titanium Man]

Merv, that's GOLD thanks! Sao, this is a primitive ugly thing I was doing to manually add aliases, but it worked for me.

alias mkalias "pico ~/Library/init/tcsh/aliases.mine"

As I said this isn't near as elegant as Merv's script since it only opens your aliases.mine file when you type

mkalias

and then you have to add the alias yourself, but it's a starting point. Salutations to all!

TiMan

Come to think of it, how about this?

alias mkalias 'echo \!* >> /Users/timan/Library/init/tcsh/aliases.mine'

You would of course substitute your user name for timan and instead of mkalias you call it whatever you want (I know YOU know this, sao, but this *is* the newcomers section). You would add this command to your ~/Library/init/tcsh/aliases.mine file or .cshrc file and when you type this, for example

mkalias "alias ls 'ls-a'"

(that's a single quote followed by a double quote at the end of the line)
and you'll have a new alias for the ls command. Not as pretty as Merv's script, and this might not work for everything, but I'm a newbie so bear with me.

[mervTormel]

thanks, sao. i've been called worse things than pedantic and didactic.

yes, we are all in good company here.

tcsh no habla functions, to my knowledge. and there's a lot of trouble getting quoting right in csh. here's some gnarlyness from UNIX Power Tools about getting quoting right in csh.

## QUOTING RIGHT IN ALIASES:
##
## quote and makealias -- Get quoting right in csh aliases
#
alias quote "/usr/bin/sed -e 's/\\!/\\\\\!/g' \
-e 's/'\\\''/'\\\'\\\\\\\'\\\''/g' \
-e 's/^/'\''/' -e 's/"\$"/'\''/'"
alias makealias "quote | /usr/bin/sed 's/^/alias \!:1 /' \!:2*"

then feed makealias your alias name, and enter its value thusly...

% makealias mycat
cat `ls | sed '1,/!*/d'` | less
^d
alias mycat 'cat `ls | sed '\''1,/\!*/d'\''` | less'
%


hmmm, switching to bash is my very next priority.

[sao]

Thanks, Timan and MervTormel.

I need to study a little more about aliases and tsch.

Now I got things working and organized with tsch.

And I need the courage to start messing up with bash.

Unless I get help in setting up everything again, I plan to wait for a while. (and study)

Found an interesting article about csh and bash:

http://mirrors.gw.com/tcsh-book/csh-whynot

Cheers...

[rusto]

There's nothing like heating up a thread thought long stored away in the cooler...

mervTormel, a few posts up you toss out this function:


# Function which adds an alias to the current shell and to
# the ~/.bash_aliases file.
add-alias ()
{
local name=$1 value="$2"
echo alias $name='$value' >> ~/.bash_aliases
eval alias $name='$value'
alias $name
}


nice! But I'm foggy on where to put the function...in .bashrc? Or in as a standalone file in ~/bin?

[mervTormel]

put it in .bashrc so that it exists in your function stack when you login.

[rusto]

Great, that was my guess...but say I want an alias to take me to /Library/StartupItems, so I clack this in:

add-alias cdsi "cd /Library/StartupItems/"

the function echoes (as expected):

alias cdsi='cd /Library/StartupItems/'

but upon doing cat .bash_aliases it is revealed that the function has actually written:

alias cdsi=$value

I suspect it's a thing with the quotes...or is it?

[mervTormel]

whoops. yeah, heh, it's a thing with the quotes. the ticks need to be backslash-escaped in the echo redirect. but vB needs to see two, dual, redundant, back-to-back backslashes to habla blah blah...

edit2: i should make this clearer. vBullitin, the system that runs this board, needs two backslashes together in the post editor to show one in the thread. hmm, not much clearer, but you'll either figure it out or you won't.

add-alias ()
{
local name=$1 value="$2"
echo alias $name=\\'$value\\' >> ~/.bash_aliases
eval alias $name='$value'
alias $name
}

edit: boy, that was a joyous editing session. i got some weird chars in my post and i think i ripped a hole in the fabric of space. hopefully, this will be complete.

[rusto]

Thanks, but dang those pesky escape characters!

One neat feature of your function is that you don't have to close the current terminal session to use the new aliases.

[bluehz]

Thnx for the informative thread guys - I actually solved my prob via someone recommending this thread. On a related note - in my search for answer I ran across an interesting repository of user-submitted shell files. I posted this to the Hints page the other day - but it never made it in I guess.

http://www.dotfiles.com/

I would be a bit wary of simply grabbing other peoples stuff an instituting it - but it could be a great source to pick up tidbits from.

[Craig R. Arko]

Geez, I just wandered in here. Great work, folks. I am not worthy!

Is it possible to generate a summary of the findings to date? Maybe a book on the subject (I'm sure O'Reilly would be interested)?

[rusto]

One more thing, how do I get .bashrc to look to .bash_aliases? The function we have been fiddling with sets aliases fine for the current shell but no new ones.

btw, found your source (http://www-aix.gsi.de/gnu/bash-2.01/examples/startup-files/Bash_aliases) for the function, merv, and there it looks like this:

# Function which adds an alias to the current shell and to
# the ~/.bash_aliases file.
addalias ()
{
local name=$1 value="$2"
echo alias $name=\\'$value\\' >> ~/.bash_aliases
eval alias $name=\\'$value\\'
alias $name
}

[sao]

Hi all,

Well, now that the old good thread came back to life, it's time to post an update on the subject.

So, for all the tcsh lovers out there...

Here is how my .cshrc file looks today :

source /sw/bin/init.csh
date
set prompt="\! [%{\033[32m%}%n%{\033[0m%} @%{\033[36m%}%/%{\033[0m%}] : "
alias l 'ls -Ahl --color=always'
alias lh 'ls -Al --color=always'
alias ls 'ls -A --color=always'
alias m 'more'
alias top 'top -u -s 10'
set histfile = .history
set savehist = ( 250 merge )
set complete=enhance
alias lo 'logout'
alias fword ' grep -i \!* /usr/share/dict/web2 '
xttitle pm@$cwd
alias cd 'chdir \!*;xttitle pm@$cwd'
alias pushd 'pushd \!*;xttitle pm@$cwd'
alias popd 'popd \!*;xttitle pm@$cwd'
alias back 'cd -'
alias h 'history'
alias psh 'pushd'
alias pop 'popd'
alias md 'mkdir'
alias krm 'rm -i'
alias r 'rehash'
alias cl 'cd \!* ; ls'
fortune

Probably the most interesting thing, besides a couple of new aliases, is that I manage to use xttitle (installed with fink) to display my location in the window title, and it works well with terminal.app, xterm, eterm, aterm, etc. thanks to a great tip from Enri Rothman's web site.

http://compsci.salve.edu/macosx.html

(a lot of good info on this site, and by the way, pmccann, another mathematician working hard on a mac, check it out).

From bash, I think you can change the xterm/aterm/Eterm/rxvt/ title like this:

echo -e "\e]2;This is the title\007"

and in the man console_codes you can see the other variants of window/icon title.

Truth is, I also installed bash and I'm learning the way, slowly. But not yet enough to start posting about it. Maybe next time.


Cheers...

[mervTormel]

Originally posted by rusto
One more thing, how do I get .bashrc to look to .bash_aliases? The function we have been fiddling with sets aliases fine for the current shell but no new ones...

put a call to ~/.bash_aliases in ~/.bashrc ?

if [ -e ~/.bash_aliases ]; then . ~/.bash_aliases; fi # load .bash_aliases

[mervTormel]

okay, my previous reply was a little terse, so i'll flesh it out a little. this is bash specific in odor, but the fragrance applies to other shellage...

~/.bash_profile is automagically called on login by the bash executable, as per the man pages. this file performs the things you want to happen on the inital login session. one of those things is to load the ~./bashrc file.

# ~/.bash_profile

if [ -f ~/.bashrc ]; then . ~/.bashrc ; fi

date
who
biff y
echo "home size: `du -sh ~`"
fortune # -o

~/.bashrc is automagically called on a non-login shells (sub-shells) by the bash executable; this is the file to put things you want in every shell and sub-shell (aliases, functions, env variables). typically, this file won't have any commands that blab any output to stdout.

the file ~/.bash_aliases is not in the bash startup sequence. it's a user-invented file. therefore, it needs to be 'existed' and loaded.

the reason i broke out aliases to their own file was so i could define a reasonable, portable and mostly self-contained add_alias function and not worry about polluting the end of another file or of writing additional aliases beyond a premature exit or return.

since .bashrc is the meat of my shell brains, i have a 'return' at a logical place in my .bashrc and beyond that 'return' are notes and test code that i want to keep, so my .bashrc looks like:

production code
decision making code
calls to other files, like .bash_aliases

return

junk and embarrassing stuff
notes and epithets towards steve balmer
test code and stuff that can't pass for code

so, if i left aliases in .bashrc, they would be appended after junk, notes, and test code and never be executed because of the return command.

i realize this may be confusing; it's harder to explain than experience. a handy tip is to always have several shell windows open when you modify your startup scriptage so you can switch back to the un-tainted to fix things up. and test test test, lest you be unable to login to your shell to fix it.

feel free to ask questions and make suggestions (the non-lurid kind).

[sao]

MervTormel, rusto,

Sorry, just getting in the middle a little bit to finish my post from above.

Of course, if you want to display your location in the window title, without using xttitle, you can do the following:

create a file in your home directory named .settitle with:

alias settitle 'echo -n "^[]2;$cwd^G"'
settitle
alias cd 'cd \!*;settitle'
alias pushd 'pushd \!*;settitle'
alias popd 'popd \!*;settitle'

To type the ^[ characters into the file type ctrl-v followed by the ESC key.
The ^G character by pressing ctrl-v followed by ctrl-g.

After you created .settitle, add the following to your ~/.cshrc file:

source ~/.settitle

Now you should get your location in the window title.

Thank you, let's now continue with the bash education. (By the way MervTormel, what I wrote about bash title in my post above, does it make any sense?)


Cheers...

PS: Bluehz, for tidbits besides http://www.dotfiles.com you can also check http://www.shelldorado.com/shelltips/beginner.html

[bluehz]

Maybe I am missing someting here or its losing something in the text to HTML display translation. I tried the ctr-v followed by.... scenario and I get nothing - or I get the tcsh help facility. Why can I not just use the "^" provided on the keyboard?


To type the ^[ characters into the file type ctrl-v followed by the ESC key.
The ^G character by pressing ctrl-v followed by ctrl-g.

Thx! Checkin it out right now...


PS: Bluehz, for tidbits besides http://www.dotfiles.com you can also check [url]http://www.shelldorado.com/shelltips/beginner.html

ADD: shelldorado is great! Thanx for the turn-on. BYW - did you happen to visit the Tutorials page http://www.shelldorado.com/links/index.html#tutorials it is a HUGE page of links to UNIX related tutorials. Could take a while to digest all this!

[sao]

bluehz,

Best, is to create the .settitle file with vim, I had trouble with pico to type the special characters. Don't miss any characters or it will not work.

Let me know.

Cheers...

PS: Wow, quite a few links to unix tutorials there.

[bluehz]

Yes - I think I figured that out - copy and paste doesn't work in pico. I don't get around very well in VIM, etc. Guess I'm gonna have to start learning....

[sao]

bluehz,

Go for it. Learn a couple of commands in vim and you are done in five minutes. It's not so difficult, I promise. Or, if you still have XFree installed you can call gvim, the GUI version of vim, and there just type, save and quit.

Good luck.

Cheers...

[xchanyazy]

<flamebait>vim is the devil! Use Emacs!</flamebait>

Or xemacs, if you want a gui version.

[sao]

xchanyazy,

Yes, emacs, Xemacs are great. I suggested vim because I found is slighlty easier for a beginner)

By the way, in order to use all of them and not to be concerned about the devil, you need to be....

[stetner]

The main reason I always use vi is because there are not many UNIX boxes that does not have it. At one time I tried using emacs, became quite comfortable with it, but then started cursing when I could not us it on certain machines (it is not installed by default on a lot of machines and has a huge footprint which precludes putting it on others). I then went back to good old vi which works the same every where and exists everywhere!

My opinion of course 8-)

[bluehz]

I d/l, compiled and installed VIM today. Haven't had much chance to mess with it yet. VI just totally confuses me. Its not that I couldn't learn it in a few mins - its just I shouldn't have to spend an inordinate amount of time learning to use a simple text editor. I guess thats why so many people use tcsh - you can normally just poke and peck and get around. More than once I have gotten stuck in VI, can't go back, can't go forward - totally confounding. Obviously I don't know the secret code...ahahahaha....

Giving VIM a good try though....

[mervTormel]

yeah, vi is a bit awkward at first. but stetner is correct. it's recommended to know, at least with a passing familiarity, because it is universally available on unix installs.

there's only a few notions and a handful of key sequences to know to be able to use vi at a minimal level. and get out of messes.

even tho the man pages has a fast start section that covers the minimum, it might be useful to start a vi thread somewhere.

[stetner]

The only "intuitive" interface is the nipple. After that, it's all learned.

(Bruce Ediger, bediger@teal.csn.org, in comp.os.linux.misc, on X interfaces.) That said, vi has two modes, insert and command mode. If you are not sure where you are, hit <ESC> and you are in command mode (two times if you happen to be in a 'raw keystroke entry mode IE have just hit ^V). Then just a ':q' to quit (or ':q!' to quit if the buffer has been changed, or ':wq' to write and quit).
If check out:www.google.com/search?hl=en&q=vi+cheat+sheet (http://) You will see there are a lot of cheat sheets to help you get started.

The two things I like best are key mapping and the search/replace. Key mapping lets you do something like (where ^V is control-V and ^[ is <ESC>::map g 0iStart of Line - ^V^[$aEnd of Line - ^V^[jand changeaaa
bbb
ccc
ddd

To:

Start of Line - aaa - End of Line
Start of Line - bbb - End of Line
Start of Line - ccc - End of Line
Start of Line - ddd - End of Linein 4 key strokes. Basically it maps the single stroke 'g' into the remaining stuff (IE 0 - go to begining of line i - insert 'Start....' the literal text until the <ESC>).

if you had:Fish is good
Beef is good
Fish is good
Beef is good

A search/replace of:
:g/Fish/s/good/bad/

Turns it into:

Fish is bad
Beef is good
Fish is bad
Beef is good(yeah, I know, fish is good for you! 8-)
Anyway, there are a million neat things you can do in vi (from the keyboard) that make it very good for hacking text.

[sao]

stetner,

Thanks for the input and the "nipple" memories. :D

Since Vim 6.1 became available through Fink, and I realized that I could launch gvim as long as I had X11 running, I never looked back.

Although it may look strange as vim has two modes, learning from scratch was fast and easy for me.


Cheers...

[Titanium Man]

Gvim? sao, I tried doing fink list but didn't come up with gvim. Is it unstable still? Wow this post is old. Ok here's my 2 cents: its my ugly ungainly PID getter. It's a Frankenscript that I've thrown together, and while it won't bring about world peace, it was fun researching, and has taught me a lot. In bash, this goes in your .bash_profile, .bashrc, .bash_alias, or in your ear :D:

gpid () { ps ax | grep "$*" | grep -v grep | awk '{ print $1 }' ; }

then you type

gpid Mozilla

and you get the PID for Mozilla. In tcsh, I think it'd be something like:

alias gpid 'ps ax | grep "\!*" | grep -v grep | awk '{ print $1 }''

but I'm not sure, since I haven't been able to to test it. While I'm here, merv (and everyone else), I'm still a little unclear on this .bash_profile vs. .bashrc thing. I understand (I think) that .bashrc is used for non interactive sub process thingies, but is there a need for .bashrc and .bash_profile to be different? Fer example, when I pop open an xterm in Windowmaker, it seems to read from .bashrc, so I'd like all my stuff to be the same as when I'm in Terminal.app. Am I a nut for considering removing .bashrc and replacing it with a symlink to .bash_profile so they'll always be the same and so I don't have to go edit the other when I make changes to the first? Thanks

[sao]

Hi Timan,

If you install VIM - Vi IMproved 6.1, with fink, you also get the GUI version gvim.

system vimrc file: "$VIM/vimrc"
user vimrc file: "$HOME/.vimrc"
user exrc file: "$HOME/.exrc"
system gvimrc file: "$VIM/gvimrc"
user gvimrc file: "$HOME/.gvimrc"
system menu file: "$VIMRUNTIME/menu.vim"
fall-back for $VIM: "/sw/share/vim"

which gvim
sw/bin/gvim

Package vim
In 0.4.0-stable: *** Version 6.0-2
In current-stable: *** Version 6.0-2
In current-unstable: *** Version 6.1-1

Description: ***Improved version of the editor "vi"

VIM adds many of the features that you would expect in an editor: Unlimited undo, syntax coloring, split windows, visual selection, graphical user interface (read: menus, mouse control, scrollbars, text selection), and much much more.


Cheers...

PS: Wow Timan, you started this thread, and still is alive and well.

[Titanium Man]

sao, thanks! I got vim, so now to play with it...(good thing I'm off from work today)

[mervTormel]

Originally posted by Titanium Man
...I'm still a little unclear on this .bash_profile vs. .bashrc thing. I understand (I think) that .bashrc is used for non interactive sub process thingies, but is there a need for .bashrc and .bash_profile to be different? ...Am I a nut for considering removing .bashrc and replacing it with a symlink to .bash_profile so they'll always be the same and so I don't have to go edit the other when I make changes to the first?
HTH

.bash_profile is run under the conditions of a new login. therefore, it is only run once for that shell window (in terminal.app's case). however, .bashrc is run under the conditions of a sub-shell and .bash_profile is skipped in a sub-shell. so, what does that mean?

in .bash_profile, you can run commands that write to stdout. you wouldn't want chatty commands when you start a sub-shell. the PATH variable should be finalized in .bash_profile. this is so that sub-shells don't alter/prepend/append to it. since fink's init sets PATH and exports some variables, run fink's init from .bash_profile. also, run your .bashrc from .bash_profile

.bashrc is the driver for everything else, aliases, functions, completions, prompt-string, env settings, etc. they should be silent settings, i.e., no noise to stdout.

the PS1 string should be set in .bashrc. this is because non-interactive bashes go out of their way to unset PS1.

to see the effect of .bashrc, start a sub-shell like so: $ bash -xv

so, in review, .bash_profile = main driver and chatty on login ; .bashrc = silent creator of your underworld elements.

here's an example .bash_profile that is very verbose; compare this to starting a subshell (i.e., $ bash) :

##
# file: ~/.bash_profile
##

# fix MANPATH for man files in /usr/local/man

export MANPATH=\
"${HOME}/man:/usr/local/man:/usr/local/share/man:/usr/share/man"

# bash path wrangling

export PATH # path has been set somewhere in the bowels of startup

pwrangle () # march thru path elements removing non-existent ones
{
local dlist=$PATH
local p=""
local IFS=": "

for x in $dlist;
do
if [ -d $x ] ; then p=$p:$x ; fi
done

export PATH="${HOME}/bin${p}" ;
}

# why pwrangle here? in case i want to promote my ${HOME}/bin
# to be the first dir in my path, i would move the call to pwrangle
# after the fink init.

pwrangle

# fink init

if [ -f /sw/bin/init.sh ]; then . /sw/bin/init.sh ; fi

# load up the goods

if [ -f ~/.bashrc ]; then . ~/.bashrc ; fi

biff y

# reports - the chatty part

date +"%a %e %b %Y @ %T %Z"
uptime
who
ps a
ps axhum | head -10 # top 10 RAM eaters
vm_stat | grep pageouts
netstat -in
echo "home size: `du -sh ~`"
echo ".-_-.-_-.-_-."
fortune # -o
echo ".-_-.-_-.-_-."
cd

# end: ~/.bash_profile

[Titanium Man]

DING! That was the sound of a lightbulb coming on. The lightbulb over my head. So, .bash_profile is for when logging in, and you can put the "chatty" stuff there, and .bashrc is for other stuff, sub-shells, etc. This is going to be very useful info, merv. Thanks!

[vonleigh]

Hello,

I'm actually interested in just adding a gpid command (for getting pid's). I looked at the example above (for tcsh) that read:

gpid 'ps ax | grep "\!*" | grep -v grep | awk '{ print $1 }''

And it didn't work, any other way of doing it?


Thanks,
Vonleigh

[mervTormel]

tcsh's quoting can become quite onerous. and the forum's editor strips
un-double-quoted backslashes. this should get it...

% alias gpid 'ps wwax | grep "\!*" | grep -v grep | awk '\\''{print $1}'\\'''

be aware of single ticks vs. double quotes; the only thing double quoted
is the "\!*"

also, be aware that you can't rely on this too much for an accurate return.
you have to have high confidence that your search arg is completely unique.

e.g., try:

% gpid ic

you wouldn't want to, say, kill, it's return value

[vonleigh]

Hello,

Thanks MT, you've helped me on too many ocassions already ;)

One last question, is there any way to make it ignore capitalization? for example if i do: gpid omni, or gpid Omniweb, it won't find anything because it's "OmniWeb".


Thanks,
Vonleigh

[mervTormel]

oh, that would be grep -i (gnu's allows --ignore-case)

see the grep man pages, right?

[vonleigh]

Hi mt,

Duh! that's so obvious. For some reason I was thinking of some strange solution like the tip about setting upper to lowercase, something really involved. Never thought to just tell grep to ignore case. I'll read the man pages.


Vonleigh

[Justin Sane]

Its dirt simple and uninspiringly unclever, but to keep track of everything I add the following line to files:

For example in path:
PATH_INIT = `date +%y%m%d-%H%M%S`
In .tcshrc
TCSHRC_INIT = `date +%y%m%d-%H%M%S`

then I know what updates when I run source and can spot any omissions. It also gives me the start order and tells me if anything breaks. Like in 10.2 when Apple stopped calling the init Library files by default.

Like I said not too clever but a little trick that helps me.

[thatch]

When you say, "...in path", do you mean the infamous ~/Library/init/tcsh/path? When I add it there, exit a terminal.app window and open a new one, I get "PATH_INIT: Command not found.", at the top of the window. Same thing if I put the .TCSHRC_INIT = blah, blah into my ~/.tcshrc.

I'm using OS 10.2.1 and tcsh. And I've noticed that the ~/Library/init/tcsh files aren't really working well except for aliases.mine. It seems to work better, for me, to put everything into ~/.tcshrc and ~/.login, except aliases.

It sure would be great if this would work as you mentioned to spot problems in the sourcing and start order though.

[Justin Sane]

I left out the preceding 'setenv' as in:

setenv ENVIRONMENT_MINE `date +%y%m%d-%H%M%S`

Sorry... ;-)

BTW,
I source my files in ~/Library/init from my .tcshrc using:


source ~/Library/init/tcsh/path
source ~/Library/init/tcsh/rc.mine
source ~/Library/init/tcsh/environment.mine


Just remember, *.app applicatins (official AppKit GUI applications ) will not read these files which is why Apple uses the plist i.e. ~/.MacOSX/environment.plist. So set anything you want GUI apps to find in that file. Hope that helps.

[thatch]

Thanks for the clarification. I see what happens when I add the appropriate environment variable to the various files. But I noticed that all the times for them are the same in tcsh from terminal.app, which is a good thing, I suppose.
ENVIRONMENT_MINE=021202-233905
RC_MINE=021202-233905
PATH_MINE=021202-233905
TCSHRC_INIT=021202-233905
PATH_INIT=021202-233905
...But in my xterm via windowmaker, it's another story entirely.
TCSHRC_INIT=021202-234628
ENVIRONMENT_MINE=021202-233905
PATH_INIT=021202-234610
RC_MINE=021202-234628
PATH_MINE=021202-234610
I don't use xterm that much but think it should be the same tcsh environment variables I have set in those various files. I get redundancies in my $INFOPATH and $PATH which may not be that important. And I can't seem to get my ~/.dircolors into xterm unless I add the eval command to my ~/Library/init/tcsh/environments.mine which is called first. But then it breaks terminal.app and its LS_COLORS environment variable.

I will continue to tinker with this in hopes of figuring it out. Any suggestions are most welcome.

[sao]

thatch,

(Don't kill me...) of course you tried in your ~/.tcshrc file:

eval `dircolors ~/.dircolors`


Cheers...

[thatch]

I've had practically no time for tinkering today, just work. But sao, thanks for your reply. Yes, of course that's the command to put into one of the configuration files and I've tried everything and everyplace I can think of. Currently, I'm satisfied with it in my ~/.login at the end which keeps terminal.app happy but not xterm in windowmaker. If I want to use a configuration that works with xterm, placing the command in my ~/Library/init/tcsh/environments.mine does the job but breaks terminal.app.

I'm fairly convinced that jaguar has mixed some old system and new system attributes for environment configuration, the sourcing and all, and that is why some of this strange behavior. But I have faith it will get ironed out in the next OS release.

Best,

thatch

[mnewman]

This has been a most interesting thread and I appreciate the time and effort put into it by the folks who have done the research and who have patiently explained everything.

Tonight I went through and looked at my .login, .xinitrc, .tcshrc and .cshrc files to try and put everything in the right place. After doing so, I find that my path has two copies of:

/usr/X11R6/bin

As far as I can see, it exists only in my .login file.

Where could the second iteration be coming from?

[Titanium Man]

If you have fink installed:

% cat /sw/bin/init.sh | grep PATH | head -1
PATH=/sw/bin:/sw/sbin:$PATH:/usr/X11R6/bin

% cat /sw/bin/init.csh | grep path | head -1
set path = ( /sw/bin /sw/sbin $path /usr/X11R6/bin )

[thatch]

mnewman, try removing /usr/X11R6/bin from your ~/.login while it is being sourced from /sw/bin/init.*.

I used to have a problem with redundancies in my tcsh $path on the X window system. But everything was perfect in terminal.app. And I was able to fix it so I would be good in the X system but not in terminal.app.

Then I switched to zsh for my shell and also combo updated 10.2.1 to 10.2.3. I haven't had those redundancies since but I'm not sure if it was the system update or the switch to zsh that fixed it for me.

I described this all in more detail a few post back from here. And even though I couldn't get it exactly the way I wanted in both environments, everything worked just the same, very well. So, having the redundancies at the end of the path really wasn't so bad.

[mnewman]

Originally posted by thatch
mnewman, try removing /usr/X11R6/bin from your ~/.login while it is being sourced from /sw/bin/init.*.


Oddly, this didn't work. I removed it and still have two /usr/X11R6 in my path.

You're probably right that redundancies don't matter, but I thought it would be an interesting exercise to track it down.

And, Titanium Man, I'm sorry, but I didn't understand your reply to my post. Could you explain, please?

[thatch]

mnewman, sounds like you have the problem I used to have as I mentioned in prior posts. I couldn't figure out where the extra sourcing was coming from. I tried commenting out the sourcing from various user defined files as well as changing the order of their presence but to no avail.

Are you on 10.2.3? And is this redundancy only in xterm or in terminal.app or both? Also, is it with your $PATH and $INFOPATH but not in your $MANPATH? That's how it was for me, and with either/or in xterm or terminal.app.

What TiMan was showing in his post was that you can use cat and grep to find the actual source in those files, /sw/bin/init.sh and /sw/bin/init.csh. In his examples, if you issue the command line, you should get the second line in the output for each. Try it and you will see.cat /sw/bin/init.csh | grep path | head -1
set path = ( /sw/bin /sw/sbin $path /usr/X11R6/bin )

cat /sw/bin/init.sh | grep PATH | head -1
PATH=/sw/bin:/sw/sbin:$PATH:/usr/X11R6/bin

[Titanium Man]

Sorry. What I meant is, if you have fink installed, it adds /usr/X11R6/bin to your path. If you add /usr/X11R6/bin to your path yourself, it will appear twice. Clear as mud? What I illustrated above was where in the fink file (/sw/bin/init.sh or /sw/bin/init.csh) /usr/X11R6/bin gets added to your path. So, if you have fink installed, and you've manually added /usr/X11R6/bin to your path, stop manually adding it, and the redundancy should disappear. Let me know how it turns out.

[mnewman]

OK - Fink is installed and I see how it adds /usr/X11R6/bin.

As far as I know, I've removed all references to /usr/X11R6/bin from any of my customization files. But, I still have two iterations in when I look at the path in xterm, but only one when I look in Terminal.app.

Also, when I start Terminal.app I get this:

"Too many ('s."

Any idea where that's coming from? The only files I've knowingly edited are .xinitrc and .tcshrc

Here they are:

.tcshrc:

source /sw/bin/init.csh
if( ! $?DISPLAY ) then
setenv DISPLAY :0.0
endif
set autolist

.xinitrc:

source /sw/bin/init.sh
/usr/X11R6/bin/quartz-wm

[sao]

mnewman wrote:
Also, when I start Terminal.app I get this:

"Too many ('s."
I think your problem is in your ~/.tcshrc file. There must an extra `\n` which doesn't show on the screen. Delete all what's there and type it again by hand, don't copy/paste.


Cheers...

[mnewman]

Originally posted by sao
I think your problem is in your ~/.tcshrc file. There must an extra `\n` which doesn't show on the screen. Delete all what's there and type it again by hand, don't copy/paste.


Did that. Still get the "too many ('s" line when I start up Terminal.app.

Looked for all these files:

/etc/csh.cshrc
/usr/share/init/tcsh/rc
/usr/share/init/tcsh/environment
~/Library/init/tcsh/environment.mine
/usr/share/init/tcsh/tcsh.defaults
~/Library/init/tcsh/rc.mine
/usr/share/init/tcsh/aliases
~/Library/init/tcsh/aliases.mine
/usr/share/init/tcsh/completions
~/Library/init/tcsh/completions.mine
/etc/csh.login
/usr/share/init/tcsh/login
~/Library/init/tcsh/path
~/Library/init/tcsh/login.mine
~/.tcshrc
(~/.cshrc)
~/.login
~/.history
~/.cshdirs

I don't have any of the "init" directories shown and the only files I have do not mention /usr/X11R6/bin. As far as I can see, the only initialization file I have that mentions /usr/X11R6/bin is the one that belongs to Fink.

Nevertheless, my path has two /usr/X11R6/bin's.

What a mystery....

[mnewman]

Originally posted by thatch
Are you on 10.2.3? And is this redundancy only in xterm or in terminal.app or both? Also, is it with your $PATH and $INFOPATH but not in your $MANPATH? That's how it was for me, and with either/or in xterm or terminal.app.

I'm on 10.2.3.

I don't have $INFOPATH or $MANPATH defined.

The reduncancy only is in xterm, not terminal.app. But, I do have that odd error ("too many 0's") when I start terminal.app.

thanks

[sao]

mnewman wrote:
Did that. Still get the "too many ('s" line when I start up Terminal.app.
I see. Please, do the same as I told you above (delete all and write by hand) to your ~/.cshrc file.


Cheers...

[Titanium Man]

Originally posted by mnewman ...The only files I've knowingly edited are .xinitrc and .tcshrc

Here they are:

.tcshrc:

source /sw/bin/init.csh
if( ! $?DISPLAY ) then
setenv DISPLAY :0.0
endif
set autolist

.xinitrc:

source /sw/bin/init.sh
/usr/X11R6/bin/quartz-wm



You source /sw/bin/init.csh in your tcshrc, and /sw/bin/init.sh in your .xinitrc. That's unnecessary. Comment out "source /sw/bin/init.sh" in .xinitrc so it looks like this:

#source /sw/bin/init.sh

and test.

[thatch]

Originally posted by mnewman
I'm on 10.2.3.

I don't have $INFOPATH or $MANPATH defined.

The reduncancy only is in xterm, not terminal.app. But, I do have that odd error ("too many 0's") when I start terminal.app.

thanks I'm fairly certain you have the same problem I described in above posts. In your xterm, you can type 'env' without the single quotes and see all path info including $MANPATH and $INFOPATH, (infopath is only if you have installed the texinfo system but you should have a manpath). But that's all kind of moot since the problem is probably in $PATH and, if you had it, $INFOPATH.

BTW, I never had a source line in my ~/.xinitrc. Yet, I still had the redundancies from an xterm and not a terminal window. But since it was at the end of the path, I didn't worry about it much.

Your odd error, as you call it, could be from incorrect spacing in some of your lines. You reported, "too many ('s.", originally. And I think that is what you meant when you next reported the similar, "too many 0's", above. Anyway, try adding a space in between the "if" and the "(".

If that doesn't work, check the end of every line and make certain you don't have a space at the end where it shouldn't be. You can do this in a couple of different ways, but as sao suggests, if you retype the whole thing you will get it right being careful about those spaces.

[mnewman]

I got rid of my .xinitrc file.

I still have two iterations of the /usr/X11R6/bin path in my xterm environment.

Here's what the two customization files I have left look like:

Last login: Thu Jan 16 16:26:18 on ttyp2
Welcome to Darwin!
Too many ('s.
[Newmans-iBook:~] mnewman% cat .tcshrc
source /sw/bin/init.csh
if ( ! $?DISPLAY) then
setenv DISPLAY :0.0
endif
set autolist

[Newmans-iBook:~] mnewman% cat .login
## System-wide tcsh login file
#


# Set paths
set path = ( \
. \
~/bin \
/Developer/Tools /Developer/Applications \ /usr/local/bin /usr/bin /bin \
/usr/local/sbin /usr/sbin /sbin
)

[Newmans-iBook:~] mnewman% env
HOME=/Users/mnewman
SHELL=/bin/tcsh
USER=mnewman
LANG=en_US
PATH=/sw/bin:/sw/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin
QDTEXT_ANTIALIASING=1
QDTEXT_MINSIZE=12
__CF_USER_TEXT_ENCODING=0x1F5:0:0
TERM=vt100
TERMCAP=����
TERM_PROGRAM=Apple_Terminal
TERM_PROGRAM_VERSION=81
LOGNAME=mnewman
HOSTTYPE=macintosh
VENDOR=apple
OSTYPE=darwin
MACHTYPE=powerpc
SHLVL=1
PWD=/Users/mnewman
GROUP=staff
HOST=Newmans-iBook.local.
MANPATH=/sw/share/man:/sw/man:/usr/local/share/man:/usr/local/man:/usr/share/man:/usr/X11R6/man
INFOPATH=/sw/share/info:/sw/info:/usr/local/share/info:/usr/local/lib/info:/usr/local/info:/usr/share/info
PERL5LIB=/sw/lib/perl5
DISPLAY=:0.0
[Newmans-iBook:~] mnewman%

I fixed the space between 'if' and '(' by manually retyping the whole file, as suggested.

Thanks for your patience, but I'm still at a loss.

By the way, when I still had the .xinitrc file, but commented out the 'source' statement, that caused the xterm window to draw behind the Mac menu bar, leaving the top of the xterm window hidden. Removing the entire .xinitrc file fixed that.

[thatch]

mnewman, what window manager are you using for the X window system? If it's Apple's X11, I haven't messed with that yet and so I can't comment on that. I just use windowmaker. But if getting rid of your ~/.xinitrc is working for you, I guess that's okay.

Sorry my suggestion with the spaces didn't work for you. I assume you're using a text editor to make the changes, like pico? Please confirm what editor you use.

Could you try leaving out the 'if' line entirely? I don't use it, just the 'setenv Display :0.0'.

I hope the format of your set path area of your ~/.login is more like this:# Set paths
set path = ( \
~/bin \
/usr/local/bin /usr/bin /bin \
/usr/local/sbin /usr/sbin /sbin \
/Developer/Tools /Developer/Applications \
)
The open and close parenthesis should line up perfectly. Also, the escape, ( \ ), characters are only at the end of the visual line but mean to continue on the next line. I don't know for certain if this would make the difference for you but the format should be neater in this way. I suspect that you've copied and pasted bits and pieces of code into your config files, possibly from a browser, which can add spaces and newline, ( \n ), into your code or just make things messy.

You posted your ~/.tcshrc and ~/.login. But what about your ~/.cshrc? Are you still using it? Please post it if you are.

The env that you posted was from terminal.app and not xterm, correct? It shows the paths are perfectly the way you wanted them less the /Developer/Tools and /Developer/Applications, right? Let's see the xterm with that env command which will show your redundancy; (a shorter way would be 'echo $PATH' and then 'echo $MANPATH' and then 'echo $INFOPATH', without the single quotes of course).

[mnewman]

Thatch, I hope I can answer all your questions:

Originally posted by thatch
mnewman, what window manager are you using for the X window system?

I am using Apple's quaartz.wm. It doesn't seem to need an .xinitrc. In fact, if I use one, every x11 application I open is hidden under the Mac menu bar.
I assume you're using a text editor to make the changes, like pico? Please confirm what editor you use.
I am using pico.

~/.login is more like this: <snip>

It turns out the "too many ('s" message came because I was missing an escape on the last line of the set path statement....
You posted your ~/.tcshrc and ~/.login. But what about your ~/.cshrc? Are you still using it? Please post it if you are.

I'm not. I wouldn't know what to put in a .cshrc file that can't go in the .tcshrc file.
The env that you posted was from terminal.app and not xterm, correct?
Correct.
It shows the paths are perfectly the way you wanted them less the /Developer/Tools and /Developer/Applications, right? Let's see the xterm with that env command which will show your redundancy
Here it is:

PWD=/Users/mnewman
QDTEXT_ANTIALIASING=1
USER=mnewman
LANG=en_US
DISPLAY=:0.0
SHLVL=2
SHELL=/bin/tcsh
HOME=/Users/mnewman
PATH=/sw/bin:/sw/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/mnewman:/usr/X11R6/bin:/usr/X11R6/bin
__CF_USER_TEXT_ENCODING=0x1F5:0:0
QDTEXT_MINSIZE=12
_=/usr/X11R6/bin/xterm
TERM=xterm
WINDOWID=4194318
LOGNAME=mnewman
HOSTTYPE=macintosh
VENDOR=apple
OSTYPE=darwin
MACHTYPE=powerpc
GROUP=staff
HOST=Newmans-iBook.local.
MANPATH=/sw/share/man:/sw/man:/usr/local/share/man:/usr/local/man:/usr/share/man:/usr/X11R6/man
INFOPATH=/sw/share/info:/sw/info:/usr/local/share/info:/usr/local/lib/info:/usr/local/info:/usr/share/info
PERL5LIB=/sw/lib/perl5

Thanks again for your help and patience.

[thatch]

mnewman, thanks for answering all the questions. I see now, as you said, that you didn't include an escape near the end of your path. Glad you figured it out. So, now back to the redundancy in the path.

I just have one more suggestion. Move the 'source /sw/bin/init.csh' line to just after your path in ~/.login. Hopefully, that will get rid of the redundancy and include your /Developer/Tools and /Developer/Applications. For me, and this was a while back, it did include all that I needed but didn't fix the extra /usr/X11R6/bin in my path. But I hope it works for you.

I see in your env output that you have SHLVL=2. Are you running the xterm side by side with terminal? I have found that to cause some strange irregularities. I would just test one application at a time, xterm or terminal. And to test changes made in xterm, I usually had to quit XDarwin and launch it again, unlike terminal.app where I could just rehash or exit the window and start a new one again to see the changes. I don't know about Apple's X11 though.

[mnewman]

Originally posted by thatch
I just have one more suggestion. Move the 'source /sw/bin/init.csh' line to just after your path in ~/.login. Hopefully, that will get rid of the redundancy and include your /Developer/Tools and /Developer/Applications.

I made this change and it did remove the redundancy. Do you know why?

I don't think that Apple's X11 is processing my .login file. Take a look at the following. It shows my .login file, my .tcshrc file, the env from xterm and my env from terminal.app. None of the path specified in the .login file is in the xterm environment:


.login:

## System-wide tcsh login file
#


# Set paths
set path = ( \
. \
~/bin \
/Developer/Tools /Developer/Applications \
/usr/local/bin /usr/bin /bin \
/usr/local/sbin /usr/sbin /sbin \
)
source /sw/bin/init.csh

=================================

.tcshrc

if ( ! $?DISPLAY) then
setenv DISPLAY :0.0
endif
set autolist

=================================

env from xterm:


PWD=/Users/mnewman
QDTEXT_ANTIALIASING=1
USER=mnewman
LANG=en_US
DISPLAY=:0.0
SHLVL=2
SHELL=/bin/tcsh
HOME=/Users/mnewman
PATH=/usr/bin:/bin:/usr/sbin:/sbin:/Users/mnewman:/usr/X11R6/bin
__CF_USER_TEXT_ENCODING=0x1F5:0:0
QDTEXT_MINSIZE=12
_=/usr/X11R6/bin/xterm
TERM=xterm
WINDOWID=2097166
LOGNAME=mnewman
HOSTTYPE=macintosh
VENDOR=apple
OSTYPE=darwin
MACHTYPE=powerpc
GROUP=staff
HOST=Newmans-iBook.local.

=================================

env from terminal.app:


HOME=/Users/mnewman
SHELL=/bin/tcsh
USER=mnewman
LANG=en_US
PATH=/sw/bin:/sw/sbin:.:/Users/mnewman/bin:/Developer/Tools:
/Developer/Applications:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:
/usr/sbin:/sbin:/usr/X11R6/bin
QDTEXT_ANTIALIASING=1
QDTEXT_MINSIZE=12
__CF_USER_TEXT_ENCODING=0x1F5:0:0
TERM=vt100
TERMCAP=øˇ◊¿
TERM_PROGRAM=Apple_Terminal
TERM_PROGRAM_VERSION=81
LOGNAME=mnewman
HOSTTYPE=macintosh
VENDOR=apple
OSTYPE=darwin
MACHTYPE=powerpc
SHLVL=1
PWD=/Users/mnewman
GROUP=staff
HOST=Newmans-iBook.local.
DISPLAY=:0.0
MANPATH=/sw/share/man:/sw/man:/usr/local/share/man:
/usr/local/man:/usr/share/man:/usr/X11R6/man
INFOPATH=/sw/share/info:/sw/info:/usr/local/share/info:
/usr/local/lib/info:/usr/local/info:/usr/share/info
PERL5LIB=/sw/lib/perl5


BTW - I do sometimes have both terminal.app and xterm open at the same time. For purposes of gathering the above, I had them open one at a time.

[edit: readability -mt]

[mervTormel]

there are no binary executables in /Developer/Applications so it is specious to have this in the path.

apple's X11 xterm is not a login shell, so it doesn't source login startup items, i.e., ~/.login (tcsh)

[mnewman]

Originally posted by pmccann
Stepping back a little: obviously the whole philosophy behind the Apple arrangement (as explained in Fred Sanchez's README file in /usr/share/init/tcsh)


I've just been re-reading this thread and realize that I don't have a /usr/share/init/ directory.

I wonder why not? Where should it have come from?

[Titanium Man]

Whew, this is an old post. That referred to OS 10.1, so if you're using 10.2 you'll want to check /usr/share/tcsh/examples.

[thatch]

Originally posted by mnewman
I made this change and it did remove the redundancy. Do you know why?The order that the sourcing is called upon makes the difference.
Originally posted by mervTormel
there are no binary executables in /Developer/Applications so it is specious to have this in the path.I agree and also wonder why mnewman wants the developer tools called before /usr/*.
Originally posted by Titanium Man
Whew, this is an old post. That referred to OS 10.1, so if you're using 10.2 you'll want to check /usr/share/tcsh/examples.I thought that was a 'given'. But apparently the thread did need updating for Jaguar.

mnewman,
About those instructions in /usr/share/tcsh/examples/README; the second part of that file is residual from OS 10.1, and so the file is not exactly accurate. You can still utilize the customization part if you want although, other than the aliases.mine, I didn't find those files to always work correctly in Jaguar. The important part is the first part. Once you get those sourcing's made up as instructed, then please check your env and post the results.

[mervTormel]

Originally posted by thatch
...why mnewman wants the developer tools called before /usr/* ...

well, it doesn't really matter as long as you know the binaries are unique. all the binaries in /developer/tools are unique, here, so i don't see a problem.

if a different GetFileInfo were installed in /usr/local/bin , it would never get called with his path config.

there is a modest performance penalty to scan many path elements, but hashing minimizes this.

there are only a few tools in /developer/tools that i ever want to run, and they're symlink'd in ~/bin/ so i don't have more path elements than are necessary.

[thatch]

OIC, that's true enough. It just didn't look the same as what I was used to seeing.

Another thing too.... what about his having the dot (.) directory in his path? Isn't that supposed to be a security risk of some sort?

[mervTormel]

aye. a dot in the path is ill advised. many a trojan horse whinnies thusly. pfbbbbbbbt

well, a few anyhow. it's a known exploit.

[thatch]

mnewman, there's another heads up for you. And thanks to mT for confirming that.

[mnewman]

OK, except for one thing. All looks well now. Here are my .login, .cshrc, .tcshrc and .xinitrc files along with the env from xterm and the env from terminal.app:


login:

# Set paths
set path = ( \
. \
~/bin \
/usr/local/bin /usr/bin /bin \
/usr/local/sbin /usr/sbin /sbin \
/Developer/Tools \
)
==========

.cshrc:

source /sw/bin/init.csh

==========

.tcshrc

if ( ! $?DISPLAY) then
setenv DISPLAY :0.0
endif
set autolist

==========

.xinitrc

exec /usr/X11R6/bin/quartz.wm

==========

xterm env:

PWD=/Users/mnewman
QDTEXT_ANTIALIASING=1
USER=mnewman
LANG=en_US
DISPLAY=:0.0
SHLVL=2
SHELL=/bin/tcsh
HOME=/Users/mnewman
PATH=/usr/bin:/bin:/usr/sbin:/sbin:/Users/mnewman:
/usr/X11R6/bin
__CF_USER_TEXT_ENCODING=0x1F5:0:0
QDTEXT_MINSIZE=12
_=/usr/X11R6/bin/xterm
TERM=xterm
WINDOWID=2097166
LOGNAME=mnewman
HOSTTYPE=macintosh
VENDOR=apple
OSTYPE=darwin
MACHTYPE=powerpc
GROUP=staff

==========

terminal.app env:

HOST=Newmans-iBook.local.
HOME=/Users/mnewman
SHELL=/bin/tcsh
USER=mnewman
LANG=en_US
PATH=.:/Users/mnewman/bin:/usr/local/bin:
/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:
/Developer/Tools
QDTEXT_ANTIALIASING=1
QDTEXT_MINSIZE=12
__CF_USER_TEXT_ENCODING=0x1F5:0:0
TERM=vt100
TERMCAP=øˇ◊¿
TERM_PROGRAM=Apple_Terminal
TERM_PROGRAM_VERSION=81
LOGNAME=mnewman
HOSTTYPE=macintosh
VENDOR=apple
OSTYPE=darwin
MACHTYPE=powerpc
SHLVL=1
PWD=/Users/mnewman
GROUP=staff
HOST=Newmans-iBook.local.
DISPLAY=:0.0


The remaining oddity: if I use that .xinitrc, any x11 applications I start are hidden behind the Mac menu bar. If I use the geometry statement to start them up in a better location, they lose their widgets. What causes this?

[thatch]

mnewman, you can find info on the remaining oddity in the X11 forum. But I don't use Apple's X11 so I don't know the answer, only that I have seen others talk about those same issues there.

But, I noticed a few things from your files:

First off, you don't need a ~/.cshrc. That sourcing you had there was better off at the end of your ~/.login as you had it before.

Secondly, I'm not seeing everything that should be in your path. Which method did you chose from the README instructions, the system-wide? If so, you should have created /etc/csh.cshrc, /etc/csh.login and /etc/csh.logout. And in each of those you should have the proper source line as described.

Thirdly, you should be seeing /sw/bin and /sw/sbin at the beginning of your path and /Developer/Tools and /usr/X11R6/bin at the end of your path in both terminal and xterm.

Lastly, you still need to remove that dot (.) directory line from your path in the ~/.login file. You don't want to have a security risk, right?

[mnewman]

I'm becoming hopelessly confused.

I added the .cshrc because I reread the fink documentation and it said it needed that file with that source statement in it.

I did not decide to use the system-wide customization. The only files I have are .cshrc, .tcshrc, .login and .xinitrc.

I removed the dot directory line from the .login file.

I think the path that is in my .login file does not get appended to the path in xterm because xterm does not open a login shell so the .login file doesn't get processed.

I still can't figure out why windows opened in X11 without a geometry statement are hidden behind the Mac menu bar, but using a geoghraphy statement causes the widgets to get lost.

I also have Apple's X11 and fink installed on an iMac. It does not have the hidden/widgets problem. It is only using a .cshrc file and an .xinitrc file. No .login and no .tcshrc. However, note that it too has the redundant path problem in xterm:

Files on the iMac

.cshrc:

source /sw/bin/init.csh

==============================

.xinitrc

source /sw/bin/init.sh
exec /usr/x11R6/bin/quartz-wm

==============================

xterm env:

PWD=/Users/mnewman
USER=mnewman
LANG=en_US
DISPLAY=:0.0
SHLVL=2
SHELL=/bin/tcsh
HOME=/Users/mnewman
PATH=/sw/bin:/sw/sbin:/usr/bin:/bin:
/usr/sbin:/sbin:/Users/mnewman:
/usr/X11R6/bin:/usr/X11R6/bin
__CF_USER_TEXT_ENCODING=0x1F5:0:0
_=/usr/X11R6/bin/xterm
TERM=xterm
WINDOWID=4194318
LOGNAME=mnewman
HOSTTYPE=macintosh
VENDOR=apple
OSTYPE=darwin
MACHTYPE=powerpc
GROUP=staff
HOST=ChichaiMac.local.
MANPATH=/sw/share/man:/sw/man:
/usr/local/share/man:/usr/local/man:
/usr/share/man:/usr/X11R6/man
INFOPATH=/sw/share/info:/sw/info:
/usr/local/share/info:/usr/local/lib/info:
/usr/local/info:/usr/share/info
PERL5LIB=/sw/lib/perl5

==============================

terminal.app env:

HOME=/Users/mnewman
SHELL=/bin/tcsh
USER=mnewman
LANG=en_US
PATH=/sw/bin:/sw/sbin:/bin:/sbin:/usr/bin:
/usr/sbin:/usr/X11R6/bin
__CF_USER_TEXT_ENCODING=0x1F5:0:0
TERM=vt100
TERMCAP=øˇÿ
TERM_PROGRAM=Apple_Terminal
TERM_PROGRAM_VERSION=81
LOGNAME=mnewman
HOSTTYPE=macintosh
VENDOR=apple
OSTYPE=darwin
MACHTYPE=powerpc
SHLVL=1
PWD=/Users/mnewman
GROUP=staff
HOST=ChichaiMac.local.
MANPATH=/sw/share/man:/sw/man:
/usr/local/share/man:/usr/local/man:
/usr/share/man:/usr/X11R6/man
INFOPATH=/sw/share/info:/sw/info:
/usr/local/share/info:/usr/local/lib/info:
/usr/local/info:/usr/share/info
PERL5LIB=/sw/lib/perl5

[mervTormel]

...xterm does not open a login shell so the .login file doesn't get processed...

correct. xterm is not a login shell, so .login is not sourced.

and you need either .tcshrc or .cshrc, not both. consolidate those.

somewhere, out there, is how to wrangle your startup path based on whether you're a login shell or an xterm. someone may find it soon :D

if [ ima xterm] then;
do
something special about the path because xterm dint source .login where i keep my path wrangled;
done

[mervTormel]

here is some fair treatment of the issue, but i don't like the path wrangling in .blahrc because then the path gets redundant in subshells...

http://www.ee.surrey.ac.uk/FAQ/loginfiles.html

hmm, so, perhaps we need an ifdef include define type dealy.


if [ -z $PATH_SET ] then; do
setenv $PATH_SET=true
setenv $PATH ...;
done

or something like that.

and that will only set the path once no matter how many times you subshell. hmm, is it gonna work for new xterms? test please.

[mnewman]

Originally posted by mervTormel
and you need either .tcshrc or .cshrc, not both. consolidate those.


Done. Thank you MT.

[mnewman]

Originally posted by mervTormel
hmm, so, perhaps we need an ifdef include define type dealy.


if [ -z $PATH_SET ] then; do
setenv $PATH_SET=true
setenv $PATH ...;
done

or something like that.

and that will only set the path once no matter how many times you subshell. hmm, is it gonna work for new xterms? test please.

Let me understand. Right now I'm using the path statement in my .login file. Instead, you want to explicity assign a value to the $PATH variable and note that you have done so by creating boolean environment variable to use as a flag.

I assume all this has to go in the .tcshrc file since xterm won't process the .login file?

Sorry if I'm way off, but I haven't played BSD since the late 80's....

....

Thinking about this a little more. If we're going to use the $PATH_SET variable, don't we have to declare it somwhere and then initialize it? I don't know how to do that in tcsh. I guess it should be done in the .login fiile as that only gets processed once?

[mervTormel]

yep. that's exactly it.

this is one technique. i'm still looking for the definitive webpage that discussed this very thing, and i can't seem to craft the magic google cookie to bubble it up.

my above horrorshow coding is brain damaged. should be more like...

if [ -z $PATH_SET ]; then

# wrangle the path

PATH=blah; export PATH
PATH_SET=true; export PATH_SET

fi

this could be put in it's own file and sourced from .blahrc

right, it needs to happen in the .tcshrc file.

it seems to me that there's an if TERM=xterm kinda thing we need to ask in .tcshrc, too.

consider:

login shells source .login/.profile which should source .blahrc

subshells run .blahrc but already have the env var PATH

xterms run .blahrc and don't get the special path wrangling of a login, therefore, need to test and set it if needed.

grok?

so, in your .blahrc file, source ~/.path and path contains the tests to see if the path env var has been set, and do the right thing then, pfbbt, drive on, i believe.

[mnewman]

Yeah, I grok. But see my additional comments:

Originally posted by mnewman
Thinking about this a little more. If we're going to use the $PATH_SET variable, don't we have to declare it somwhere and then initialize it? I don't know how to do that in tcsh. I guess it should be done in the .login fiile as that only gets processed once?

And, yeah, there is a TERM=xterm in the X11 environment.

[mervTormel]

...If we're going to use the $PATH_SET variable, don't we have to declare it somwhere and then initialize it?...

no, that's the key. check for it's existence, if it don't exist, we need to set the path and init the path_set variable. it's all done in the if [ -z $PATH_SET ] block

[mnewman]

Originally posted by mervTormel
no, that's the key. check for it's existence, if it don't exist, we need to set the path and init the path_set variable. it's all done in the if [ -z $PATH_SET ] block

I tried it and got this:

PATH_SET: Undefined variable. Because the if statement has to look like this:

if [-z $?PATH_SET] then

See this page:

http://www.cit.gu.edu.au/~anthony/info/shell/csh.startup.faq

About half way down the page he talks about dealing with xterm not inheriting the environment from .cshrc and .login.

I want to study it a bit more so we're not reinventing the wheel here.

[mervTormel]

understand that i am in the bash shell here; you may need to craft your if [ foo ] differently, or use the test command...

$ echo $PATH_SET

$ if [ -z $PATH_SET ]; then echo foo; fi
foo

$ env | grep -i path
MANPATH=/sw/share/man:/sw/man:...
INFOPATH=/sw/share/info:/sw/info:...
PATH=/Users/merv/bin:/sw/bin:/sw/sbin:...

[mnewman]

Originally posted by mervTormel
understand that i am in the bash shell here; you may need to craft your if [ foo ] differently, or use the test command...


I'm afraid I'm stuck then, because I don't know the syntax. It's been too long. I looked at the tcsh man pages, but it wasn't clear to me how to structure the if..then..else statement.

This is what I'm trying:


if ( $?PATH_SET ) then
echo 'setting path'
setenv PATH_SET true
setenv PATH :~/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin\
:/usr/sbin:sbin:/Developer/Tools
export PATH
export PATH_SET
else
echo 'path already set'
endif

Even if I explicitly do an unsetenv on PATH_SET, it doesn't work. Maybe I don't know how to test.

Trying it manually in xterm:

[Newmans-iBook:~] mnewman% unsetenv path_set
[Newmans-iBook:~] mnewman% if $?path_set echo 'path is set'
[Newmans-iBook:~] mnewman% setenv path_set true
[Newmans-iBook:~] mnewman% if $?path_set echo 'path is set'
path is set
[Newmans-iBook:~] mnewman% unsetenv path_set
[Newmans-iBook:~] mnewman% source .setpath
path already set

[Titanium Man]

This might make life a little less complex:

xterm -ls

The manpage says:

This option indicates that the shell that is
started in the xterm window will be a login shell
(i.e., the first character of argv[0] will be a
dash, indicating to the shell that it should read
the user's .login or .profile).

[mervTormel]

mnewman, c'mon! variables are case sensitive!

% setenv foo bar

% setenv FOO blatz

% printenv | grep -i foo
foo=bar
FOO=blatz

[mnewman]

Originally posted by Titanium Man
This might make life a little less complex:

xterm -ls



Very interesting and it does work. But, /usr/x11R6 is no longer in the path, so we'll have to add that in the .login script.

[mnewman]

[QUOTE]Originally posted by mervTormel
mnewman, c'mon! variables are case sensitive!
[code]

See what happens when you get old! :confused:

[mervTormel]

Originally posted by mnewman
See what happens when you get old!
yeah, i know!

but you are on the garden path. just need to test and experiment more on the command line to verify your results. then! commit them to a script.

i condemn you! i mean, i commend you to the eternal fires of... hey, dees don't fit?!

i have olds-heimer's dis-ease too. :D

[mnewman]

The problem I'm having now is that tcsh doesn't have an "export" command. I'm having trouble figuring out how to make the PATH_SET variable global.

But, at least the script is working if I set the variable from the command line....

[pmccann]

"setenv" is what you're searching for:

setenv EDITOR /usr/local/bin/vim

for example.

Cheers,
Paul

[mnewman]

Originally posted by pmccann
"setenv" is what you're searching for:


Thank you. I was using this, but it kept failing because of a logic error. (I guess I didn't play "Zoombini's" enough!)

Anyway, here's the code that seems to work. I threw in the test for xterm because I was still getting redundant x11r6 paths in xterm. But, they mysteriously went away.... I left the code there for future use.

If I'd known it was going to take so long to write less than a dozen lines of code, I might not have bothered. At least it kept me busy while the tropical storm messed up my long weekend:

#.setpath
# this file can be sourced by anyhbody who needs to set the path

if ( ! $?PATH_SET ) then

setenv PATH_SET true

if ( "$TERM" == "xterm" ) then
echo ' setting path for xterm'
setenv PATH :~/bin:/usr/local/bin:/usr/bin:/bin:
/usr/local/sbin:/usr/sbin:sbin:/Developer/Tools
:/usr/x11R6/bin
else
echo 'setting path for some other term'
setenv PATH :~/bin:/usr/local/bin:/usr/bin:/bin:
/usr/local/sbin:/usr/sbin:sbin:/Developer/Tools
:/usr/x11R6/bin
endif

else

echo 'path already set'

endif


I've sourced this in my .tcshrc file and it seems to work as expected.

[pmccann]

A couple of quick things: firstly, you should kill that leading colon, which will prevent the ~ from being expanded into your home directory. (That is, I don't think it's working as expected at the moment: try "which exe", where "exe" is in your ~/bin directory: it won't be found.

Secondly, and maybe it's a point of style moreso than one of substance, but if you're going to repeat a long and somewhat ugly string of directories letter for letter then set up a variable to hold it once and once only:

MYPATH=~/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin

and so on, and use it in your calls to "setenv"

setenv PATH $MYPATH

(That way you can change it in a single place rah rah...)

Cheers,
Paul

[mnewman]

Paul,

Thanks for your thoughts. I'll get rid of the leading colon. I think it snuk in there during a copy/paste.

Although the long path is repeated in the version of the code I posted, I originally thought that I would have to have separate paths set for xterm and non-xterm sessions. Now I think this is not the case, so I'll probably remove the terminal test.

That said, your point about style is right on. Even if only used once, this long and ugly string ought to be set in a variable to make the logic of the code easier to follow.

Thanks again.