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?
Related
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.
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.
I'm trying to run the word_align.pl script provided by CMUSphinx. I write the command as follows:
perl word_align.pl actualtext.txt batchOutputText.txt
But the terminal gives me the following errors:
Use of uninitialized value $ref_uttid in hash element at word_align.pl line 60, line 1.
Use of uninitialized value $ref_uttid in concatenation (.) or string at word_align.pl line 61, line 1.
UttID is not ignored but it could not found in any entries of the hypothesis file on line3 1 UTTID
I am not quite familiar with Perl and I can't figure out what is the problem here though I followed the instructions provided by CMUSphinx to run that script
You can find the script here
Edit: here is the reference's file link
The answer is in this error message
UttID is not ignored but it could not found in any entries of the hypothesis file on line3 1 UTTID
The reference file that you are passing is malformed, specifically its first line isn't formatted as it should be
More precisely, each line of the reference file requires a UTT ID—a unique string in parentheses like (output00000). It must be unique because it is used as a hash key. A simple digit like (1) won't work as it will be mistaken for an alternative pronunciation
The first line of your file must be different from that. You suggest
<s> text </s> (file12)
which actually works fine—I have tested it—and $ref_uttid comes out as FILE12. If you tell us what is actually in your file then I am sure we could help you better
GCC version 4.6
The Problem: To find a way to feed in parameters to the executable, say a.out, from the command line - more specifically feed in an array of double precision numbers.
Attempt: Using the READ(*,*) command, which is older in the standard:
Program test.f -
PROGRAM MAIN
REAL(8) :: A,B
READ(*,*) A,B
PRINT*, A+B, COMMAND_ARGUMENT_COUNT()
END PROGRAM MAIN
The execution -
$ gfortran test.f
$ ./a.out 3.D0 1.D0
This did not work. On a bit of soul-searching, found that
$./a.out
3.d0,1.d0
4.0000000000000000 0
does work, but the second line is an input prompt, and the objective of getting this done in one-line is not achieved. Also the COMMAND_ARGUMENT_COUNT() shows that the numbers fed into the input prompt don't really count as 'command line arguments', unlike PERL.
If you want to get the arguments fed to your program on the command line, use the (since Fortran 2003) standard intrinsic subroutine GET_COMMAND_ARGUMENT. Something like this might work
PROGRAM MAIN
REAL(8) :: A,B
integer :: num_args, ix
character(len=12), dimension(:), allocatable :: args
num_args = command_argument_count()
allocate(args(num_args)) ! I've omitted checking the return status of the allocation
do ix = 1, num_args
call get_command_argument(ix,args(ix))
! now parse the argument as you wish
end do
PRINT*, A+B, COMMAND_ARGUMENT_COUNT()
END PROGRAM MAIN
Note:
The second argument to the subroutine get_command_argument is a character variable which you'll have to parse to turn into a real (or whatever). Note also that I've allowed only 12 characters in each element of the args array, you may want to fiddle around with that.
As you've already figured out read isn't used for reading command line arguments in Fortran programs.
Since you want to read an array of real numbers, you might be better off using the approach you've already figured out, that is reading them from the terminal after the program has started, it's up to you.
The easiest way is to use a library. There is FLAP or f90getopt available. Both are open source and licensed under free licenses.
The latter is written by Mark Gates and me, just one module and can be learned in minutes but contains all what is needed to parse GNU- and POSIX-like command-line options. The first is more sophisticated and can be used even in closed-source projects. Check them out.
Furthermore libraries at https://fortranwiki.org/fortran/show/Command-line+arguments
What READ (*,*) does is that it reads from the standard input. For example, the characters entered using the keyboard.
As the question shows COMMAND_ARGUMENT_COUNT() can be used to get the number of the command line arguments.
The accepted answer by High Performance Mark show how to retrieve the individual command line arguments separated by blanks as individual character strings using GET_COMMAND_ARGUMENT(). One can also get the whole command line using GET_COMMAND(). One then has to somehow parse that character-based information into the data in your program.
I very simple cases you just need the program requires, for example, two numbers, so you read one number from arg 1 and another form arg 2. That is simple. Or you can read a triplet of numbers from a single argument if they are comma-separated like 1,2,3 using a simple read(arg,*) nums(1:3).
For general complicated command line parsing one uses libraries such as those mentioned in the answer by Hani. You have set them up so that the library knows the expected syntax of the command line arguments and the data it should fill with the values.
There is a middle ground, that is still relatively simple, but one already have multiple arguments, that correspond to Fortran variables in the program, that may or may not be present. In that case one can use the namelist for the syntax and for the parsing.
Here is an example, the man point is the namelist /cmd/ name, point, flag:
implicit none
real :: point(3)
logical :: flag
character(256) :: name
character(1024) :: command_line
call read_command_line
call parse_command_line
print *, point
print *, "'",trim(name),"'"
print *, flag
contains
subroutine read_command_line
integer :: exenamelength
integer :: io, io2
command_line = ""
call get_command(command = command_line,status = io)
if (io==0) then
call get_command_argument(0,length = exenamelength,status = io2)
if (io2==0) then
command_line = "&cmd "//adjustl(trim(command_line(exenamelength+1:)))//" /"
else
command_line = "&cmd "//adjustl(trim(command_line))//" /"
end if
else
write(*,*) io,"Error getting command line."
end if
end subroutine
subroutine parse_command_line
character(256) :: msg
namelist /cmd/ name, point, flag
integer :: io
if (len_trim(command_line)>0) then
msg = ''
read(command_line,nml = cmd,iostat = io,iomsg = msg)
if (io/=0) then
error stop "Error parsing the command line or cmd.conf " // msg
end if
end if
end subroutine
end
Usage in bash:
> ./command flag=T name=\"data.txt\" point=1.0,2.0,3.0
1.00000000 2.00000000 3.00000000
'data.txt'
T
or
> ./command flag=T name='"data.txt"' point=1.0,2.0,3.0
1.00000000 2.00000000 3.00000000
'data.txt'
T
Escaping the quotes for the string is unfortunately necessary, because bash eats the first quotes.
I have searched around the Internet and the Perl doc and can't seem to find the answer.
Help will be appreciated.
EDIT:: He asked me about -G, wrote it down on a piece of paper and when i looked stumped asked me to go read up on the basics.
I agree with JesperE, please show us some code. However, as far as I can tell, this is what's happening:
if(-G) {
Perl sees this, doesn't recognize -G, and so treats it as a string. It becomes:
if('-G') {
Which is equivalent to:
if(1) {
So as far as I can tell, if(-G) does nothing. I've tried using it, and it always seems to return true, which supports my hypothesis. Further support is from the following code (tested on OS X with Perl 5.10.0):
use strict;
use warnings;
my $var = -G;
print "$var\n";
Displays no warnings, compiles and runs, and prints simply "-G".
EDIT: Doing a search I should have done much earlier provides the following from Perldoc's perlop page:
Unary "-" performs arithmetic negation if the operand is numeric. If the operand is an identifier, a string consisting of a minus sign concatenated with the identifier is returned. Otherwise, if the string starts with a plus or minus, a string starting with the opposite sign is returned. One effect of these rules is that -bareword is equivalent to the string "-bareword". If, however, the string begins with a non-alphabetic character (excluding "+" or "-"), Perl will attempt to convert the string to a numeric and the arithmetic negation is performed. If the string cannot be cleanly converted to a numeric, Perl will give the warning Argument "the string" isn't numeric in negation (-) at ....
As stated in the comments, B::Deparse appears to show that Perl converts if(-G) to if(-'G'). However, the documentation (and the behavior with print()) are consistent with the documentation, which says that it should convert if(-G) to if('-G'). This doesn't change the result of the program either way.
However, subtle typing differences in the behaviors of unary operators that 99% of people will only ever use on numbers are not what I would call "basic." I don't think anyone should (or would ever need to) use the -bareword to 'bareword' conversion in any practical situation.
There's no switch -G in perl.
perl -G
Unrecognized switch: -G (-h will show valid options).
Edit: OK, there's nothing with -G either - only -g.
-g File has setgid bit set.
http://perldoc.perl.org/perlfunc.html
Otherwise, it's nonsense and the question is misphrased.
I don't know about -G but -g is described here as
-g File has setgid bit set.
This is clearly confusion between [ (test) options and Perl -X file tests. -G is in the former (on my BSD system), but not the latter. -G is a non-posix extension and I guess Perl didn't include all the extensions, just some. So its either, he meant to say -g or he meant [ -G $file ]; (for some superset of POSIX [). It is also in my default shell (pdksh) and bash (the linux default shell, for the most part)
-G in test or as a shell builtin here:
-G file
True if file exists and its group matches the effective group ID
of this process.
One answer says: "I don't think anyone should (or would ever need to) use the -bareword to -'bareword' conversion in any practical situation."
This is widely used in one style of named parameters. See the venerable CGI for one:
$cookie1 = $q->cookie(-name=>'riddle_name', -value=>"The Sphynx's Question");
$cookie2 = $q->cookie(-name=>'answers', -value=>\%answers);
print $q->header(
-type => 'image/gif',
-expires => '+3d',
-cookie => [$cookie1,$cookie2]
);