Description of problem:

If the SHELL environment variable is not set, perl -Mlocal::lib is fooled into emitting bourne shell syntax instead of csh syntax. This can cause error messages (possibly invisible if running in a cron job or similar). And it will interrupt the process of reading other .csh files in /etc/profile.d (.csh files that would have been sourced after perl-homedir.csh do not get sourced and the user's ~/.cshrc file can also not be sourced).

Version-Release number of selected component (if applicable):

1.008010-4

How reproducible:

100%

Steps to Reproduce:
1. install perl-homedir package
2. ( unsetenv SHELL; csh )    OR   run csh commands or csh script from crontab or similar

Actual results:

(a) you may see error messages like the following:
Bad : modifier in $ '+'.

 This is due to local::lib emitting things like: PATH="/home/foo/perl5/bin${PATH:+:${PATH}}"
 You can see this with: (unsetenv SHELL; perl -Mlocal::lib)

(b) If you were depending on something to be sourced in some /etc/profile.d/*.csh file or your ~/.cshr or ~/.tcshrc file, it may not get executed due to syntax errors trying to execute bourne shell syntax.  Try adding 'setenv FOO bar' at the end of your ~/.cshrc, then run (unsetenv SHELL FOO; csh).  In the subshell, the FOO env var will not be set if a bourne shell syntax command triggers a syntax error for csh.

Expected results:

perl-homedir.csh should not cause csh syntax errors, of course.


Additional info:


Here is a possible patch:

--- perl-homedir.csh.orig       2022-08-29 20:00:35.367799797 +0000
+++ perl-homedir.csh    2022-08-29 20:05:18.326112310 +0000
@@ -11,10 +11,10 @@ if (-f "$HOME/.perl-homedir") then
        eval `sed -ne 's|^[[:blank:]]*\([^#=]\{1,\}\)=\([^=]*\)|setenv \1 \2;|p' "$HOME/.perl-homedir"`
 endif
 
-alias perlll 'eval "`perl -Mlocal::lib`"'
+alias perlll 'eval "`env SHELL=csh perl -Mlocal::lib`"'
 
 # if system default
 if ("x$PERL_HOMEDIR" == "x1") then
-       eval "`perl -Mlocal::lib`"
+       eval "`env SHELL=csh perl -Mlocal::lib`"
 endif