[comp.unix.aux] tcsh problem on 2.0.1

ckwang@cs.utexas.edu (Chih-kan Wang) (05/06/91)

I downloaded the compiled tcsh from aux.support.apple.com, put it in /bin,
edited the /etc/shells, set proper access mode (as the root), and chsh to
tcsh (in an ordinary user account). Then when I login again and opened
commandshells, my .login file in home directory didn't get executed. But
if I changed back to csh, everything went back to normal.  Does anybody
have any similar experience?

The configuration is:

	MacIIsi 5/105
	AUX 2.0.1
	patched CommandShell from aux.support.apple.com
		(support VT100 compatible numerical keypad)
	tcsh 5.18 compiled for AUX 2.0

Thanks in advance.

CK

p.s. If I have to recompile it, does anybody know where I can find csh
     source? I got the tcsh source from comp.sources.unix, but it requires
     csh source too.


------------------------------------------------------------------------------
Real-Time Laboratory			512-471-9573 (office-TAY 5.106)
Dept. of Computer Sciences		512-320-0765 (home)
The University of Texas at Austin  ckwang@cs.utexas.edu (Internet)
Austin, TX   78712-1188            {harvard,gatech,uunet}!cs.utexas.edu!ckwang

ron@afsg.apple.com (Ron Flax) (05/07/91)

In article <989@lychee.cs.utexas.edu> ckwang@cs.utexas.edu (Chih-kan Wang) writes:
>I downloaded the compiled tcsh from aux.support.apple.com, put it in /bin,
>edited the /etc/shells, set proper access mode (as the root), and chsh to
>tcsh (in an ordinary user account). Then when I login again and opened
>commandshells, my .login file in home directory didn't get executed. But
>if I changed back to csh, everything went back to normal.  Does anybody
>have any similar experience?
>
>The configuration is:

>	tcsh 5.18 compiled for AUX 2.0

Well for starters you should probably grab version 5.20.02 from
afsg.apple.com at 192.1.34.2.

Here's what is going on.. tcsh determines that it is a "login shell" by
looking at it's own argc and argv upon execution.  

	if (argc==1 && *argv[0] == '-')
		tcsh is a login shell;
	else
		tcsh is NOT a login shell;

If tcsh thinks it's a login shell, it processes /etc/csh.login, .tcshrc,
.login, .cshrc, .logout, and /etc/Logout.  If it's not a login shell
then it only processes .tcshrc and .cshrc.

That said, here's what is happening... /mac/bin/Login calls tcsh as
follows to start your mac environment:

	-tcsh -c /mac/bin/mac32

You can see it sets up *argv[0] ok, but argc=3, not 1.  So it's not
considered a login shell and therefore doesn't process the apropriate
dot files.

Now let's say you login to the Console Emulator screen instead of a
32-bit Macintosh environment.  Here's what /mac/bin/Login does:

	-tcsh

Now both requirements are satisfied, and tcsh thinks it's a login
shell.

To fix things so that tcsh will process your .login file you can trick
the shell by creating a .tcshrc file and placing a line that reads:

	source ~/.login

in that file. This will force tcsh to process your .login file.  You can
even get a little more specific and only have that occur if the tcsh
process is connected to the console.  For instance you could do the
following:

	if ( `/bin/tty` == /dev/console ) source ~/.login

Hope this helps you to understand how tcsh is handling startup files.

--
Ron Flax
ron@afsg.apple.com	
Apple Federal Systems Group

rmtodd@uokmax.ecn.uoknor.edu (Richard Michael Todd) (05/07/91)

ckwang@cs.utexas.edu (Chih-kan Wang) writes:
>I downloaded the compiled tcsh from aux.support.apple.com, put it in /bin,
>edited the /etc/shells, set proper access mode (as the root), and chsh to
>tcsh (in an ordinary user account). Then when I login again and opened
>commandshells, my .login file in home directory didn't get executed. But
>if I changed back to csh, everything went back to normal.  Does anybody
>have any similar experience?

Yeah.  CommandShell won't have the .login or equivalent automatically executed
unless your shell is /bin/sh or /bin/csh.  It checks specifically for those
two shells.  (Hmm--wonder if it works correctly with ksh?)  
The workaround I use is to log in in the "normal Unix" way (the Console 
Emulator), so that all the appropriate setenvs, etc. in .login get executed,
and then start up the Mac environment by hand with the "mac32" or "mac24"
command.  This has the additional advantage that when the MacOS environment
crashes (and sooner or later you *will* find a program that takes it down,
reliability of software for MacOS being what it is...) you don't have to 
re-login again, but can just re-issue the "mac32" command.  

>	tcsh 5.18 compiled for AUX 2.0
I believe the current version is 5.20.  

>p.s. If I have to recompile it, does anybody know where I can find csh
>     source? I got the tcsh source from comp.sources.unix, but it requires
>     csh source too.

Unless you're a University that already has a BSD source licence, you can't.
Such is the joy of AT&T-licenced code.  Pray for a csh rewrite in BSD4.4
that'll be free of AT&T code....
-- 
Richard Todd   rmtodd@chinet.chi.il.us  or  rmtodd@uokmax.ecn.uoknor.edu  

wrwalke@rsi.UUCP (William Walker) (05/08/91)

In article <567@afsg.apple.com>, ron@afsg.apple.com (Ron Flax) writes:
> In article <989@lychee.cs.utexas.edu> ckwang@cs.utexas.edu (Chih-kan Wang) writes:
> >I downloaded the compiled tcsh from aux.support.apple.com, put it in /bin,

<stuff deleted>

> > my .login file in home directory didn't get executed. But
> >if I changed back to csh, everything went back to normal.  Does anybody
> >have any similar experience?
> >
> >The configuration is:
> 
> >	tcsh 5.18 compiled for AUX 2.0
> 
> Well for starters you should probably grab version 5.20.02 from
> afsg.apple.com at 192.1.34.2.


as of 5.18 (at least), .login was a compile time option.


> To fix things so that tcsh will process your .login file you can trick
> the shell by creating a .tcshrc file and placing a line that reads:
> 
> 	source ~/.login

be careful here, if you are doing any stty's in your .login, 
running some things like pagers through a fork/exec'd shell
will give "stty: not a typewriter" messages.

bill.


-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Bill Walker  -  Overlord of Gateway Traffic, Keeper of all that is PD,
		Maintainer of the Almighty Source Tree, Worshipper of K+R, 
		Altar-boy at the Temple of "Bob", Resource in Residence,
		Patcher of Perl, Configurer of the Holy Sendmail...
wrwalke@rsi.prc.com  --  PRC, a wholly owned subsidiary of Black+Decker Inc.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

ckwang@cs.utexas.edu (Chih-kan Wang) (05/11/91)

In article <989@lychee.cs.utexas.edu>, ckwang@cs.utexas.edu (Chih-kan Wang) writes:
> I downloaded the compiled tcsh from aux.support.apple.com, put it in /bin,
> edited the /etc/shells, set proper access mode (as the root), and chsh to
> tcsh (in an ordinary user account). Then when I login again and opened
> commandshells, my .login file in home directory didn't get executed. But
> if I changed back to csh, everything went back to normal.  Does anybody
> have any similar experience?
> .....

Thanks to everyone that replied or sent me email on this topic. After some
experiment on the suggestions you gave me, I decide to use Ron Flax's
method. He suggests putting the following two lines in .tcshrc

	if ( `/bin/tty` == /dev/console ) source ~/.login
	source ~/.cshrc

The second line is necessary if you have .cshrc file because tcsh does not
execute .cshrc automatically if it finds a .tcshrc.

---
CK