Что вызывает csh сценарий к иногда не источник/etc/csh.cshrc?
Ваше приложение печатает немного мусора. Вы ничего не можете сделать об этом кроме фиксации приложение.
Посторонние символы могли также быть символами неASCII, распечатанными в неправильной локали, но, учитывая, что мусор сразу происходит после законно выглядящей строки и приложения, кажется, не пытается распечатать неанглийский текст, ошибка приложения наиболее вероятна — вполне возможно это добавляет мусор к строке, потому что некоторый код C пропускает часть, где это должно добавить пустой разделитель в конце строкового буфера.
Если приложение, оказывается, печатает определенные escape-последовательности, это могло бы иметь длительные эффекты. Попробовать tput reset или reset сбрасывать терминал к конфигурации по умолчанию.
Получается, что разница заключается в отсутствующей переменной окружения $HOME. Когда $HOME не определено в окружении, ни один загрузочный файл не исходит от csh или tcsh. Отсутствие переменной $HOME интерпретируется csh точно так же, как если бы ей был задан параметр командной строки -f.
Это имеет смысл при рассмотрении стартовых файлов оболочки ~/.cshrc и ~/.login в домашнем каталоге пользователя. Если $HOME не определено, то эти пользовательские файлы загрузить невозможно. Но csh просто пропускает поиск всех файлов запуска, как общесистемных, так и пользовательских, когда $HOME не определено.
Определение $HOME для любого действительного каталога перед выполнением csh скрипта, будь то настоящий домашний каталог пользователя или даже пустой временный каталог, делает csh исходным кодом /etc/csh. cshrc, как и ожидалось.
Я не нашел никакой документации, объясняющей или описывающей эту возможность, но исходный код как bsd-csh, так и tcsh подтверждает это поведение.
.Убедитесь, что csh действительно работает!
Запустите which csh, чтобы получить местоположение csh.
Выполнитьls -l /path/returned/by/which/csh
В моем случае каким-то образом cshбыло сопоставлено с tcsh.