[33124] in Perl-Users-Digest
Perl-Users Digest, Issue: 4400 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Mar 26 14:09:19 2015
Date: Thu, 26 Mar 2015 11:09:05 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 26 Mar 2015 Volume: 11 Number: 4400
Today's topics:
Re: running Perl scripts w/o extension on Windows 7 jomarbueyes@hotmail.com
Re: running Perl scripts w/o extension on Windows 7 jomarbueyes@hotmail.com
Re: running Perl scripts w/o extension on Windows 7 <kaz@kylheku.com>
Re: running Perl scripts w/o extension on Windows 7 <m@rtij.nl.invlalid>
Re: running Perl scripts w/o extension on Windows 7 <gamo@telecable.es>
Re: running Perl scripts w/o extension on Windows 7 <kaz@kylheku.com>
Re: running Perl scripts w/o extension on Windows 7 <gamo@telecable.es>
Re: running Perl scripts w/o extension on Windows 7 <rweikusat@mobileactivedefense.com>
Re: running Perl scripts w/o extension on Windows 7 <jurgenex@hotmail.com>
Re: running Perl scripts w/o extension on Windows 7 <kaz@kylheku.com>
Re: running Perl scripts w/o extension on Windows 7 <gamo@telecable.es>
Re: running Perl scripts w/o extension on Windows 7 <kaz@kylheku.com>
Re: running Perl scripts w/o extension on Windows 7 <greg.at.softsprocket@dot.com>
Re: running Perl scripts w/o extension on Windows 7 <rweikusat@mobileactivedefense.com>
Re: running Perl scripts w/o extension on Windows 7 <bauhaus@futureapps.invalid>
Re: running Perl scripts w/o extension on Windows 7 <greg.at.softsprocket@dot.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 25 Mar 2015 13:56:07 -0700 (PDT)
From: jomarbueyes@hotmail.com
Subject: Re: running Perl scripts w/o extension on Windows 7
Message-Id: <eede8f54-2897-4951-867b-10b055964dff@googlegroups.com>
On Wednesday, March 25, 2015 at 3:15:48 PM UTC-4, Greg Martin wrote:
> On 2015-03-25, jomar bueyes at h o t m a i l dot c o m wrote:
> > On Wednesday, March 25, 2015 at 11:16:55 AM UTC-4, Kaz Kylheku wrote:
> >> On 2015-03-25, jomarbueyes at overheated mail dot com <> wrote:
> >> > On Wednesday, March 25, 2015 at 2:46:19 AM UTC-4, Kaz Kylheku wrote:
> >> >> On 2015-03-25, gamo <e-mail address removed> wrote:
> >> >> > El 24/03/15 a las 18:00, escribi=F3:
> >> >> >> I wrote several Perl scripts under Linux (using X11 on Mac OS X)=
. Because Linux does not require an extension, I did not use one.
> >> >> >
> >> >> > Wrong. You can not relay in a location in a directory or a fancy =
name.=20
> >> >> > If it's a perl script, what do you save for not putting the propp=
er .pl=20
> >> >> > name extension?
> >> >>=20
> >> >> You prevent the situation that a foo.pl program is written in Pytho=
n,
> >> >> because the name had to be retained for compatibility when it was
> >> >> rewritten in a different language.
> >> >>=20
> >> >> You save the user from having to type some junk after the program
> >> >> name.
> >> >>=20
> >> >> You know how many OSS programs have a configure script, and how it
> >> >> isn't called "configure.sh"? Doesn't bother anyone.
> >> >> You can write that in some language other than the shell, and nobod=
y is the
> >> >> wiser (unless they don't have that language installed).
> >> >>=20
> >> >> > When the scripts grown in number, and you can't remember which is=
which,=20
> >> >> > it will save you time.
> >> >>=20
> >> >> Your ls program will show you which files are executable, at a glan=
ce.
> >> >
> >> > Hi Kaz,
> >> >
> >> > You do get the idea I'm after. Basically, using Perl (or, as you men=
tion,
> >> > Python) scripts w/o the need to either append an extension or prepen=
d the
> >> > 'perl' command. Thus far, it seems that the only choice to be able t=
o use
> >>=20
> >> No program on Windows can be run without an extension, period. Everyth=
ing
> >> in your C:\Windows\System32 has an extension.
> >>=20
> >> These extensions, like .bat and .exe, of course are "hidden" from user=
s
> >> who are using Explorer, and do not have to be included when invoking
> >> the programs from a command line.
> >>=20
> >> > only the command name is to install some variation of Unix/Linux on =
top of
> >> > Windows and just use plain Linux.
> >>=20
> >> Backwards, ante-deluvial handling of executables: just one of the many=
reasons
> >> to ditch Windows.
> >>=20
> >> By the way, I seem to recall modern Windows (the kernel) will execute =
files
> >> which have no suffix. That is to say, it's not a limitation in the
> >> CreateProcess kernel.dll function. And Windows does have detailed perm=
issions
> >> on files, at least under NTFS.
> >>=20
> >> It's a problem in the Explorer shell and CMD.EXE.
> >>=20
> >> See for instance this:
> >>=20
> >> http://stackoverflow.com/questions/12655314/open-an-executable-file-wi=
thout-an-exe-extension-with-shellexecute
> >>=20
> >> According to the accepted answer, the shell *can* be coaxed into execu=
ting a
> >> suffix-less file, if you call it directly in C with your ShellExecuteE=
x API.
> >>=20
> >> Of course, even though CreateProcess will execute a suffix-less file, =
it still
> >> lacks the #! (shebang) mechanism for choosing an arbitrary interpreter=
for it.
> >>=20
> >> In practice, what this means is that when "stand-alone executables" ar=
e
> >> produced from scripting languages, this means creating an ordinary mac=
hine
> >> language executable (actual binary .exe), or a batch file wrapper.
> >>=20
> >> The .exe can be a wrapper, or it can actually contain the entire inter=
preter,
> >> with the script appended to it. A wrapper .exe could contain a much sm=
aller
> >> binary program (not the entire interpreter) with the script appended t=
o it;
> >> whose job is to retrieve the script and pass it to the real interprete=
r.
> >
> > Hi Kaz,
> >
> > Thank you for your response and for the link. I'll certainly take a loo=
k. Your suggestion is somewhat similar to Henry Law's of using a .bat wrapp=
er whose only content is something 'perl' followed by the name of the Perl =
script it's wrapping.
> >
> > Thank you again,
> >
> > Jomar
>=20
> I couldn't help but wonder if MSWindows would have some form of
> commandline aliasing. I don't use MSWindows and so apologize if this is
> somewhere out in left field but a web search did find this:
> https://msdn.microsoft.com/en-us/library/windows/desktop/ms682057%28v=3Dv=
s.85%29.aspx
>=20
> --=20
> http://www.softsprocket.com
Hi Greg,=20
Thank you for your suggestion. I checked the link and this might be another=
possible workaround. Although not exactly as suggested in the linked page.=
The example includes a 'cd' to the directory where the command is, which i=
s seldom desirable. I'll investigate whether the alias can be the full path=
to the command.
Thanks again,
Jomar
------------------------------
Date: Wed, 25 Mar 2015 14:06:39 -0700 (PDT)
From: jomarbueyes@hotmail.com
Subject: Re: running Perl scripts w/o extension on Windows 7
Message-Id: <1f96b1d6-7589-444f-95c9-1197126d61cd@googlegroups.com>
On Wednesday, March 25, 2015 at 3:14:34 PM UTC-4, gamo wrote:
> El 25/03/15 a las 19:50, Martijn Lievaart escribi=F3:
> > On Wed, 25 Mar 2015 18:00:10 +0100, gamo wrote:
> >
> >> If you want to confuse yourself with another scripts or programs, yes,
> >> you can. BTW to maintain on topic the discussion, would you mix your
> >> Perl 5 scripts with Perl 6 programs omitting the extension?
> >
> > Absolutely. And with my python scripts. And bash scripts. From the
> > outside I don't care what's inside and the extension is just useless
> > baggage. If I want to know what language it is written in, I use the
> > `file' command.
> >
> > M4
> >
>=20
> Ok, and if 'file' fails miserabily?
>=20
> :~/rakudo-star-2015.02$ file 6x6e.pl
> 6x6e.pl: OS/2 REXX batch file, ASCII text
>=20
>=20
> --=20
> http://www.telecable.es/personales/gamo/
> The generation of random numbers is too important to be left to chance
Hi Gamo,
We Linux/Unix users are spoiled in the way Martijn described. We group exec=
utables by their function, not by their type. A directory can contain compi=
led executables (from C, C++, Fortran, ...), Scripts written in Perl, Pytho=
n, any shell, ... . No need for extensions, the OS does not needs them (in =
fact a Python script with extension .pl does run).=20
Also, I'm puzzled by your=20
"and if 'file' fails miserably?".=20
If the OS finds the command, it tries to run it. If it does not run, there =
is a problem with the file, not with the OS. The same way as would happen u=
nder any operating system. On the other hand, if the OS does not find the c=
ommand, it is because either the command is not in a directory in the path =
variable or, if it is, it was placed there recently and all we need to do i=
s type 'rehash' and the command becomes available.
Thanks
Jomar
------------------------------
Date: Wed, 25 Mar 2015 21:13:35 +0000 (UTC)
From: Kaz Kylheku <kaz@kylheku.com>
Subject: Re: running Perl scripts w/o extension on Windows 7
Message-Id: <20150325135308.345@kylheku.com>
On 2015-03-25, Greg Martin <greg.at.softsprocket@dot.com> wrote:
> On 2015-03-25, jomarbueyes@hotmail.com <jomarbueyes@hotmail.com> wrote:
>> On Wednesday, March 25, 2015 at 11:16:55 AM UTC-4, Kaz Kylheku wrote:
>> Hi Kaz,
>>
>> Thank you for your response and for the link. I'll certainly take a look.
>> Your suggestion is somewhat similar to Henry Law's of using a .bat wrapper
>> whose only content is something 'perl' followed by the name of the Perl
>> script it's wrapping.
>>
>> Thank you again,
>>
>> Jomar
>
> I couldn't help but wonder if MSWindows would have some form of
> commandline aliasing. I don't use MSWindows and so apologize if this is
> somewhere out in left field but a web search did find this:
> https://msdn.microsoft.com/en-us/library/windows/desktop/ms682057%28v=vs.85%29.aspx
We could really use a utility of this form:
C:\> winbang.exe <output.exe> {<argument>}*
The requirements for "Winbang" is that it produces a small executable file
which wraps up a scripinclude t written in an arbitrary language, together with
a relative or full path to that script's interpreter:
C:\> winbang.exe <output.exe> <interpreter> <script>
The output exe file is a real machine-language binary, which opens itself
as a file, and look for some appended info. In the appended info is
a header structure which provides various bits of information, followed
by the script. The program writes the script out to a file, and then
passes the name of this file to <interpreter> as the command line argument.
When the interpreter terminates, the file is removed.
Additional embellishments:
C:\> winbang.exe <output.exe> <interpreter> <script> <cmdline>
<cmdline> overrides the default command line (which consists of the temp
file). It could have a syntax indicating "insert the full path name of the
script here". E.g. "-f % -z", means insert the full path to the temporary
script file in place of the %. Something more general could be done:
several different variables. For instance, the script might want to know
in what directory <output.exe> is located so it can find other adjacent files
to load; there could be syntax for interpolating that into the command line.
Furthermore:
C:\> winbang.exe /gui /i16 <16x16-icon-file> /i32... /fileversion ...
Winbang's arguments could specify resources for the generated <output.exe>:
like whether it is a GUI or console mode appliaction, and some important
resources like icons and certain string.
This way in a single invocation of wingbang.exe you could wrap a script to look
like a proper executable with its own icon in multiple resolutions, version
info, your name, and whatnot.
------------------------------
Date: Thu, 26 Mar 2015 09:37:37 +0100
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: running Perl scripts w/o extension on Windows 7
Message-Id: <h3tcub-qmm.ln1@news.rtij.nl>
On Wed, 25 Mar 2015 20:14:09 +0100, gamo wrote:
> El 25/03/15 a las 19:50, Martijn Lievaart escribió:
>> On Wed, 25 Mar 2015 18:00:10 +0100, gamo wrote:
>>
>>> If you want to confuse yourself with another scripts or programs, yes,
>>> you can. BTW to maintain on topic the discussion, would you mix your
>>> Perl 5 scripts with Perl 6 programs omitting the extension?
>>
>> Absolutely. And with my python scripts. And bash scripts. From the
>> outside I don't care what's inside and the extension is just useless
>> baggage. If I want to know what language it is written in, I use the
>> `file' command.
>>
>> M4
>>
>>
> Ok, and if 'file' fails miserabily?
>
> :~/rakudo-star-2015.02$ file 6x6e.pl 6x6e.pl: OS/2 REXX batch file,
> ASCII text
Then you should adhere to sane standards instead of relying on file
extensions. (That, or file a bug).
Even then, what is so interesting about what language a script is written
in? I'm still grasping to see why you would want this arrangement of
yours.
M4
------------------------------
Date: Thu, 26 Mar 2015 12:48:14 +0100
From: gamo <gamo@telecable.es>
Subject: Re: running Perl scripts w/o extension on Windows 7
Message-Id: <mf0rls$6d2$1@speranza.aioe.org>
El 26/03/15 a las 09:37, Martijn Lievaart escribió:
> On Wed, 25 Mar 2015 20:14:09 +0100, gamo wrote:
>
>> El 25/03/15 a las 19:50, Martijn Lievaart escribió:
>>> On Wed, 25 Mar 2015 18:00:10 +0100, gamo wrote:
>>>
>>>> If you want to confuse yourself with another scripts or programs, yes,
>>>> you can. BTW to maintain on topic the discussion, would you mix your
>>>> Perl 5 scripts with Perl 6 programs omitting the extension?
>>>
>>> Absolutely. And with my python scripts. And bash scripts. From the
>>> outside I don't care what's inside and the extension is just useless
>>> baggage. If I want to know what language it is written in, I use the
>>> `file' command.
>>>
>>> M4
>>>
>>>
>> Ok, and if 'file' fails miserabily?
>>
>> :~/rakudo-star-2015.02$ file 6x6e.pl 6x6e.pl: OS/2 REXX batch file,
>> ASCII text
>
> Then you should adhere to sane standards instead of relying on file
> extensions. (That, or file a bug).
>
Sane standard is C, where filename.c means one thing, and filename.h
other.
> Even then, what is so interesting about what language a script is written
> in? I'm still grasping to see why you would want this arrangement of
> yours.
>
An extension defines content and function, and is useful not only
for scripts but to other kind of files, with different formats
(audio, video, pictures, documents, spreadsheets, etc.)
As an example, when I open a new file.pl with my editor, yet it's
ready in Perl mode for propper indentation and highlight. Useful.
> M4
>
--
http://www.telecable.es/personales/gamo/
The generation of random numbers is too important to be left to chance
------------------------------
Date: Thu, 26 Mar 2015 13:59:18 +0000 (UTC)
From: Kaz Kylheku <kaz@kylheku.com>
Subject: Re: running Perl scripts w/o extension on Windows 7
Message-Id: <20150326064455.404@kylheku.com>
On 2015-03-26, gamo <gamo@telecable.es> wrote:
> El 26/03/15 a las 09:37, Martijn Lievaart escribió:
>> On Wed, 25 Mar 2015 20:14:09 +0100, gamo wrote:
>>
>>> El 25/03/15 a las 19:50, Martijn Lievaart escribió:
>>>> On Wed, 25 Mar 2015 18:00:10 +0100, gamo wrote:
>>>>
>>>>> If you want to confuse yourself with another scripts or programs, yes,
>>>>> you can. BTW to maintain on topic the discussion, would you mix your
>>>>> Perl 5 scripts with Perl 6 programs omitting the extension?
>>>>
>>>> Absolutely. And with my python scripts. And bash scripts. From the
>>>> outside I don't care what's inside and the extension is just useless
>>>> baggage. If I want to know what language it is written in, I use the
>>>> `file' command.
>>>>
>>>> M4
>>>>
>>>>
>>> Ok, and if 'file' fails miserabily?
>>>
>>> :~/rakudo-star-2015.02$ file 6x6e.pl 6x6e.pl: OS/2 REXX batch file,
>>> ASCII text
>>
>> Then you should adhere to sane standards instead of relying on file
>> extensions. (That, or file a bug).
>>
> Sane standard is C, where filename.c means one thing, and filename.h
> other.
Strawman example.
C files are usually not executables shipped to end users. They are like
"application data" for your C compiler.
The discussion is about suffixes on executables.
Your C compiler executable is called "cc" or "gcc" in a sanely designed OS, not
"cc.exe", or "cc.pl".
I.e. no extensions on programs, only application data.
And not even always on application data.
There are plenty of examples of textual data in the free world which has no
suffix, even if it is in a special format or language: README; ChangeLog;
passwd; fstab; inittab; Makefile; tags; configure; ...
> An extension defines content and function, and is useful not only
Nonsense. It vaguely identifes.
> for scripts but to other kind of files, with different formats
> (audio, video, pictures, documents, spreadsheets, etc.)
Not really. Quick --- .MP4! What is the video codec? Audio codec?
There is such a proliferation of suffixes on media files, yet they hardly
tell you anything other than "I'm one of the fifty suffixes you have
to recognize to suspect that this is probably a video".
> As an example, when I open a new file.pl with my editor, yet it's
> ready in Perl mode for propper indentation and highlight. Useful.
A decent editor can figure this out anyway; for instance from the #!
line, or other clues. A suffix-less perl script will likely have this.
------------------------------
Date: Thu, 26 Mar 2015 15:12:47 +0100
From: gamo <gamo@telecable.es>
Subject: Re: running Perl scripts w/o extension on Windows 7
Message-Id: <mf144t$tj6$1@speranza.aioe.org>
El 26/03/15 a las 14:59, Kaz Kylheku escribió:
> The discussion is about suffixes on executables.
Your discussion. Since when a script is a executable?
--
http://www.telecable.es/personales/gamo/
The generation of random numbers is too important to be left to chance
------------------------------
Date: Thu, 26 Mar 2015 14:42:34 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: running Perl scripts w/o extension on Windows 7
Message-Id: <87sicrbz1h.fsf@doppelsaurus.mobileactivedefense.com>
gamo <gamo@telecable.es> writes:
> El 26/03/15 a las 14:59, Kaz Kylheku escribió:
>> The discussion is about suffixes on executables.
>
> Your discussion. Since when a script is a executable?
Abstractly, considering that it's executed, since ever. Specifically,
since about 1980, assuming a sufficiently capable system. The Windows
CLI environment only supports the anachronism of a special 'system
interpreter' and only scripts written in the language understood by that
are considered 'executable' but that's just an anachronism.
------------------------------
Date: Thu, 26 Mar 2015 07:50:53 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: running Perl scripts w/o extension on Windows 7
Message-Id: <2278ha5f300icgjltf25t32robm5ie4jfm@4ax.com>
gamo <gamo@telecable.es> wrote:
>El 26/03/15 a las 14:59, Kaz Kylheku escribió:
>> The discussion is about suffixes on executables.
>
>Your discussion. Since when a script is a executable?
Oh, my guess would be since somewhere around the 60s of the last
century.
Or definitely since the 70s the very latest, because since then they got
the 'x' flag in the file status.
jue.
------------------------------
Date: Thu, 26 Mar 2015 14:51:50 +0000 (UTC)
From: Kaz Kylheku <kaz@kylheku.com>
Subject: Re: running Perl scripts w/o extension on Windows 7
Message-Id: <20150326075039.121@kylheku.com>
On 2015-03-26, gamo <gamo@telecable.es> wrote:
> El 26/03/15 a las 14:59, Kaz Kylheku escribió:
>> The discussion is about suffixes on executables.
>
> Your discussion. Since when a script is a executable?
Oh, I would say, the discussion has been about a script being executable
ever since ... that time someone put "running Perl scripts w/o extension"
in the fucking subject line!
------------------------------
Date: Thu, 26 Mar 2015 15:58:04 +0100
From: gamo <gamo@telecable.es>
Subject: Re: running Perl scripts w/o extension on Windows 7
Message-Id: <mf16pq$4gu$1@speranza.aioe.org>
El 26/03/15 a las 15:42, Rainer Weikusat escribió:
> gamo <gamo@telecable.es> writes:
>> El 26/03/15 a las 14:59, Kaz Kylheku escribió:
>>> The discussion is about suffixes on executables.
>>
>> Your discussion. Since when a script is a executable?
>
> Abstractly, considering that it's executed, since ever. Specifically,
> since about 1980, assuming a sufficiently capable system. The Windows
> CLI environment only supports the anachronism of a special 'system
> interpreter' and only scripts written in the language understood by that
> are considered 'executable' but that's just an anachronism.
>
To consider a script file executable there is needed the OS
cooperation to change file mode bits. Before that, you have
a text file interpretable. There is a matter of taste to
chmod +x a script or not. I prefer to not, so leave me alone.
--
http://www.telecable.es/personales/gamo/
The generation of random numbers is too important to be left to chance
------------------------------
Date: Thu, 26 Mar 2015 15:18:28 +0000 (UTC)
From: Kaz Kylheku <kaz@kylheku.com>
Subject: Re: running Perl scripts w/o extension on Windows 7
Message-Id: <20150326081348.532@kylheku.com>
On 2015-03-26, gamo <gamo@telecable.es> wrote:
> El 26/03/15 a las 15:42, Rainer Weikusat escribió:
>> gamo <gamo@telecable.es> writes:
>>> El 26/03/15 a las 14:59, Kaz Kylheku escribió:
>>>> The discussion is about suffixes on executables.
>>>
>>> Your discussion. Since when a script is a executable?
>>
>> Abstractly, considering that it's executed, since ever. Specifically,
>> since about 1980, assuming a sufficiently capable system. The Windows
>> CLI environment only supports the anachronism of a special 'system
>> interpreter' and only scripts written in the language understood by that
>> are considered 'executable' but that's just an anachronism.
>>
>
> To consider a script file executable there is needed the OS
> cooperation to change file mode bits. Before that, you have
> a text file interpretable. There is a matter of taste to
> chmod +x a script or not.
Nobody said that every Perl file should not have a suffix.
If you have a Perl program made up of multiple files, only
the one which is used to invoke it can be made "suffix-free";
all the rest have ".pl" on them.
> I prefer to not, so leave me alone.
An excellent way to achieve the total absence of criticism for your preferences
is not to discuss them with anyone.
(Another way, almost as good, is to discuss them only with people who are too
intimidated to criticize you.)
------------------------------
Date: Thu, 26 Mar 2015 15:19:30 GMT
From: Greg Martin <greg.at.softsprocket@dot.com>
Subject: Re: running Perl scripts w/o extension on Windows 7
Message-Id: <6sVQw.119580$yX2.34449@fx18.iad>
On 2015-03-26, gamo <gamo@telecable.es> wrote:
> El 26/03/15 a las 09:37, Martijn Lievaart escribió:
>> On Wed, 25 Mar 2015 20:14:09 +0100, gamo wrote:
>>
>>> El 25/03/15 a las 19:50, Martijn Lievaart escribió:
>>>> On Wed, 25 Mar 2015 18:00:10 +0100, gamo wrote:
>>>>
>>>>> If you want to confuse yourself with another scripts or programs, yes,
>>>>> you can. BTW to maintain on topic the discussion, would you mix your
>>>>> Perl 5 scripts with Perl 6 programs omitting the extension?
>>>>
>>>> Absolutely. And with my python scripts. And bash scripts. From the
>>>> outside I don't care what's inside and the extension is just useless
>>>> baggage. If I want to know what language it is written in, I use the
>>>> `file' command.
>>>>
>>>> M4
>>>>
>>>>
>>> Ok, and if 'file' fails miserabily?
>>>
>>> :~/rakudo-star-2015.02$ file 6x6e.pl 6x6e.pl: OS/2 REXX batch file,
>>> ASCII text
>>
>> Then you should adhere to sane standards instead of relying on file
>> extensions. (That, or file a bug).
>>
>
> Sane standard is C, where filename.c means one thing, and filename.h
> other.
>
>> Even then, what is so interesting about what language a script is written
>> in? I'm still grasping to see why you would want this arrangement of
>> yours.
>>
>
> An extension defines content and function, and is useful not only
> for scripts but to other kind of files, with different formats
> (audio, video, pictures, documents, spreadsheets, etc.)
>
> As an example, when I open a new file.pl with my editor, yet it's
> ready in Perl mode for propper indentation and highlight. Useful.
>
>
bytes.dat
It's easy to see why .dat would be a popular extension. It does
exemplify one problem, a problem easily solved by a header of some sort
and an application that checks for it.
I see nothing wrong with file extensions unless everyone has to have one.
--
http://www.softsprocket.com
------------------------------
Date: Thu, 26 Mar 2015 15:22:16 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: running Perl scripts w/o extension on Windows 7
Message-Id: <87h9t7bx7b.fsf@doppelsaurus.mobileactivedefense.com>
gamo <gamo@telecable.es> writes:
> El 26/03/15 a las 15:42, Rainer Weikusat escribió:
>> gamo <gamo@telecable.es> writes:
>>> El 26/03/15 a las 14:59, Kaz Kylheku escribió:
>>>> The discussion is about suffixes on executables.
>>>
>>> Your discussion. Since when a script is a executable?
>>
>> Abstractly, considering that it's executed, since ever. Specifically,
>> since about 1980, assuming a sufficiently capable system. The Windows
>> CLI environment only supports the anachronism of a special 'system
>> interpreter' and only scripts written in the language understood by that
>> are considered 'executable' but that's just an anachronism.
>
> To consider a script file executable there is needed the OS
> cooperation to change file mode bits.
This is true for a file with any kind of content: If the 'execute
permission' bits of the i-node referring to it are clear, execve will
fail with EACCES when called with this file as argument, otherwise, it
won't. It may be possible to execute the file in some other way, eg,
,----
| [rw@doppelsaurus]/tmp#cat >a.c
| #include <stdio.h>
|
| int main(void)
| {
| puts("Kamelle!");
| return 0;
| }
| [rw@doppelsaurus]/tmp#gcc a.c
| [rw@doppelsaurus]/tmp#chmod -x a.out
| [rw@doppelsaurus]/tmp#./a.out
| bash: ./a.out: Permission denied
| [rw@doppelsaurus]/tmp#/lib64/ld-linux-x86-64.so.2 ./a.out
| Kamelle!
`----
hence, it can rightfully be regarded as 'executable' regardless of the
permission bits.
Another definition of executable would be "file which could be executed
via execve".
> Before that, you have a text file interpretable. There is a matter of
> taste to chmod +x a script or not. I prefer to not, so leave me
> alone.
One could envision a policy which disallows passing any file to execve
on Saturdays (for hopefully obvious reasons) but this wouldn't lend
itself to the generalized conclusion that "on Saturdays, no files are
executable" ...
------------------------------
Date: Thu, 26 Mar 2015 16:57:07 +0100
From: "G.B." <bauhaus@futureapps.invalid>
Subject: Re: running Perl scripts w/o extension on Windows 7
Message-Id: <mf1a70$3g4$1@dont-email.me>
On 26.03.15 16:22, Rainer Weikusat wrote:
> Another definition of executable would be "file which could be executed
> via execve".
Or this:
"An executable file is a binary file that the processor can run.
These files typically have the .exe, .dll, or .sys file name
extension. Executable files are also known as modules, especially
when executable files are described as units of a larger application.
Before the Windows operating system runs an executable file, it loads
it into memory. The copy of the executable file in memory is called
the executable image or the image.
"Note These terms are sometimes used imprecisely. For example,
some documents might use "image" for the actual file on the disk."
https://msdn.microsoft.com/en-us/library/windows/hardware/hh439335(v=vs.85).aspx
Therefore, no script is executable.
Then, there is WSH, allegedly.
Didn't NT, via the registry, provide for associating either
file name extensions or extended attributes with a way of
running the files that have matching names or attributes?
------------------------------
Date: Thu, 26 Mar 2015 16:23:06 GMT
From: Greg Martin <greg.at.softsprocket@dot.com>
Subject: Re: running Perl scripts w/o extension on Windows 7
Message-Id: <KnWQw.98617$uF6.4965@fx17.iad>
On 2015-03-26, G.B. <bauhaus@futureapps.invalid> wrote:
> On 26.03.15 16:22, Rainer Weikusat wrote:
>
>> Another definition of executable would be "file which could be executed
>> via execve".
>
> Or this:
>
> "An executable file is a binary file that the processor can run.
> These files typically have the .exe, .dll, or .sys file name
> extension. Executable files are also known as modules, especially
> when executable files are described as units of a larger application.
> Before the Windows operating system runs an executable file, it loads
> it into memory. The copy of the executable file in memory is called
> the executable image or the image.
>
> "Note These terms are sometimes used imprecisely. For example,
> some documents might use "image" for the actual file on the disk."
>
> https://msdn.microsoft.com/en-us/library/windows/hardware/hh439335(v=vs.85).aspx
>
> Therefore, no script is executable.
Well, a script is a binary file and a processor can run it in
conjunction with an interpretor. Any relocatable code will require a
loader and other OS support so while the description may /wish/ to
exclude scripts as executables, I don't see that it does.
I am aware that MSWindows does differentiate between text and binary
files but it is an artifice.
--
http://www.softsprocket.com
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 4400
***************************************
