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`"'

1. if system default
   if ("x$PERL_HOMEDIR" == "x1") then

• eval "`perl -Mlocal::lib`"
  + eval "`env SHELL=csh perl -Mlocal::lib`"
  endif