I think it's just a commented out piece of code. Perl only gives special meaning to #!, not to # by iteslf, unless you consider comments "special" ;) . And the `backticks` containing which perl are the same as qx/which perl/, which is also a little wierd because the command is executed in void context. ...actually it's not executed at all because it's commented out.

I don't know the nuances of Solaris ksh, but perlrun doesn't give any indication that #`....` would have some special meaning aside from a comment.

Response to OP's update:
Now it makes sense. With the #! (as you've indicated in your update), the shell invokes the backticks (perl doesn't), essentially expanding `which perl` to something along the lines of "/usr/bin/perl" (or whatever the output of "which perl" happens to be on your configuration). perlrun does state that whatever follows #! on the first line will be executed, so it's not surprising this should work in a unix flavored environment.

C:\>perl
#line 666 special
die
^Z
Died at special line 666.

C:\>
[download]

greatshots sought to understand that which is described by the following text:

[...] in a very old application called npr [...] I have picked the following snippet from there and ask for your valueable inputs about it. #!`which perl` The above code works fine in Solaris ksh. Is that a appreciatable line in perl ? have anyone of you already used such a line in your perl codes ? can I use those line in my future codes ?

I would say not. It is a thing i don't think i have seen before, but it does something similar to what is done by a much more recent and sound first-line: #! /usr/bin/env perl

Points to understand:

• This is called "the shebang line" in Perl culture, or alternately the "sharpbang" or the "hash-bang".

• This is not Perl code. It is not really shell code either. This first line is a means by which, only under Unix systems, a Unix OS kernel can determine which interpreter to run this script under. If the shell becomes involved in this process at all, and I suppose under some very ancient Unix made by some vendor in the benighted depths of history, that could happen, then one might see the shell execute which perl and report back to the kernel what path to use for invoking the Perl interpreter.

• Non-unix systems like MS Windows do not care about this line, except that the Perl intepreter on those systems sees the line and if there are some switches like -w after the tokens perl, it will take note of them as it would if they had appeared on the commandline.

• /usr/bin/env perl does them same thing as `which perl` might have done in this obsolete Unix context, on modern Unix systems, without the involvement of the shell.

Caveat: I am not a Unix guru of 30 years experience and I don't warrantee that every aspect of this reply is correct.

If you want the best advice I can give you based on my own understanding, use #! /usr/bin/env perl (but no switches allowed after 'perl'). The space between the ! and the /usr/bin... is deliberate. It caters to the dysfunction of a legacy Unix flavor (I think it is an HPUX) that didn't do correct kernel intepretation of the shebang without the space. It does not harm correct operation of any other known Unix flavor.

-- 

Most Solaris machines come with Perl and this may be rather ancient. However it may be better not to play with this and to install your own in another location.

Different versions for different jobs and I'd rather have control which I want to use.

What happens when run under cron rather than at terminal?

Edit OK so this doesn't answer the question but others have done that far better than I can.

Here's an addendum to what others have said about the perl shebang. There's a disctinction between an installed script, and one that is distributed (to multiple target machines, to different hardware platforms).

The installed script should contain a shebang that points to the real perl image. On Unix O/S, anything else is a potential security risk. Windows doesn't care, and ignores the shebang line.

A distributed script can potentially have anything in the shebang line, provided it contains the word perl. Granted if you are developing in a Unix environment, it will need to be set to the perl path on the box you are developing on, if you want ./foo.pl to work.

To turn one or more distributed scripts into installed scripts involves changing the shebang line. On Windows it involves running pl2bat to wrap the script in a .bat file.

With standard CPAN installs, this process has been automated - add your script to the target exe_files (script_files for Module::Build), and the shebang magic happens during make install.

However that doesn't answer the question, "is that a appreciatable line in perl" Well I ain't got a clue what "a appreciatable line" is, but I'll say this:

As the wikipedia entry mentions, the shebang is part of the shell not perl. Like most of the rest of life there is more than one way to do it. The usual way is #!/usr/bin/perl However your shebang seems to work on your system (it doesn't on mine) so if it ain't broke don't fix it. If you're planning on moving the scripts to another system you should be prepared to have to change that line. Someone else mentioned another non-standard shebang line using env. That one also fails on my system. If you're looking for portability between systems then stick with the standard way. If not you're free to use whatever works (in a secure way) on your system.