Hello Kino,
Thank you for your reply.
Kino wrote:That is not a NW Pro problem but what you always get even from a script run in Terminal, when backticks are used to receive something from an external program. As perl does not know the encoding of the output, the UTF-8 flag is not turned on automatically. I don't know if this is a proper way but usually I use "utf8::decode".
Code: Select all
begin Perl
$res = `~/Desktop/myPerlScript.pl`;
# /usr/bin/perl is unnecessary as far as the script is executable.
utf8::decode $res;
end
This seems to be the answer to my problem. I tried this, and it worked perfectly. Thank you!
By the way, another option which is needed is to not delete immediately this temporary Perl script. As you delete it, it becomes impossible to debug it...!
Me too, I have complaint to Martin about the deletion repeatedly but recently I realised that I can see the script very easily, just by putting `open -e "$0"`; somewhere in the perl block. Alternatively and with NW Pro 1.1, you can do:
Code: Select all
Debug.setDestination 'new'
Debug.setIncludePerl true
begin Perl
[your code]
$NisusPL = `cat "$0"`;
utf8::decode $NisusPL;
print STDOUT $NisusPL;
end
I tried this, and it worked perfectly. This is very good to know this!
The ideal would be that you create a kind of "expert mode", in which you would leave the users to decide if they want or not the two lines.
Once I sent a feedback requesting the same feature but I began to think such an option is perhaps unnecessary because I have not had a single occasion in which I really need it and because I think (not tested) you can override those three lines by inserting your own preambules at the top of a perl block, for example...
Code: Select all
no utf8;
binmode (STDIN, ":bytes");
binmode (STDOUT, ":bytes");
I tried this, and it seems to not work. When I put 'binmode (STDOUT, ":byte")' in the script, the Perl block doesn't return any output; I can do for example:
Code: Select all
binmode (STDOUT, ":bytes");
$res = `perl $myScript`;
binmode (STDOUT, ":utf8");
In this case, I get the result, but it can be garbled -- the same thing as if I have not put either of these 'binmode' lines. I think this is due to the final line of the Nisus Perl block (that I could verify using your '`open -e "$0"`;' technique...):
Code: Select all
print "
NisusPerlBoundary-AB3F2CA0-35C7-4528-8293-CB88BD60146B
";
that I don't understand. Anyway, this is not the behavior of the normal Perl script.
This seems to mean that my suggestion of the "expert mode" would not work with the current implementation of Nisus Perl block... So, the only possibilities for this kind of cases is either to use 'utf8:: decode' or to redirect the output to a temporary file and read it afterward... Sigh!
But all this should be documented in the Reference.
OTOH what looks urgent to me now is, as I requested via feedback some hours ago, a new command for controling which variables are sent to a perl block, excluding all the others.
With the excellent and innovative new macro language introduced by NW Pro 1.1, many of macros I write now begin with
Code: Select all
$doc = Document.active
$text = $doc.text
Then, if there is a perl block, the
whole $doc.text will be written to a temporary perl script file. I think this would be a serious performance hit especially when $doc.text is large and the perl block is executed repeatedly in a loop. Of course, you could sometimes work it around by putting "$text = $doc.text"
after perl block(s), but
not always. So I'd like to have a way to specify variables to be written to the script file.
Ah, this is a serious problem. I think you realized the existence of this problem because you could look at the actual Perl code using your "debug mode".
I think such a command would not cause any trouble to any user as far as the restriction of variables sent to perl occurs only when the hypothetical "Perl.variablesAvailable ($var1, $var2...)" command is present in the macro.
This is a very good suggestion, and I second it!
And, on this occasion, I'd like to repeat my past feature request here again. I'd like to have "begin Shell... end". It is absurd and inelegant to call perl just to execute an external program via backticks.
And of course, I agree on this as well!