RE: using Perl Editor with files sans extensions

halbers wrote on Wed Oct 13 17:32:19 MEST 2004:

As a workaround, run a routine in your login script that searches for the
*.pl files and creates aliases with the same name but without the extension.

halbers wrote on Wed Oct 13 17:43:25 MEST 2004:

Sorry, I forgot to mention that the alias will have to include the call
of your perl library, for bash something like

for file in /usr/local/bin/*.pl ; do
  alias ${file%.pl}="/usr/bin/perl $file"
done

should do the job.

jshields wrote on Fri May 27 20:30:24 MEST 2005:

Have there been any updates to this issue? Any viable work arounds?

Thanks!

pacanukeha wrote on Fri May 27 21:15:24 MEST 2005:

M7 is supposed to support mime types.  Now.  How to we register #!/usr/bin/perl
as a mime type :)

paul_l_allen wrote on Fri Jul  8 20:53:40 MEST 2005:

I was amused to discover that EPIC did absolutely nothing
interesting until I renamed my script with a .pl extension.
As far as I know, ".pl" is a long-abandoned designation for
the old "perl library" concept in perl 4.  It's ancient history.

It is surprising that modern software like Eclipse remains
bound by obsolete notions like filename extensions that
determine file types.  Should I expect any progress on this
if I migrate to the latest version of Eclipse?  I'm currently
running 3.0 with the testing version of the perl plugin.

pguzis wrote on Fri Jul  8 23:09:58 MEST 2005:

File extensions are still very much alive.  Contrary to what some might
want to believe, their use is not just limited to Windows.  File extensions
provide a simple, fast, and *portable* way to identify the type of a file
without having to inspect its contents first.

In this case, the file extensions are used by Eclipse, not EPIC, to determine
which editor should handle a file.  To see and/or change which editors are
assigned to each file type, open "Window -> Preferences -> Editors -> File
Associations".

A suggestion: try to be a bit more constructive next time.  The phrasing
of your message comes across as smug and borderline elitist.  If you stick
with the same approach, don't expect too many thoughtful replies.

paul_l_allen wrote on Sat Jul  9 01:03:45 MEST 2005:

Interesting.  The need for filename extensions went away
before the release of 7th Edition Unix with the invention of
the file(1) command and the /etc/magic database.  They're
still convenient for some kinds of files, but have never been
necessary for perl scripts.  Sorry if that sounds smug or
elitist.  I'm just used to software working for me, not the
other way around.  I expected a modern system like
Eclipse to be more, well, modern.

Thanks for noting that the problem is with Eclipse and not
with EPIC.  I'll go over there and start poking around.

tshinnic wrote on Sat Jul  9 00:52:13 MEST 2005:

There is since Eclipse 3.0 an API to allow plugins to register 'describer's.
 These can be called when opening a file to read the file contents and see
if the file matches a particular "content type" (another posting here wrongly
called it "mime type")

It looks like this addon feature (if the API works) should be 'easy' to
add to EPIC.  Only problem with it is that EPIC would then become Eclipse
version dependent?  How bad would it be to do that, anyway?

paul_l_allen wrote on Sat Jul  9 03:01:21 MEST 2005:

Ah!  That makes sense.  I went and grabbed the platform-core
stuff from the Eclipse CVS repository, but didn't find anything
about mime in there.  Lots of stuff about describers, though.
So perhaps the next step is to snarf the EPIC sources and
see if anything can be done.

tshinnic wrote on Tue Jul 12 06:36:08 MEST 2005:

Hmm, don't hold your breath.  After working up a stub 'describer', I'm now
flailing about trying to develop a test case that shows that Eclipse 3.1
doesn't understand the combination of 'describers' and filenames without
extensions.  I've gotten to where changing one of their (Eclipse's) JUnit
tests to remove the extension from a filename forces a failure.  More later...
 

jploski wrote on Fri Sep  9 00:31:02 MEST 2005:

You are correct. What we are looking for is presently not possible via Eclipse's
"content types" aka IContentDescriber. See my comments at

https://sourceforge.net/tracker/index.php?func=detail&aid=1256145&group_id=75859&atid=545277

uherbst wrote on Wed Aug 10 22:01:31 MEST 2005:

Is anyone working on this ?

I've got the same problem...

illvilja wrote on Thu Sep  8 13:09:26 MEST 2005:

Just wanted to provide yet another case of when it is very, very valuable
to have the Eclipse/EPIC framework (or any debugger) to properly identify
executable Perl scripts as just executable Perl scripts, regardless of the
name of those scripts.

There are for Linux/UNIX "off the shelf" products out there written in perl
(both commercial and open source) and for those products to work properly,
you oft.b cannot rename the files that miss the .pl extension to ensure
their names include it.  Often you break the application and in some cases
the Perl scripts in question might even be read only installed in the Linux/Unix
system by the system administrators.

I can imagine many cases when you want to use a debugger to work with those
scripts  (yes, even if the scripts are bug-free as you see it) but two main
cases stand out that I have encountered in my job:

1.)  You need to understand the mechanics of the code for one reason or
another (and there are many very valid such reasons).  In addition to print
out the Perl code and read it carefully, running the code through a Perl
debugger session and go study it's execution step by step speeds up the
understanding of the code's mechanics tremendously.

2.)  You are going to actually carry out some development of the code (for
instance, adapting it to your local needs or  implementing some feature
you want to contribute to the product) and the use of a debugger in that
situation is obvious (unless you do really trivial changes to the code).

In both these situations, if there are perl scripts missing the .pl extension
I need to run step by step or I need to carry out development, then Eclipse/EPIC
as they stand today cannot be used.  The ability to identify a Perl executable
is a very basic functionality and I have to say that I hardly find it to
be a elitistic point of view to state that it IS problematic that such a
modern and highly advanced IDE framework as Eclipse/EPIC fails to carry
out that basic task.


So, how could we fix this?  There are several ways mentioned (that Eclipse/EPIC
reads the first line and makes it's conclusions) but one very basic way
I would consider valuable is to give the developer the option of explicitly
defining what kind of file the file added to the project is.  It can be
done when adding the file, as an extra option and it can be an option in
the "Properties" dialog for the file.

This ability for explicitly defining the type of a file is very useful for
all kinds of programming languages where the script can be explicitly fed
into the interpreter, eg by executing

perl scriptfile

on the command line.  "scriptfile" IS a perl script and it is that even
if it happens to miss a "#!" statement at the start and a .pl suffix.  Hence
the need in that case to be able to explicitly tell Eclipse that "Yes, this
is indeed a Perl script".

Any thoughts about this?

Best regards

/IllvilJa