Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

Documentation @PERL

Apr
318
7
It would be a great help if the documentation of this feature would link to a list of all prerequisites for its use.

E.g. I can use Perl scripts anywhere anytime except with this function. !

Of course, the same goes for @Python and its brethren.

Have a nice day,
DJ
 
Please read my posting. Thank you for your effort but you answered a question I did not ask.
Now I fear I can predict what your next response will be: "Suggestions should be posted in ...".
I will, later.

In lieu of the missing documentation I found something in the release notes for version 12. It says "that Perl support is no longer version dependent, so you can use Perl 5.8, 5.10, or 5.12".

These versions are no longer available at ActiveState. I'm currently using 5.16. Could that be the reason all calls to @perl fail?
 
Please read my posting. Thank you for your effort but you answered a question I did not ask.


You asked about running Perl scripts with @PERL; I responded that you cannot -- @PERL is only for executing individual Perl statements. If you want to execute Perl scripts, you need to enable Perl support in OPTION, and then simply run them from the command line.

Because of the massive (and rapidly worsening) bugs in embedded Perl for Windows, the Perl support in TCC was changed in v12 to use PerlScript (the WSH COM interface). The version of Perl you use isn't relevant anymore, provided you have PerlScript support. You can see the WSH languages you have installed by running the SCRIPT command with no arguments. If you don't see PerlScript, then you cannot run Perl scripts (or statements via the @PERL function).
 
How do you get WSH COM to support Perl if it's not there?
 
You asked about running Perl scripts with @PERL

No I didn't. [...] Really! I didn't! Read again. I didn't ask a question at all. I suggested a way to improve the documentation. To illustrate why I think such an improvement of the docs is warranted I mentioned the problem I'm having running perl scripts. It was offered as:
1) an example of a problem a user might have and
2) a way to improve the docs, so that:
- users will have a better understanding of the intended use of the product​
- users will make fewer errors applying the product to their work​
- users will have less confusion and frustration their satisfaction​
- users will ask fewer questions about them on these forums​

I still think such an addition to the documentation would be an improvement, btw. I would now add to my former suggestion that if, for reasons I do not understand, you are reluctant to change the documentation, then please use the "Tips" forum to provide such info. I would write it myself if I felt my help would be appreciated and provided I was assigned a proof-reader and tech sparring partner. The last thing I would want to do is polute that space with incorrect, incomplete, misleading or otherwise unhelpful information.
@PERL executes a Perl statement, not a script

Perhaps there is some confusion here about the use of the term "script". In my mind, Perl is a scripting language. I use the term 'script' for any and every piece of text that contains valid perl-code. Looking back, I see I used the word 'scripts' somewhere, which might be construed as plural of 'a script', which might in turn be thought of as a rounded piece of software stored in a separate file. If that confused or offended you, I'm sorry.

But, now that we're here,... :)

When I wrote
I can use Perl scripts anywhere anytime ...
what I meant was that I frequently use code like this:

Code:
@setlocal
@echo off
 
:: Perl already accomodated? 
:: Sets up some aliases and perl-specific envars.
if not defined PERLHOME call %TCLib\TCPerl
 
:: Wrap the script in a transient specialized environment.
perl -f hello.pl
 
:: No quoting problems!
perl <<< print("Hello from a here-string, ");
 
:: Same here,..
perl <<- PerlScript
...
PerlScript
 
:: Perldoc says: "Cmdline quoting is just a mess."
:: These variants, at least, do work in TCC.
 
perl -e "print(\"and a one-liner.\n\");"
perl -e "print('Is a second one-liner ... ');"
perl -e "print(q/in effect a two-liner?/);"
perl -e "print(\"\n\");"
 
:: This one does NOT work.
echo %@perl[$a = 'Do geese see God'; $a = reverse($a); printf "$a\n"]
 
@endlocal
@quit 0
::EOF

which gives me four demonstrated ways to use perl in TC, at least one more not shown here, while the method proposed by the documentation, using @PERL[] does not work.

Your remark about WSH did trigger a recollection of that same piece of information in the version 12 release notes. And - of course - you're right! I didn't install the ActiveScript component.

And you know what Rexx? That's exactly what would NOT have happened if my originally suggested improvement of the docs had been heard and that's exactly what I could have solved by myself if the info had been accessible in the way we discussed.

As always, I appreciate your product very much!
Thank you for providing it.

DJ
 

Similar threads

Back
Top