How can I get csh for a file source and then go online?

Question

Brief

how can I (1) start a new csh, (2) get it to execute several commands that are NOT in any .cshrc (although I could arrange for them to be in a non-standard location to be the source) ed) and (3 ), then go online?

eg. is there any way to get csh or tcsh to sue alternative launch files other than those described in http://www.manpagez.com/man/1/tcsh/ which says

I already know about

Commissioning and shutdown The login shell starts by executing commands from the system files /etc/csh.cshrc and /etc/csh.login. Then it executes commands from files in the user's home directory: first ~ / .tcshrc (+) or, if ~ / .tcshrc is not found, ~ / .cshrc, then ~ / .history (or histfile value), then ~ / .login and finally ~ / .cshdirs (or the value of the dirsfile shell variable) (+). The shell can read /etc/csh.login earlier than after /etc/csh.cshrc, and ~ / .login before instead of ~ / .tcshrc or ~ / .cshrc and ~ / .history if this is so compiled; see version shell variable. (+)

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

DETAIL

I am a bash user. But I work for a hardware company where (1) many people are csh users, and (2) many of the CAD tools depend on material in the environment, such as a module system.

Many recipes, for example. internal wiki pages where people explain how to do things - start 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 

Environmental variables often conflict; sometimes I have to delete all my files ~ /.*, ssh again, etc.

I would like to automate many of them. Indeed, I have automated many of them. However, I had to automate them using wait (in fact, Perl CPAN Expect) in order to fake myself as an interactive user.

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

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

This works for automation. But sometimes I really need to be interactive, but only after I have loaded a few lines with long script names.

I would like to be able to download the source files and then return to the interactive ones.

eg. I tried

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

or, without my explicit env

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

hoping that he executes the -c command and then becomes interactive. But it only executes the -c command.

I managed to pass commands to csh, waiting in a perl script of my own, which reads my tty, and then passes the command to csh via expect. However, I am losing the interactive features of csh.

Is there a better way? Some way to say: "From now on, I want you to reconnect your control terminal to this other terminal?"

Thanks.

By the way, this would be useful for other shells. However, my experience shows that csh users are most likely to write recipes that need to be done manually.

-

Perhaps I do not understand:

I know about

  exec tcsh -c "source stuff ; exec bash" 

and exec csh -c "source material, exec csh"

The situation is that I already ran the tool, script, a long way, using "interactive" commands through Expect.

Now, after I made this pseudo-interactive setup, I finally want to get back to being truly interactive. Basically, the control terminal change for the shell from pty that Expect used is in real pty.

I was able to do this by creating a forwarding process.

But I was hoping 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 for this. The key is the interact operator.

 #!/usr/bin/env expect spawn tcsh expect { > { send "cd /some/path/foobar\n" } } interact 

... if > at your invitation, of course. This is the main problem with using expect , but sometimes you get into a situation without any other way out.

In addition, you can take steps to not contaminate your .history file with script commands, but you probably already know about it.

Answer 2

I had the same problem. I use bash and have a software package that only works if you are on the csh command line and set up a file called nemo_start . This solution:

 me@machine :~/nemo$ csh -c "source nemo_start; csh" # This is bash. FALCON set to /home/me/nemo/usr/dehnen/falcON machine:~/nemo% tsf # This is csh already. Insufficient parameters, try 'help=', 'help=?' or 'help=h' or 'man tsf', Usage: tsf in=??? ... type contents of a (binary) structured file 

This tsf command tsf not be available if the file was not received correctly and the environment variables and aliases were saved.

Answer 3

I managed to do this by installing $ HOME in another directory and putting .cshrc in a new $ HOME that does what you want, then sets $ HOME back to ~ $ USER and manually sources $ HOME / .cshrc .

It feels terribly unpleasant, but seems to work. Beware of other dotfiles, such as .history , that may be broken down depending on the startup sequence in the shell, but it's an idea to investigate if you are desperate and want to avoid using the expect .

I started using this to share my own .cshrc user when logging into a shared test account using something like this:

 xterm -e "setenv HOME ~spickup; exec csh -l" & 

(Of course, in this case you need open permissions between accounts, so do not do this on a secure system.)

Similar principles can supposedly be applied to bash or other shells.

Answer 4

This may not solve your problem, but if your goal is to automate the "source", you can put it in an alias:

~ / .aliases

 alias mysource 'source /path/to/source/file.rc' 

Answer 5

 exec tcsh -c "source stuff ; exec bash" 

If the source material needs to be replaced by a shell (csh) script, this leaves you in the bash shell, which inherits the environment created in tcsh, by the source material. "Exec" means that you are not entering the processes of a nested shell.