From: Peter J. Holzer on
On 2010-07-31 22:00, PerlFAQ Server <brian(a)theperlreview.com> wrote:
> --------------------------------------------------------------------
>
> 8.44: How do I tell the difference between errors from the shell and perl?
>
> (answer contributed by brian d foy)
>
> When you run a Perl script, something else is running the script for
> you, and that something else may output error messages. The script might
> emit its own warnings and error messages. Most of the time you cannot
> tell who said what.

I find this paragraph confusing. The "something else" that "is running
the script for" me is the perl interpreter. But from the rest of this
entry I guess that "something else" means the shell, which doesn't run
the script, it merely starts it. Or at least it shouldn't run the
script. If it tries to, you get the error message below.


> You probably cannot fix the thing that runs perl, but you can change how
> perl outputs its warnings by defining a custom warning and die
> functions.
>
> Consider this script, which has an error you may not notice immediately.
>
> #!/usr/locl/bin/perl
>
> print "Hello World\n";
>
> I get an error when I run this from my shell (which happens to be bash).
^^^^^^^^^^^^^^^^^^^^^^^^
> That may look like perl forgot it has a "print()" function, but my
> shebang line is not the path to perl, so the shell runs the script, and
> I get the error.
>
> $ ./test
> ./test: line 3: print: command not found

At least bash 4.1 on Linux prints

bash: ./foo: /usr/locl/bin/perl: bad interpreter: No such file or directory

here. But an older version of bash (or some other shell) may behave as
stated.

>
> A quick and dirty fix involves a little bit of code, but this may be all
> you need to figure out the problem.
[...]
> Perl: Useless use of division (/) in void context at ./test line 9.
[...]
> You could also just know all the perl errors, and although there are
> some people who may know all of them, you probably don't.

Or you may just know the general style of error messages from perl and
from your shell. In the example above, the error message

./test: line 3: print: command not found

has the form

$filename: line $linenumber: $message

Perl messages never look like this. They always have the form

$message at $filename line $linenumber

(plus possibly a hint on the last read operation). This is sufficiently
different from the style of the shell (and indeed from just about any
other Unix program) that perl messages are easily recognized.

hp
From: Peter J. Holzer on
On 2010-08-10 13:10, brian d foy <brian.d.foy(a)gmail.com> wrote:
> In article <slrni59df1.v04.hjp-usenet2(a)hrunkner.hjp.at>, Peter J.
> Holzer <hjp-usenet2(a)hjp.at> wrote:
>> On 2010-07-31 22:00, PerlFAQ Server <brian(a)theperlreview.com> wrote:
>> > 8.44: How do I tell the difference between errors from the shell and perl?
>> >
>> > (answer contributed by brian d foy)
>> >
>> > When you run a Perl script, something else is running the script for
>> > you, and that something else may output error messages. The script might
>> > emit its own warnings and error messages. Most of the time you cannot
>> > tell who said what.
>>
>> I find this paragraph confusing. The "something else" that "is running
>> the script for" me is the perl interpreter. But from the rest of this
>> entry I guess that "something else" means the shell, which doesn't run
>> the script, it merely starts it.
>
> Starting it is the same as running it, when most people consider
> "running" to be typing at the command line and hitting enter to kick
> something off.

The target audience of this FAQ is not "most people", but Perl
programmers. More specifically, this question is about possible
confusion caused by two interpreters (the shell and the perl
interpreter) and I don't think it is helpful to add to the confusion by
using vague and misleading language.

Maybe something like:

When you run a Perl script, you often start it from a shell. The
script is compiled and executed by the perl interpreter. Both the
shell and the perl interpreter may output error messages. The script
might emit its own warnings and error messages. Most of the time you
cannot tell who said what.

But I'm not happy with that either, because it covers the normal
situation and not the specific error that the perl script is interpreted
by shell instead of the perl interpreter.

> It sounds like you've sussed it out just fine by reading the whole
> thing. :)

I'm a sysadmin. It's my job to understand users.

hp

From: Dr.Ruud on
brian d foy wrote:

> A better answer probably changes the verbs instead of the nouns.

You flirt!

--
Ruud