I recently upgraded Strawberry Perl from version 5.14.1.1-32bit to 5.24.0-64bit on my PC running Windows 7. I have a perl script I run under both Windows and Linux, and when I was using the old version the command
use if $^O eq 'MSWin32' , 'Win32::Console::ANSI';
worked, but now that I've upgraded I get the error message
Unrecognized character \x0F; marked by <-- HERE after use if $<-- HERE near column9 at p:\bin\abc.pl line 31.
Does anyone know what changed, and how I can get the new version of Strawberry Perl to accept the command? Thanks in advance to all who respond.
Your code contains the Shift In control character (0x0F), also known as "Control-O", instead of the characters ^ and O. This works in older versions of Perl but was deprecated in version 5.20.0:
Literal control characters in variable names
This deprecation affects things like $\cT, where \cT is a literal control (such as a NAK or NEGATIVE ACKNOWLEDGE character) in the source code. Surprisingly, it appears that originally this was intended as the canonical way of accessing variables like $^T, with the caret form only being added as an alternative.
The literal control form is being deprecated for two main reasons. It has what are likely unfixable bugs, such as $\cI not working as an alias for $^I, and their usage not being portable to non-ASCII platforms: While $^T will work everywhere, \cT is whitespace in EBCDIC. [perl #119123]
As of 5.24.0, using a variable name containing non-graphical ASCII control characters results in a syntax error.
Related
here are the relevant code lines for a unicode/pyside related problem :
#!/usr/bin/env python
# coding=utf-8
...
msgBox = QtGui.QMessageBox()
msgBox.setText('é')
print 'é'
....
The print does what it should, implying my locale is utf-8, and printenv confirms it. On the other hand, the msgBox shows 'é', unless I prefix the string with 'u'. Is that normal, and do I really have to prefix every string with u in order to use Pyside, when python never raises a problem?
Thanks for your attention.
In Python 2.X there are two data types for strings: byte code and unicode. With u you choose unicode with nothing you choose byte code. If you print bytes('é') you see where PySide/PyQt get their data from. So it probably is normal.
The easy way out is using Python 3.X which just has unicode and won't bother you with the difference.
Not sure who is actually doing something that shouldn't be done, the print function Python 2.X or PySide/PyQt for Python 2.X, so I make it community wiki.
require 5.00503;
The above perl statement demans the version 5.00503. I'm curious to know what would happen if the above statement is not included in a perl program.
If the version you specified is greater than the version of the Perl interpreter, an exception is raised.
So it's necessary when you use some features of Perl that demands the interpreter version greater than a certain version.
From perldoc:require:
VERSION may be either a numeric argument such as 5.006, which will be compared to $] , or a literal of the form v5.6.1, which will be compared to $^V (aka $PERL_VERSION). An exception is raised if VERSION is greater than the version of the current Perl interpreter. Compare with use, which can do a similar check at compile time.
In Perl, you call modules using :: as path separator. So, if you have a module on site/lib/GD/Image.pm, you call use GD::Image.
However, long time ago I found out that you can also call use GD'Image and things like my $img = new GD'Image;, and there are also modules on CPAN using that syntax on ther names/documentation.
What is the purpose or logic behind that? Is it maybe, as many things in Perl, just a feature intended to humanize sentences and allow you to create and use modules like Acme::Don't?
Does it have any other intention different to ::?
See perlmod for explanation:
The old package delimiter was a single quote, but double colon is now the preferred delimiter
So, the reason is history.
The single quote is an old ADA separator. However, it didn't play well with Emacs, so the double colon became used.
Good God! ADA? Emacs? I am old.
Here is what I have:
use Term::ANSIColor;
print "Blah!".color("green");
The output is
Test←[32m
What am I missing?
The terminal program you are using does not support the ECMA-48 color escape codes. So it does not give them any special treatment, and instead outputs the characters as-is.
What you are missing: a terminal that does. xterm, libvte, putty, are just a few to name that do.
Are you on Windows? I'm fairly certain that the Windows shell isn't compliant with the color codes used by the module.
Actually, it says so right there on the module's documentation.
Note that not all displays are ISO 6429-compliant, or even X3.64-compliant (or are even attempting to be so). This module will not work as expected on displays that do not honor these escape sequences, such as cmd.exe, 4nt.exe, and command.com under either Windows NT or Windows 2000. They may just be ignored, or they may display as an ESC character followed by some apparent garbage.
EDIT:
An addendum to my comment:
C:\>perl -MWin32::Console::ANSI -MTerm::ANSIColor -e "print color(\"green\"), 'test', color(\"reset\");"
Works just fine on Windows XP, Perl 5.12.1, so there's your workaround.
Note below how ã changes to a. NOTE2: Before you blame this on CMD.EXE and Windows pipe weirdness, see Experiment 2 below which gets a similar problem using File::Find.
The particular problem I'm trying to fix involves working with image files stored on a local drive, and manipulating the file names which may contain foreign characters. The two experiments shown below are intermediate debugging steps.
The ã character is common in latin languages. e.g. http://pt.wikipedia.org/wiki/Cão
Experiment 1
Look closely, note how cão becomes cao.
Experiment 2
Here I tried using File::Find instead of piped input, in case the issue was with the Windows implementation of the | shell operator. The issue actually gets worse, as the ~a becomes Pi:
Debugging update:
I tried some of the tricks listed at http://perldoc.perl.org/perlunicode.html,
e.g. use utf8, use feature 'unicode_strings', etc, to no avail.
Environment and Version Info
The OS is Windows 7, 64-bit.
The Perl is:
This is perl 5, version 12, subversion 2 (v5.12.2) built for MSWin32-x64-multi-thread
(with 8 registered patches, see perl -V for more detail)
Copyright 1987-2010, Larry Wall
Binary build 1202 [293621] provided by ActiveState http://www.ActiveState.com
Built Sep 6 2010 22:53:42
Perl, as with many other scripting languages, is built on the C runtime.
On Windows, the standard MS C runtime for narrow (byte) characters uses an encoding which defaults to the Windows system encoding (‘ANSI code page’) for IO activities such as opening files or writing to the console.
The ANSI code page is always a locale-specific encoding: usually single-byte, but multi-byte in some locales (eg China, Japan etc). It is never UTF-8 or anything else capable of reproducing the whole of Unicode; which characters Perl IO can cope with is dependent on the Windows locale (“language for non-Unicode programs” setting).
Whilst console apps can be given UTF-8 using the chcp 65001 command, there are a number of serious inconsistencies which come up with doing this. This causes difficulty for a lot of tools on Windows and is something Microsoft really needs to fix, but so far their attitude is that Unicode Equals UTF-16; everyone who wants Unicode to work must use the widechar interfaces.
So you won't currently be able to deal with files that use non-ASCII filenames reliably in Perl on Windows. Sorry.
You could try Python (which added special Windows-only filename handling to get around this problem in version 2.3 onwards; see PEP 277), or one of the Unicode-aware Windows Scripting Host languages. Either way, getting Unicode out to the console on Windows still has more pitfalls.
The following 3 liner works as expected on my newly minted ActivePerl 5.12.2:
use utf8;
open($file, '>:encoding(UTF-8)', "output.txt") or die $!;
print $file "さっちゃん";
I think the culprit is cmd.exe.