[Bug 1033018] New: syntax error in /etc/profile.d/perl-homedir.csh (perl-local-lib/perl-homedir)
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1033018
Bug ID: 1033018
Summary: syntax error in /etc/profile.d/perl-homedir.csh
(perl-local-lib/perl-homedir)
Product: Fedora
Version: rawhide
Component: perl-local-lib
Severity: low
Priority: high
Assignee: iarnell(a)gmail.com
Reporter: ppisar(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: iarnell(a)gmail.com, jkachuck(a)redhat.com,
mmaslano(a)redhat.com,
perl-devel(a)lists.fedoraproject.org, ppisar(a)redhat.com,
wgomerin(a)redhat.com
External Bug ID: CPAN 85667
+++ This bug was initially created as a clone of Bug #1032195 +++
Syntax error in /etc/profile.d/perl-homedir.csh
---Steps to Reproduce---
* Install perl-homedir
* Create a user with csh as login shell
* login with that user
The file /etc/profile.d/perl-homedir.csh, contained in perl-homedir,
contains a syntax error.
The command "eval `perl -Mlocal::lib`" fails with "Bad : modifier in $ (/).".
The processing of any login scripts stops at that error, resulting in an
incomplete environment for the user.
Fyi ...
.... looks like this is caused by missing {}:
ls3814:db2lin 8> perl -Mlocal::lib
setenv PERL_LOCAL_LIB_ROOT "$PERL_LOCAL_LIB_ROOT:/db2/db2lin/perl5";
setenv PERL_MB_OPT "--install_base /db2/db2lin/perl5";
setenv PERL_MM_OPT "INSTALL_BASE=/db2/db2lin/perl5";
setenv PERL5LIB "/db2/db2lin/perl5/lib/perl5:$PERL5LIB";
setenv PATH "/db2/db2lin/perl5/bin:$PATH";
ls3814:db2lin 9> setenv PERL_LOCAL_LIB_ROOT
"$PERL_LOCAL_LIB_ROOT:/db2/db2lin/perl5";
Bad : modifier in $ (/).
ls3814:db2lin 10> setenv PERL_LOCAL_LIB_ROOT
"${PERL_LOCAL_LIB_ROOT}:/db2/db2lin/perl5" ;
# no error
[...]
--- Additional comment from Petr Pisar on 2013-11-20 14:22:15 GMT ---
Thank your for this bug report and a suggestion how to fix. Unfortunately, this
is not enough.
If PERL_LOCAL_LIB_ROOT is not set, then tcsh will bail out with undefined
variable and the variable will not get set:
[test@rhel-7-0 ~]$ echo ${?PERL_LOCAL_LIB_ROOT}
0
[test@rhel-7-0 ~]$ setenv PERL_LOCAL_LIB_ROOT
"${PERL_LOCAL_LIB_ROOT}:/home/test/perl5" ;
PERL_LOCAL_LIB_ROOT: Undefined variable.
[test@rhel-7-0 ~]$ echo $?
1
[test@rhel-7-0 ~]$ echo ${?PERL_LOCAL_LIB_ROOT}
0
This is a know issue to the upstream
<https://rt.cpan.org/Public/Bug/Display.html?id=85667> with no ratified
solution yet.
--- Additional comment from Petr Pisar on 2013-11-21 10:50:37 GMT ---
Due to CSH limits on subcommand substitution and parsing if-then-else
statemens, appending to a variable FOO can be achieved this way:
test 1 == ${?FOO} && setenv FOO "a:${FOO}" || setenv FOO "a";
----
All Fedoras are affected.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=jn9WnmhloX&a=cc_unsubscribe
9 years, 10 months
[Bug 1026763] New: Locale::Maketext interpolating escaped backslashes improperly
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1026763
Bug ID: 1026763
Summary: Locale::Maketext interpolating escaped backslashes
improperly
Product: Fedora
Version: 18
Component: perl-Locale-Maketext
Assignee: ppisar(a)redhat.com
Reporter: ppisar(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: eggled(a)gmail.com, perl-devel(a)lists.fedoraproject.org,
ppisar(a)redhat.com, psabata(a)redhat.com
External Bug ID: CPAN 120457
+++ This bug was initially created as a clone of Bug #1025906 +++
Description of problem:
When a literal backslash is in an L10N value, it is treated nonuniformly by the
Locale::Maketext::_compile method, as patched by RH in Locale::Maketext::Guts
(per https://bugzilla.redhat.com/show_bug.cgi?id=884354). The result depends
on unrelated parts of the string.
[...]
How reproducible:
Always
Steps to Reproduce:
1. Create a language token, whose value is 'Some data\n'
2. Query the language token through Locale::Maketext ($lh->maketext($tag))
Actual results:
'Some data\\n'
Expected results:
'Some data\n'
Additional info:
The behavior changes in the following cases:
1) If the value contains a tokenized field, behavior depends on whether there
is a trailing newline:
'[_1]Some data\n' => 'Some data\n'
'[_1]Some data\n'."\n" => 'Some data\\n
'
2) If the escaped backslash is in a function call, it behaves as expected:
'Some data[sprintf,\n]' => 'Some data\n'
NOTE: All of these cases in standard perl (with Locale::Maketext v 1.13 from
CPAN) behave exactly the same as each other, and they all produce just a single
'\' before the 'n'.
--- Additional comment from Petr Pisar on 2013-11-04 12:16:19 GMT ---
The 'Some data\n' is due to back-porting the fix to perl 5.10.1.
The parameterized case behaves for me differently and is caused by the changes
in the fix. Even latest Locale::Maketext is affected.
----
All Fedoras are affected.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=BtlUasPZ1z&a=cc_unsubscribe
9 years, 10 months