How can I get csh to source a file and then go interactive?

Question

BRIEF

how do I (1) start a new csh, (2) force it to execute a few commands that are NOT in any .cshrc (although I could arrange for them to be in a non-standard location to be source'ed) and (3) then go interactive?

E.g. is there any way to get csh or tcsh to sue alternate startup files other than those described at http://www.manpagez.com/man/1/tcsh/, which says

I already know about

Startup and shutdown 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) (+). The shell may read /etc/csh.login before instead of after /etc/csh.cshrc, and ~/.login before instead of after ~/.tcshrc or ~/.cshrc and ~/.history, if so compiled; see the version shell variable. (+)

   Non-login  shells read only /etc/csh.cshrc and ~/.tcshrc or ~/.cshrc

DETAIL

I'm a bash user. But I work at a hardware company, where (1) many people are csh users, and (2) many of the CAD tools depend on stuff in the environment, such as the modules system.

Many recipes - e.g. internal wiki pages where people explain how to do things - start off something like

start a new shell or xterm
source /proj/Foo/setup.proj
source ~some_engineer/env/setup-for-this-tool
now run the tool

Oftentimes the environment variables conflict; sometimes I have to delete all of my ~/.* files, ssh in afresh, etc.

I would like to automate many of these. Indeed, I have automated many of these. However, I had to automate them by using expect (actually, Perl CPAN Expect), to fake out being an interactive user.

Along the way, I have my own script clear-env that I often use to start a shell with almost no environment variables. Used thusly:

clear-env -keep HOME -- csh
and then either pipe commands in through expect
or run interactively

This works for automation. But sometimes I really do need to be interactive - but only after I have loaded several lines of long source script names.

I would like to be able to load thes source files, and then fall back to interactive.

E.g. I have tried

clear-env -keep HOME -- csh -c 'source filename' -i
...

or, without my clear-env

csh -c 'source filename' -i
...

hoping that it would execute the -c command and then become interactive. But it only executes the -c command.

I have been able to feed commands to csh via expect in a perl script of my own, that reads my tty, and then pipes the command into the csh via expect. However, then I lose the interactive features of csh.

Is there any better way? Some way of saying "From this point on, I want you to reconnect youir controlling terminal to this other terminal?"

Thanks.

By the way, this would be useful for other shells as well. However, it has been my experience that csh users are the most prone to writing recipes that must be manually executed.

--

Perhaps I am not being clear:

I know about

 exec tcsh -c "source stuff ; exec bash"

and exec csh -c "source stuff ; exec csh"

The situation is that I have already driven the tool, the script, a long way using "interactive" commands via Expect.

Now, after I have done that pseudo-interactive setup, finally I want to return to being truly interactive. Basically, changing the controlling terminal for the shell from the pty that Expect was using, to a real pty.

I have been able to do this by creating a forwarding process.

But I was hoping that I could switch. Or do something like

... long
... sequence
... of expect commands
exec csh -i < /dev/my-pty ...

Answer 1

You were on the right track. You can use expect to do this. The key is the statement interact.

#!/usr/bin/env expect

spawn tcsh

expect {
  > {
    send "cd /some/path/foobar\n"
  }
}
interact

... if > is in your prompt, of course. This is the main problem with using expect, but sometimes you're trapped in a situation with no other way out.

Also, you might want to take steps to not pollute your .history file with scripted commands, but you're probably already aware of that.