rpms / perl-local-lib

Clone
Source Code
GIT

#2 Ensure csh syntax is used for C shell even if SHELL env var is unset.
Merged 6 months ago by jplesnik. Opened 6 months ago by jhein.
rpms/ jhein/perl-local-lib rawhide  into  rawhide

file modified
+2 -2 
@@ -11,10 +11,10 @@ 
 

  	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

We know we're running from C shell in perl-homedir.csh, so be
explicit rather than letting local::lib guess.

If the SHELL environment variable is not set, perl -Mlocal::lib is
fooled into emitting bourne shell syntax (e.g., export FOO=bar)
instead of csh syntax (setenv FOO bar). This can be fatal to the
C shell possibly interrupting execution of a script before the
script has completed.

This (no SHELL variable set) can happen, for instance, when running a
cron job.

See also:
https://bugzilla.redhat.com/show_bug.cgi?id=2122359
https://issues.redhat.com/browse/RHEL-5545

Signed-off-by: John Hein c0eh3p702@sneakemail.com

Pull-Request has been merged by jplesnik
6 months ago

Just a nit pick: If SHELL is not set, Perl local::lib is not fooled into sh syntax. It's a documented feature:

  • Rather basic shell detection. Right now anything with csh in its
    name is assumed to be a C shell or something compatible, and
    everything else is assumed to be Bourne, except on Win32 systems. If
    the "SHELL" environment variable is not set, a Bourne-compatible
    shell is assumed.

But I agree that your fix is appropriate.

Just a nit pick: If SHELL is not set, Perl local::lib is not fooled into sh syntax. It's a documented feature:

Maybe 'fooled' isn't the best characterization given what the README says, but given that the function is "guess_shelltype", one might think it's trying harder than "guess based entirely on what the SHELL environment var has explicitly been set to" - that's not a very heroic attempt at guessing.

I hope the "Fedora CI - installability" failure is not a show stopper. I don't the the AVC failure has anything to do with the patch. Seems like some sort of CI configuration problem??

How does this change get into the queue for current versions of EPEL & Fedora?

I feel like this is documented somewhere, but I could not find it - apologies for the ill-informed question.

The AVC failure is tracked at https://pagure.io/fedora-ci/general/issue/447. It won't block perl-local-lib because it does not enforce fedora-ci.koji-build.installability.functional test https://src.fedoraproject.org/rpms/perl-local-lib/raw/rawhide/f/gating.yaml.

This change will get info Fedora when a maintainer of this package builds it. A Fedora version after another. If this package is distributed in EPEL, then likewise. If it is distributed in RHEL, you need to go to Red Hat support and ask them to include this change.
Metadata
None
No Tags
Changes Summary 1
+2 -2
file changed
perl-homedir.csh
Powered by Pagure 5.13.3
Documentation • File an Issue • About this Instance • SSH Hostkey/Fingerprint
© Red Hat, Inc. and others.