I downloaded and set up PintOS and the dependencies on my home computer, but when I try to run pintos run alarm-multiple, I get the error:
Unrecognized character \x16; marked by <-- HERE after if ($<-- HERE near column 7 at ~/code/pintos/src/utils/pintos line 911.
That line has ^V on it, the synchronous idle control character. I haven't been able to find any information on this problem; it seems like I'm the only one experiencing it.
I have Perl v5.26.0 installed.
Use of literal control characters in variable names was deprecated in Perl 5.20:
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]
The code causing this problem was fixed in PintOS with this commit in 2016:
committer Ben Pfaff <blp#cs.stanford.edu>
Tue, 9 Feb 2016 04:47:10 +0000 (20:47 -0800)
Modern versions of Perl prefer a caret in variable names over literal
control characters and issue a warning if the control character is used.
This fixes the warning.
diff --git a/src/utils/pintos b/src/utils/pintos
index 1564216..2ebe642 100755 (executable)
--- a/src/utils/pintos
+++ b/src/utils/pintos
## -912,7 +912,7 ## sub get_load_average {
# Calls setitimer to set a timeout, then execs what was passed to us.
sub exec_setitimer {
if (defined $timeout) {
- if ($\16 ge 5.8.0) {
+ if ($^V ge 5.8.0) {
eval "
use Time::HiRes qw(setitimer ITIMER_VIRTUAL);
setitimer (ITIMER_VIRTUAL, $timeout, 0);
Perl 5.26 made it a fatal error to use literal control characters in variable names.
The way you fix it is by ensuring that you are using the most recent version of pintOS. The command git clone git://pintos-os.org/pintos-anon ought to do it.
^V is a perlvar. For reasons unknown to me, it was encoded not as ^ V, but as a single unicode character, which caused the program to fail.
Related
I recently learned that you can use special characters in PowerShell variables, e.g.: ${hello world!}, but then I stumbled across this:
${^}
What does it do? I first thought it referenced the newest created variable, but it does other stuff I haven't really figured out.
The documentation says:
Contains the first token in the last line received by the session.
Examples:
dir c:\windows 🡒 dir
0..9 🡒 0
&{ dir } 🡒 &
It was likely introduced to get the last command used (dir, copy, rm, ...), but in reality that will only work for the most simplest cases, and thus it's not very useful.
The corresponding $$ returns the last token from the last line.
Note: The curly braces {} are only necessary for variable names containing characters which are not allowed in variables, except automatic variables (look here). In this case, you can omit them:
$^
It shows the first word/token in the last executed command.
When I run a file which is begin with #!/usr/bin/perl -w, I get a error:
syntax error at line 153, near "=~ ?"
I try to add "#!/bin/bash", this error is not append, but I get another
error:
"line 34: syntax error near unexpected token `('"
line 153 in my file:
($output_volume =~ ?^([\S]+).mnc?) && ($base_name = $1) ||
die "sharpen_volume failed: output volume does not appear to be"
." a minc volume.\n";
line34 in my file:
use MNI::Startup qw(nocputimes);
$output_volume =~ ?^([\S]+).mnc?
This used to be valid perl and thus might appear in old code and instructional material.
From perlop:
In the past, the leading m in m?PATTERN? was optional, but omitting it would produce a deprecation warning. As of v5.22.0, omitting it produces a syntax error. If you encounter this construct in older code, you can just add m.
That is Perl code so the first error message is meaningful.
With delimiters other than // in the match operator you must have the explicit m for it, so
$output_volume =~ m?^([\S]+).mnc?
It is only with // delimiters that the m may be omitted; from Regex Quote-Like Operators (perlop)
If "/" is the delimiter then the initial m is optional.
See perlretut for a tutorial introduction to regex and perlre for reference.
Also note that the particular delimiters of ? trigger specific regex behavior in a special case. This is discussed by the end of the documentation section in perlop linked above.
You already have two answers that explain the problem.
? ... ? is no longer valid syntax for a match operator. You need m? ... ? instead.
Until Perl 5.22, your syntax generated a warning. Now it's a fatal error (which is what you are seeing). So I assume you're now running this on a more recent version of Perl.
There are, however, a few other points it is probably worth making.
You say you tried to investigate this by changing the first line of your file from #!/usr/bin/perl -w to #!/bin/bash. I'm not sure how you think this was going to help. This line defines the program that is used to run your code. As you have Perl code, you need to run it with Perl. Trying to run it with bash is very unlikely to be useful.
The m? ... ? (or, formerly, ? ... ?) syntax triggers an obscure and specialised behaviour. It seems to me that this behaviour isn't required in your case, so you can probably change it to the more usual / ... /.
Your regex contains an unescaped dot character. Given that you seem to be extracting the basename from a filename that has an extension, it seems likely that this should be escaped (using \.) so that it matches an actual dot (rather than any character).
If you are using this code to extract a file's basename, then using a regex probably isn't the best approach. Perhaps take a look at File::Basename instead.
The Parse::Yapp currently shiping on Ubuntu 16.04 (xenial) is slightly behind perl in that it uses unescaped '{'s in regular expressions. The error message indicates that it's in YappParse.yp which doesn't exist. In the interest of patching it locally until a new version of Parse::Yapp comes down the pipe, what template file is it in?
{yapp}
Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/\G{ <-- HERE / at YappParse.yp line 288.
Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/\G%{ <-- HERE / at YappParse.yp line 315.
Parse::Yapp hasn't had a release since 2001. I wouldn't hold my breath. Since it's effectively unmaintained I'd recommend either moving whatever you're using off of it or taking over maintenance. Consider something like Pegex or Regexp::Grammars instead.
Fortunately this problem has been reported twice, both contain patches. See rt.cpan.org 114776 and rt.cpan.org 10668.
Maintenance has been picked up and 1.20 appears to fix the problem.
perldb's stack trace revealed (or implied that) the file is Parse/Yapp/Parse.pm. Here's a patch:
diff -u /usr/share/perl5/Parse/Yapp/Parse.pm{~,}
--- /usr/share/perl5/Parse/Yapp/Parse.pm~ 2001-05-20 07:19:57.000000000 -0400
+++ /usr/share/perl5/Parse/Yapp/Parse.pm 2016-09-18 02:12:09.116799976 -0400
## -880,7 +880,7 ##
return($1, [ $1, $lineno[0] ]);
};
- $$input=~/\G{/gc
+ $$input=~/\G\{/gc
and do {
my($level,$from,$code);
## -907,7 +907,7 ##
and return('START',[ undef, $lineno[0] ]);
$$input=~/\G%(expect)/gc
and return('EXPECT',[ undef, $lineno[0] ]);
- $$input=~/\G%{/gc
+ $$input=~/\G%\{/gc
and do {
my($code);
Hopefully this will save others some detective work.
This also occurs if you are calling a ksh shell script (such as print) from a non-ksh shell (such as bash).
I want to manage vendor branches in svn using the svn_load_dirs.pl script.
When I execute this script on my Mac OS X 10.5, perl v5.10.1 (*) built for darwin-multi-2level
I get he following error message:
Argument "2.07_02" isn't numeric in subroutine entry at /usr/local/bin/svn_load_dirs line 22.
What does this mean and is this harmful?
To understand Perl messages, you can look them up in perldoc perldiag:
Argument "%s" isn't numeric%s
(W numeric) The indicated string was
fed as an argument to an operator that
expected a numeric value instead.
Since this message is classified as a Warning, it may not be harmful. But, it is worth investigating. Since I do not have access to the svn_load_dirs.pl script, could you please update your Question with the 1st 22 lines of the script?
This has me puzzled. This code worked on another server, but it's failing on Perl v5.8.8 with Date::Manip loaded from CPAN today.
Warning:
Use of uninitialized value in numeric lt (<) at /home/downside/lib/Date/Manip.pm line 3327.
at dailyupdate.pl line 13
main::__ANON__('Use of uninitialized value in numeric lt (<) at
/home/downsid...') called at
/home/downside/lib/Date/Manip.pm line 3327
Date::Manip::Date_SecsSince1970GMT(09, 16, 2008, 00, 21, 22) called at
/home/downside/lib/Date/Manip.pm line 1905
Date::Manip::UnixDate('today', '%Y-%m-%d') called at
TICKER/SYMBOLS/updatesymbols.pm line 122
TICKER::SYMBOLS::updatesymbols::getdate() called at
TICKER/SYMBOLS/updatesymbols.pm line 439
TICKER::SYMBOLS::updatesymbols::updatesymbol('DBI::db=HASH(0x87fcc34)',
'TICKER::SYMBOLS::symbol=HASH(0x8a43540)') called at
TICKER/SYMBOLS/updatesymbols.pm line 565
TICKER::SYMBOLS::updatesymbols::updatesymbols('DBI::db=HASH(0x87fcc34)', 1, 0, -1) called at
dailyupdate.pl line 149
EDGAR::updatesymbols('DBI::db=HASH(0x87fcc34)', 1, 0, -1) called at
dailyupdate.pl line 180
EDGAR::dailyupdate() called at dailyupdate.pl line 193
The code that's failing is simply:
sub getdate()
{ my $err; ## today
&Date::Manip::Date_Init('TZ=EST5EDT');
my $today = Date::Manip::UnixDate('today','%Y-%m-%d'); ## today's date
####print "Today is ",$today,"\n"; ## ***TEMP***
return($today);
}
That's right; Date::Manip is failing for "today".
The line in Date::Manip that is failing is:
my($tz)=$Cnf{"ConvTZ"};
$tz=$Cnf{"TZ"} if (! $tz);
$tz=$Zone{"n2o"}{lc($tz)} if ($tz !~ /^[+-]\d{4}$/);
my($tzs)=1;
$tzs=-1 if ($tz<0); ### ERROR OCCURS HERE
So Date::Manip is assuming that $Cnf has been initialized with elements "ConvTZ" or "TZ". Those are initialized in Date_Init, so that should have been taken care of.
It's only failing in my large program. If I just extract "getdate()" above
and run it standalone, there's no error. So there's something about the
global environment that affects this.
This seems to be a known, but not understood problem. If you search Google for
"Use of uninitialized value date manip" there are about 2400 hits.
This error has been reported with MythTV and grepmail.
It is a bug in Date::Manip version 5.48-5.54 for Win32. I've had difficulty with using standard/daylight variants of a timezones, e.g. 'EST5EDT', 'US/Eastern'. The only timezones that appear to work are those without daylight savings, e.g. 'EST'.
It is possible to turn off timezone conversion processing in the Date::Manip module:
Date::Manip::Date_Init("ConvTZ=IGNORE");
This will have undesired side-effects if you treat dates correctly. I would not use this workaround unless you are confident you will be never be processing dates from different timezones.
It's almost certain that your host doesn't have a definition for the timezone you're specifying, which is what's causing a value to be undefined.
Have you checked to make sure a TZ definition file of the same name actually exists on the host?
Date::Manip is supposed to be self-contained. It has a list of all its time zones in its own source, following "$zonesrfc=".
Can you try single-stepping through the debugger to see what exactly is going wrong? It could easily be %Zone that is wrong - %tz may be set correctly on line 1 or 2, but then the lookup on line 3 fails, ending up with undef.
Edit: %Date::Manip::Cnf and %Date::Manip::Zone are global variables, so you should be able to take a dump of them before and after the call to Date::Manip::Date_Init. If I read the source correctly %Cnf should contain a basic skeleton of configuration options before the call to Date_Init, and %Zone should be empty; after Date_Init, TZ should have your chosen value, and %Zone should be populated by a lookup table of time zones.
I see a reference to .DateManip.cnf in %Cnf, which might be something to look at - is it possible that you have such a file in your home directory, or the current working directory, which is overriding the default settings?