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
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 have a TCL script that is run by Libero using a file path provided as an argument to open a project. The file path is C:\Users\me\Documents\FPGA projects\file.prjx
I am running the script according to Libero TCL Reference Guide (pages 51 - 52) to run the script on the command line. On page 47, the doc outlines how to work with filenames with spaces; using braces or in the case where it is used as an argument use double quotes.
The command I am trying to execute is:
Path\to\libero SCRIPT:export.tcl SCRIPT_ARGS:""C:\Users\me\Documents\FPGA projects\file.prjx""
The outer set of double quotes is to follow the syntax outlined in page 52 of the document for providing arguments and the inner set of double quotes is to handle the white space in the first argument. I had expected $argv 0 to be C:\Users\me\Documents\FPGA projects\file.prjx, but instead $argv 0 is actually C:\Users\me\Documents\FPGA.
I added a print statement to the script to print $argv:
puts $argv
This gives a result of C:\Users\me\Documents\FPGA so the rest of the file path is not being interpreted as even being a second argument.
My assumption is that the conventions outlined in the document are just standard TCL conventions for providing a file path containing forward slashes and spaces as an argument. I have not been able to find an example of passing a similarly formatted argument in TCL. Any ideas?
I'm not sure it's the same issue but, having MagicSplat tclsh.exe and wish.exe linked to *.tcl and *.tk files in Windows (7 to 11), calling scripts this way:
processDIR.tcl "c:\My directory\subdir"
evals arguments only till first space, becoming "c:\My" BUT calling scripts like this:
tclsh.exe processDIR.tcl "c:\My directory\subdir"
trespasses complete argument.
Could you give it a try?
Hi I was trying to use linkdatagen, which is a perl based tool. It requires a vcf file (using mpileup from SAMtools) and a hapmap annotation file (provided). I have followed the instructions but the moment I use the perl script provided, I get this error.
The codes I used are:
samtools mpileup -d10000 -q13 -Q13 -gf hg19.fa -l annotHapMap2U.txt samplex.bam | bcftools view -cg -t0.5 - > samplex.HM.vcf
Perl vcf2linkdatagen.pl -variantCaller mpileup -annotfile annotHapMap2U.txt -pop CEU -mindepth 10 -missingness 0 samplex.HM.vcf > samplex.brlmm
Use of uninitiated value $chr in concatenation (.) or string at vcf2linkdatagentest.pl line 487, <IN> line 1.... it goes on and on.. I have mailed the authors, and haven't heard from them yet. Can anyone here please help me? What am I doing wrong?
The perl script is :
http://bioinf.wehi.edu.au/software/linkdatagen/vcf2linkdatagen.pl
The HapMap file can be downloaded from the website mentioned below.
http://bioinf.wehi.edu.au/software/linkdatagen/
Thanks so much
Ignoring lines starting with #, vcf2linkdatagen.pl expects the first field of the first line of the VCF to contain something of the form "chrsomething", and your file doesn't meet that expectation. Examples from a comment in the code:
chr1 888659 . T C 226 . DP=26;AF1=1;CI95=1,1;DP4=0,0,9,17;MQ=49;FQ=-81 GT:PL:GQ 1/1:234,78,0:99
chr1 990380 . C . 44.4 . DP=13;AF1=7.924e-09;CI95=1.5,0;DP4=3,10,0,0;MQ=49;FQ=-42 PL 0
The warning means that a variable used in a string is not initialized (undefined). It is an indication that something might be wrong. The line in question can be traced to this statement
my $chr = $1 if ($tmp[0] =~ /chr([\S]+)/);
It is bad practice to use postfix if statements on a my statement.
As ikegami notes a workaround for this might be
my ($chr) = $tmp[0] =~ /chr([\S])/;
But since the match failed, it will likely return the same error. The only way to solve is to know more about the purpose of this variable, if the error should be fatal or not. The author has not handled this case, so we do not know.
If you want to know more about the problem, you might add a debug line such as this:
warn "'chr' value not found in the string '$tmp[0]'" unless defined $chr;
Typically, an error like this occurs when someone gives input to a program that the author did not expect. So if you see which lines give this warning, you might find out what to do about it.
According to wikipedia :
A quine is a non-empty computer program which takes no input and produces a copy of its own source code as its only output
I saw this piece of perl code and am not able to figure out how it works.
Save the following line in file /tmp/p and run the file as perl /tmp/p:
Illegal division by zero at /tmp/p line 1.
The output of perl /tmp/p is:
Illegal division by zero at /tmp/p line 1.
How is the code working?
First, try to run it with warnings turned on:
$ perl -w p
Unquoted string "at" may clash with future reserved word at p line 1.
Unquoted string "tmp" may clash with future reserved word at p line 1.
Argument "tmp" isn't numeric in division (/) at p line 1.
Argument "at" isn't numeric in division (/) at p line 1.
The first two warnings are from the compile phase.
Let's look at the Deparse output:
$ perl -MO=Deparse p
'division'->Illegal('zero'->by('at' / 'tmp' / 'line'->p(1)));
p syntax OK
In essence, the value of at divided by tmp divided by the return value of another method invocationp is passed as an argument to the method by invoked on the class 'zero'. at and tmp are considered to be strings, and their numeric values are zero. Therefore, at/tmp results in the illegal division by zero error.
You will get the same error if you change the file's contents to
Stackoverflow hacker news one at /tmp/p line 1.
If you are wondering how Illegal division becomes 'division'->Illegal, see indirect object syntax, and avoid using it.
I would prefer to see you concentrating on improving the quality of your Perl code, rather than investigating obscure corners
But the answer is that the line is parsed as
'division'->Illegal('zero'->by('at' / 'tmp' / 'line'->p(1)));
and Perl uses zero for 'at' and 'tmp' because they are not valid numeric strings, so the first action is to evaluate 0 / 0 which throws the error
I'm having a strange problem with Email:MIME. I have the following code, which is intended to parse a MIME email message piped to it:
my $parsed = Email::MIME->new(<STDIN>);
print $parsed->body;
When I run this, either by piping a sample MIME email into it, or by setting my host to pipe new email to it and sending myself one, I get the following error on the first line:
> Can't use string ("Received: from
> servera02.tk2adsm") as a HASH ref
> while "strict refs" in use at
> /usr/lib/perl5/site_perl/5.8.8/Email/Simple.pm
> line 100, <STDIN> line 71.
The line shown in the error varies according to the email but it is always the second line of the email content (so I'm really not very sure why it's claiming it's STDIN line 71). I've done some googling about this and it really seems to be unique to me - does anyone have any ideas?
I'm not a Perl expert by a long way, and I've never used Email::MIME, so I'm hoping this is something simple.
Chris
The documentation says that new() expects its argument to be a message in the form of a string. <STDIN> is an array (since an argument list is in list context).
Try converting the message to a string as you pass it: my $parsed = Email::MIME->new(join('', <STDIN>));
i mean you might not get the error if you turn off strict refs