5

I am running CentOS 7, and I am having problems with tcsh scripts.

I have a simple script called quittest.

#!/bin/tcsh
echo "Simple Test"
exit 0

When I run quittest from the terminal, I get

"Simple Test"

And it does not exit. I can Control+C to exit. I check on the status of this with:

ps aux

and it shows quittest with a state of S+ (foreground interruptible sleep). If I change this script to bash, or sh, it runs fine, and exits as expected.

I cannot just switch to another shell, because my users have very complex scripts written with tcsh. We are replacing OpenSuSE 12.3 with CentOS 7.

Tcsh version 6.18.01-7. SELinux is set to permissive for testing this issue.

Jared
  • 76
  • 8
  • is this something that will be fixed by `dos2unix quittest`? Else. .... "it works for me" with ver tcsh 6.07.02, and I too would fully expect this to work. There is likely some other problem. May add an extra `\n` at the end of the file? And maybe check on CentOS forums to see if others have had this problem and there is a patch available. Good luck!! – shellter Feb 29 '16 at 20:51
  • I tried updating to the latest package for tcsh. It went from 6.18.01-7 to 6.18.01-8. This showed no improvement. I could not find anything in the CentOS forums particular to this issue (I checked there before posting here). There are bug reports that are seemingly unrelated to my issue. – Jared Mar 01 '16 at 12:33
  • try `cat -vet quittest`. Do you see `^M`s at the end-of=lines? If so, then `dos2unix quittest`. Otherwise, I'm out of ideas (at the present). Good luck! – shellter Mar 01 '16 at 12:51
  • There are $ at the end of each line with the command you listed. This is some wonky behavior. My older tcsh shell (6.17.02) have no problems like this. I will keep investigating... – Jared Mar 01 '16 at 13:21
  • sorry, should have said, `$` and `^I`s are expected from `cat -vet`. As you don't see `^M`s then it's possible there is something in the `~/.tcshrc` or other startup files (I don't remember all of them anymore, ) that has set a flag for weird behavior. Chk `man tcsh` and hope there is a `startup` section. There may be an `/etc/tcshrc` (or similar) that could be different between base installs of your 2 OSs. Ah, and SELinux, no telling what that is adding to the mix. But it's really hard to imagine a shell "feature" that would cause this. **Can anyone else reproduce this problem?** Good luck. – shellter Mar 01 '16 at 13:43
  • We use ~/.cshrc files for setting up the environments on our systems. I commented out everything in the .cshrc file for my account, logged out and back in (verified it registered with "echo $PATH"), and it is still misbehaving. I checked with one of my new users (less older .files) and the script runs as it should. This appears to be a conflict with something in my directory. I will start moving files out until I find the culprit. – Jared Mar 01 '16 at 15:16

2 Answers2

1

Turns out, my ~/.history file was the issue. I deleted that and the script ran as intended. Must have gotten hung up with a permissions issue at some point.

Jared
  • 76
  • 8
  • LOL, Who would have guessed. Glad you found it. If you want to convert tcsh to bash/ksh, I'm available for contract work ;-) Good luck ! – shellter Mar 01 '16 at 15:50
  • I had this same problem on CentOS6, it started randomly, no clue how it got messed up but this sounds similar to [this bug report](https://bugzilla.redhat.com/show_bug.cgi?id=885901) for RedHat which I found. Maybe its related? Our server storage location is indeed on a network location, as mentioned in that report. Removing my `~/.history` as per this answer seems to have fixed the issue. – user5359531 May 03 '17 at 17:42
1

I had the same problem on all my Fedora 23, tcsh version 6.19.00-3.fc23.
Reason was ~/.history.lock file. Removing lock file resolved this issue.

perLHawk
  • 90
  • 7