[33123] in Perl-Users-Digest

home help back first fref pref prev next nref lref last post

Perl-Users Digest, Issue: 4399 Volume: 11

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Mar 25 16:09:18 2015

Date: Wed, 25 Mar 2015 13: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           Wed, 25 Mar 2015     Volume: 11 Number: 4399

Today's topics:
    Re: An error on page 142 of The Camel Book. <bauhaus@futureapps.invalid>
    Re: An error on page 142 of The Camel Book. <bauhaus@futureapps.invalid>
    Re: An error on page 142 of The Camel Book. <rweikusat@mobileactivedefense.com>
    Re: An error on page 142 of The Camel Book. <rweikusat@mobileactivedefense.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 jomarbueyes@hotmail.com
    Re: running Perl scripts w/o extension on Windows 7 <rweikusat@mobileactivedefense.com>
    Re: running Perl scripts w/o extension on Windows 7 <kaz@kylheku.com>
    Re: running Perl scripts w/o extension on Windows 7 <jurgenex@hotmail.com>
    Re: running Perl scripts w/o extension on Windows 7 <gamo@telecable.es>
    Re: running Perl scripts w/o extension on Windows 7 <news@lawshouse.org>
    Re: running Perl scripts w/o extension on Windows 7 <m@rtij.nl.invlalid>
    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 <gamo@telecable.es>
    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 15:34:49 +0100
From: "G.B." <bauhaus@futureapps.invalid>
Subject: Re: An error on page 142 of The Camel Book.
Message-Id: <meuh0j$bj3$1@dont-email.me>

On 24.03.15 18:27, Rainer Weikusat wrote:

>> "I'd like a loop (one of two) that, I think, would be sufficiently
>> different. It can be left at only one point such that:
>>
>>   - this point is syntactically identifiable
>>   - there is only one piece of syntax for that
>>   - the loop never needs dummy variables"
>>
>> 0. This kind of loop should have one exit.
>
> As I already tried to point out: Any looping-construct satisfies this
> condition because the exit point is always after the loop body.

Actually, no, because ...

> That's
> something other than code causing the loop to exit, either explicitly
> because a loop control verb was being user or implicitly because the
> state of the loop condition changed in a way which causes it to exit.
> That's something you can have in any language today by simply not using
> the any facility

 ... well, Humpty-Dumptying aside :-). I had been expressing a wish
for a loop that removes these very needs through providing syntax
in the language, facilitating suitable semantics.

A point where a loop is left is something that syntax
can describe. This description removes the need to think
about causation. Much like a map can show exits from
a loop around (51.404796, 5.502472).

Suppose some language had a Dijkstraian flowchart style
while loop (cf. loc. cit.) and such that no control verb
may occur in its block. Then, for example:

(if (search-forward-regexp "while\s*(")
   (progn (backward-char 1)
          (forward-sexp)
          (message "Point: %d" (point))))

may identify(!) a point(!) in the source text, by way
of syntax(!) analysis: here is where I can point my
finger. No run of the program is needed for knowing
that the program may exit here from this loop, but
not anywhere else.



------------------------------

Date: Wed, 25 Mar 2015 15:50:49 +0100
From: "G.B." <bauhaus@futureapps.invalid>
Subject: Re: An error on page 142 of The Camel Book.
Message-Id: <meuhuk$fci$1@dont-email.me>

On 24.03.15 19:44, Peter J. Holzer wrote:
> I have occasionally written loops where there is exactly one exit point
> and it is somewhere in the middle. I'm not convinced that such loops are
> frequent enough to warrant a special syntax.

These loops (also "ideal"?) have one useful property, I think:
If they exist alongside a more general looping construct,
then, on average, it may be easier to establish their
variant and their invariant. If anyone ever does that in
a Perl program.

Eiffel has an approximation, but may require dummy variables
(last time I looked):

from
    ...
until
    ...
loop
    ...
end


One may put an invariant before "until" and a variant
before "end".



------------------------------

Date: Wed, 25 Mar 2015 15:44:09 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: An error on page 142 of The Camel Book.
Message-Id: <87h9t92iba.fsf@doppelsaurus.mobileactivedefense.com>

"G.B." <bauhaus@futureapps.invalid> writes:
> On 24.03.15 19:44, Peter J. Holzer wrote:
>> I have occasionally written loops where there is exactly one exit point
>> and it is somewhere in the middle. I'm not convinced that such loops are
>> frequent enough to warrant a special syntax.
>
> These loops (also "ideal"?) have one useful property, I think:
> If they exist alongside a more general looping construct,
> then, on average, it may be easier to establish their
> variant and their invariant. If anyone ever does that in
> a Perl program.
>
> Eiffel has an approximation, but may require dummy variables
> (last time I looked):

That's a problem you can't escape in a model based on steps taken
sequentially which may affect state changes regardless of what other
steps did: If a particular operation is restricted to a certain step in
the sequence but another step causes a state change requiring the
operation to be performed, all which can be done is record the fact that
the state did change and postpone the operation until the special step
happens again, IOW, code a workaround to cope with the bureaucratically
required procedure which wouldn't be necessary for solving the problem
without it.

NB: Anything which might look like terminology in the paragraph above is
something I made up on the spot while trying to express this.



------------------------------

Date: Wed, 25 Mar 2015 15:47:58 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: An error on page 142 of The Camel Book.
Message-Id: <87d23x2i4x.fsf@doppelsaurus.mobileactivedefense.com>

"G.B." <bauhaus@futureapps.invalid> writes:
> On 24.03.15 18:27, Rainer Weikusat wrote:
>>> "I'd like a loop (one of two) that, I think, would be sufficiently
>>> different. It can be left at only one point such that:
>>>
>>>   - this point is syntactically identifiable
>>>   - there is only one piece of syntax for that
>>>   - the loop never needs dummy variables"
>>>
>>> 0. This kind of loop should have one exit.
>>
>> As I already tried to point out: Any looping-construct satisfies this
>> condition because the exit point is always after the loop body.
>
> Actually, no, because ...
>
>> That's
>> something other than code causing the loop to exit, either explicitly
>> because a loop control verb was being user or implicitly because the
>> state of the loop condition changed in a way which causes it to exit.
>> That's something you can have in any language today by simply not using
>> the any facility
>
> ... well, Humpty-Dumptying aside :-). I had been expressing a wish
> for a loop that removes these very needs through providing syntax
> in the language, facilitating suitable semantics.
>
> A point where a loop is left is something that syntax
> can describe. This description removes the need to think
> about causation. Much like a map can show exits from
> a loop around (51.404796, 5.502472).
>
> Suppose some language had a Dijkstraian flowchart style
> while loop (cf. loc. cit.) and such that no control verb
> may occur in its block. Then, for example:
>
> (if (search-forward-regexp "while\s*(")
>   (progn (backward-char 1)
>          (forward-sexp)
>          (message "Point: %d" (point))))
>
> may identify(!) a point(!) in the source text, by way
> of syntax(!) analysis:

If you can identify 'whiles', you could obviously also identify 'lasts'.
It's possibly to fake something like this in Perl (code below dedicated
to Leroy Carr whose "Christmas in jail - ain't that a pain" blues
inspired the names):

----
sub while_not_atoned_for (&@)
{
    my ($cond, $task) = @_;

    {
	last unless $cond->();
	
	{ $task->() };
	redo;
    }
}

sub run_in_circles(&@)
{
    my ($task, $cond) = @_;

    return $task unless $cond;

    {
	{ $task->() }
	redo unless $cond->();
    }
}

sub until_pardoned_by(&)
{
    @_;
}

my ($iw, $ir);

while_not_atoned_for { $iw < 10 }
run_in_circles {
    print($iw++, "\n");
};

run_in_circles {
    print($ir++, "\n");
} until_pardoned_by { $ir == 10 };
-----

Alternatively, a BEGIN block like this

-----
BEGIN {
    use Opcode qw(opmask_add opset);
    opmask_add(opset(qw(last next redo goto)));
}
-----

could be used which will turn any attempt to use last, next, redo or
goto into a compile-time error.


------------------------------

Date: Wed, 25 Mar 2015 06:53:03 +0100
From: gamo <gamo@telecable.es>
Subject: Re: running Perl scripts w/o extension on Windows 7
Message-Id: <metigh$6jj$1@speranza.aioe.org>

El 24/03/15 a las 18:00, jomarbueyes@hotmail.com escribió:
> 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. 
If it's a perl script, what do you save for not putting the propper .pl 
name extension?

When the scripts grown in number, and you can't remember which is which, 
it will save you time.

-- 
http://www.telecable.es/personales/gamo/
The generation of random numbers is too important to be left to chance


------------------------------

Date: Wed, 25 Mar 2015 06:46:15 +0000 (UTC)
From: Kaz Kylheku <kaz@kylheku.com>
Subject: Re: running Perl scripts w/o extension on Windows 7
Message-Id: <20150324233819.399@kylheku.com>

On 2015-03-25, gamo <gamo@telecable.es> wrote:
> El 24/03/15 a las 18:00, jomarbueyes@hotmail.com escribió:
>> 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. 
> If it's a perl script, what do you save for not putting the propper .pl 
> name extension?

You prevent the situation that a foo.pl program is written in Python,
because the name had to be retained for compatibility when it was
rewritten in a different language.

You save the user from having to type some junk after the program
name.

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 nobody is the
wiser (unless they don't have that language installed).

> When the scripts grown in number, and you can't remember which is which, 
> it will save you time.

Your ls program will show you which files are executable, at a glance.


------------------------------

Date: Wed, 25 Mar 2015 06:49:07 -0700 (PDT)
From: jomarbueyes@hotmail.com
Subject: Re: running Perl scripts w/o extension on Windows 7
Message-Id: <274de83e-5915-4322-ae44-4e10448b9071@googlegroups.com>

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). Beca=
use 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 propper .pl=
=20
> > name extension?
>=20
> You prevent the situation that a foo.pl program is written in Python,
> 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 nobody is t=
he
> 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 glance.

Hi Kaz,

You do get the idea I'm after. Basically, using Perl (or, as you mention, P=
ython) scripts w/o the need to either append an extension or prepend the 'p=
erl' command. Thus far, it seems that the only choice to be able to use onl=
y the command name is to install some variation of Unix/Linux on top of Win=
dows and just use plain Linux.=20

Thank you again

@gamo
Thank you for your response. However, in Unix-type operating systems do rel=
y on the location of the commands via the path shell variable. Once the scr=
ipt is in a directory included in the path, as Kaz mentioned, it does not m=
atter what extension the it has. Unix-type OSs detect the file type by the =
so-called shebang at the beginning of the script (e.g. #!/usr/bin/perl for =
Perl scripts, #!/bin/csh for a C-shell script, ...). The user does not need=
 to know in what language the script is written. In fact, it is not unusual=
 to have scripts in different languages in a single directory.  Thank you f=
or your response. Saludos

Jomar



------------------------------

Date: Wed, 25 Mar 2015 14:51:22 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: running Perl scripts w/o extension on Windows 7
Message-Id: <87lhil2kr9.fsf@doppelsaurus.mobileactivedefense.com>

jomarbueyes@hotmail.com writes:
> 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ó:
>> >> 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. 
>> > If it's a perl script, what do you save for not putting the propper .pl 
>> > name extension?
>> 
>> You prevent the situation that a foo.pl program is written in Python,
>> because the name had to be retained for compatibility when it was
>> rewritten in a different language.
>> 
>> You save the user from having to type some junk after the program
>> name.
>> 
>> 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 nobody is the
>> wiser (unless they don't have that language installed).
>> 
>> > When the scripts grown in number, and you can't remember which is which, 
>> > it will save you time.
>> 
>> Your ls program will show you which files are executable, at a glance.
>
> Hi Kaz,
>
> You do get the idea I'm after. Basically, using Perl (or, as you
> mention, Python) scripts w/o the need to either append an extension or
> prepend the 'perl' command. Thus far, it seems that the only choice to
> be able to use only the command name is to install some variation of
> Unix/Linux on top of Windows and just use plain Linux.

Some trick I found on the internet (I haven't tested an which may not be
useful): Keep all your Windows Perl scripts in a certain directory and
use a .bat file which runs a script named like itself from this directory
via perl command.


------------------------------

Date: Wed, 25 Mar 2015 15:16:49 +0000 (UTC)
From: Kaz Kylheku <kaz@kylheku.com>
Subject: Re: running Perl scripts w/o extension on Windows 7
Message-Id: <20150325072642.853@kylheku.com>

On 2015-03-25, jomarbueyes@hotmail.com <jomarbueyes@hotmail.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ó:
>> >> 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. 
>> > If it's a perl script, what do you save for not putting the propper .pl 
>> > name extension?
>> 
>> You prevent the situation that a foo.pl program is written in Python,
>> because the name had to be retained for compatibility when it was
>> rewritten in a different language.
>> 
>> You save the user from having to type some junk after the program
>> name.
>> 
>> 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 nobody is the
>> wiser (unless they don't have that language installed).
>> 
>> > When the scripts grown in number, and you can't remember which is which, 
>> > it will save you time.
>> 
>> Your ls program will show you which files are executable, at a glance.
>
> Hi Kaz,
>
> You do get the idea I'm after. Basically, using Perl (or, as you mention,
> Python) scripts w/o the need to either append an extension or prepend the
> 'perl' command. Thus far, it seems that the only choice to be able to use

No program on Windows can be run without an extension, period. Everything
in your C:\Windows\System32 has an extension.

These extensions, like .bat and .exe, of course are "hidden" from users
who are using Explorer, and do not have to be included when invoking
the programs from a command line.

> only the command name is to install some variation of Unix/Linux on top of
> Windows and just use plain Linux.

Backwards, ante-deluvial handling of executables: just one of the many reasons
to ditch Windows.

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 permissions
on files, at least under NTFS.

It's a problem in the Explorer shell and CMD.EXE.

See for instance this:

http://stackoverflow.com/questions/12655314/open-an-executable-file-without-an-exe-extension-with-shellexecute

According to the accepted answer, the shell *can* be coaxed into executing a
suffix-less file, if you call it directly in C with your ShellExecuteEx API.

Of course, even though CreateProcess will execute a suffix-less file, it still
lacks the #! (shebang) mechanism for choosing an arbitrary interpreter for it.

In practice, what this means is that when "stand-alone executables" are
produced from scripting languages, this means creating an ordinary machine
language executable (actual binary .exe), or a batch file wrapper.

The .exe can be a wrapper, or it can actually contain the entire interpreter,
with the script appended to it. A wrapper .exe could contain a much smaller
binary program (not the entire interpreter) with the script appended to it;
whose job is to retrieve the script and pass it to the real interpreter.


------------------------------

Date: Wed, 25 Mar 2015 08:28:49 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: running Perl scripts w/o extension on Windows 7
Message-Id: <iik5hat8nncu2nvapr311kdvljqgi3239e@4ax.com>

gamo <gamo@telecable.es> wrote:
>El 24/03/15 a las 18:00, jomarbueyes@hotmail.com escribió:
>> 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. 

Exactly which part of his statement is wrong?

>You can not relay in a location in a directory or a fancy name. 

Did you mean "rely" instaed of "relay"? 
If you did mean "relay", then I can't make any sense of you sentence. 
And if you meant "rely" instead, then I still have a problem: You cannot
rely on ..... _for_ _what_?

>If it's a perl script, what do you save for not putting the propper .pl 
>name extension?

3 useless characters?

>When the scripts grown in number, and you can't remember which is which, 
>it will save you time.

How would adding a dot plus 2 characters help me to remember which
script downloads email, which script monitors my investment account, and
which script reformats the daily weather report?

jue


------------------------------

Date: Wed, 25 Mar 2015 18:00:10 +0100
From: gamo <gamo@telecable.es>
Subject: Re: running Perl scripts w/o extension on Windows 7
Message-Id: <meupjo$dfo$1@speranza.aioe.org>

El 25/03/15 a las 16:28, jurgenex@hotmail.com escribió:
>> If it's a perl script, what do you save for not putting the propper .pl
>> >name extension?
> 3 useless characters?
>

That 3 chars say hello to a lot of aplications, including most of the 
editors in which were created.

>> >When the scripts grown in number, and you can't remember which is which,
>> >it will save you time.
> How would adding a dot plus 2 characters help me to remember which
> script downloads email, which script monitors my investment account, and
> which script reformats the daily weather report?
>

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?

-- 
http://www.telecable.es/personales/gamo/
The generation of random numbers is too important to be left to chance


------------------------------

Date: Wed, 25 Mar 2015 18:01:09 +0000
From: Henry Law <news@lawshouse.org>
Subject: Re: running Perl scripts w/o extension on Windows 7
Message-Id: <Eq2dnYj-Eu50ao_InZ2dnUVZ8qmdnZ2d@giganews.com>

On 24/03/15 17:00, jomarbueyes@hotmail.com wrote:
> Is there a way to make Perl scripts w/o extension be recognized as executable?

As others have suggested, no, or at least not easily.

If I were in your position and looking for a workround, I'd write a 
little Windows Script program which read the names of the Perl programs 
you've written from the directory and created a .bat file (in some other 
folder in the path, perhaps) for each one.

For example if the directory contains Perl programs "foo" and "bar" then 
the script would create foo.bat which silently does "Perl foo", and 
bar.bat which does "Perl bar".  Make running it part of your distibution 
procedure and you're done.

-- 

Henry Law            Manchester, England


------------------------------

Date: Wed, 25 Mar 2015 19:50:05 +0100
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: running Perl scripts w/o extension on Windows 7
Message-Id: <tjcbub-ji1.ln1@news.rtij.nl>

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


------------------------------

Date: Wed, 25 Mar 2015 11:57:52 -0700 (PDT)
From: jomarbueyes@hotmail.com
Subject: Re: running Perl scripts w/o extension on Windows 7
Message-Id: <73853efc-53ff-4810-9cf9-7e73c4cce14c@googlegroups.com>

On Wednesday, March 25, 2015 at 2:01:17 PM UTC-4, Henry Law wrote:
> On 24/03/15 17:00, jomarbueyes at very warm mail dot com wrote:
> > Is there a way to make Perl scripts w/o extension be recognized as executable?
> 
> As others have suggested, no, or at least not easily.
> 
> If I were in your position and looking for a workround, I'd write a 
> little Windows Script program which read the names of the Perl programs 
> you've written from the directory and created a .bat file (in some other 
> folder in the path, perhaps) for each one.
> 
> For example if the directory contains Perl programs "foo" and "bar" then 
> the script would create foo.bat which silently does "Perl foo", and 
> bar.bat which does "Perl bar".  Make running it part of your distibution 
> procedure and you're done.
> 
> -- 
> 
> Henry Law            Manchester, England

Hi Henry,

Thank you for your response. I think that your solution might be a good compromise if .bat files understand command line arguments (and I can pass the equivalent to @ARGV to the Perl script). I'll give it a try.

Thanks again,

Jomar


------------------------------

Date: Wed, 25 Mar 2015 12:04:58 -0700 (PDT)
From: jomarbueyes@hotmail.com
Subject: Re: running Perl scripts w/o extension on Windows 7
Message-Id: <4ff1c724-cda7-48cb-979a-f058572a7b38@googlegroups.com>

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). B=
ecause 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 nam=
e.=20
> >> > If it's a perl script, what do you save for not putting the propper =
 .pl=20
> >> > name extension?
> >>=20
> >> You prevent the situation that a foo.pl program is written in Python,
> >> 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 nobody i=
s the
> >> wiser (unless they don't have that language installed).
> >>=20
> >> > When the scripts grown in number, and you can't remember which is wh=
ich,=20
> >> > it will save you time.
> >>=20
> >> Your ls program will show you which files are executable, at a glance.
> >
> > Hi Kaz,
> >
> > You do get the idea I'm after. Basically, using Perl (or, as you mentio=
n,
> > Python) scripts w/o the need to either append an extension or prepend t=
he
> > 'perl' command. Thus far, it seems that the only choice to be able to u=
se
>=20
> No program on Windows can be run without an extension, period. Everything
> in your C:\Windows\System32 has an extension.
>=20
> These extensions, like .bat and .exe, of course are "hidden" from users
> 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 re=
asons
> to ditch Windows.
>=20
> By the way, I seem to recall modern Windows (the kernel) will execute fil=
es
> which have no suffix. That is to say, it's not a limitation in the
> CreateProcess kernel.dll function. And Windows does have detailed permiss=
ions
> 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-witho=
ut-an-exe-extension-with-shellexecute
>=20
> According to the accepted answer, the shell *can* be coaxed into executin=
g a
> suffix-less file, if you call it directly in C with your ShellExecuteEx A=
PI.
>=20
> Of course, even though CreateProcess will execute a suffix-less file, it =
still
> lacks the #! (shebang) mechanism for choosing an arbitrary interpreter fo=
r it.
>=20
> In practice, what this means is that when "stand-alone executables" are
> produced from scripting languages, this means creating an ordinary machin=
e
> language executable (actual binary .exe), or a batch file wrapper.
>=20
> The .exe can be a wrapper, or it can actually contain the entire interpre=
ter,
> with the script appended to it. A wrapper .exe could contain a much small=
er
> binary program (not the entire interpreter) with the script appended to i=
t;
> whose job is to retrieve the script and pass it to the real interpreter.

Hi Kaz,

Thank you for your response and for the link. I'll certainly take a look. Y=
our suggestion is somewhat similar to Henry Law's of using a .bat wrapper w=
hose only content is something 'perl' followed by the name of the Perl scri=
pt it's wrapping.

Thank you again,

Jomar


------------------------------

Date: Wed, 25 Mar 2015 20:14:09 +0100
From: gamo <gamo@telecable.es>
Subject: Re: running Perl scripts w/o extension on Windows 7
Message-Id: <mev1ei$494$1@speranza.aioe.org>

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


-- 
http://www.telecable.es/personales/gamo/
The generation of random numbers is too important to be left to chance


------------------------------

Date: Wed, 25 Mar 2015 19:15:42 GMT
From: Greg Martin <greg.at.softsprocket@dot.com>
Subject: Re: running Perl scripts w/o extension on Windows 7
Message-Id: <yPDQw.246060$hv4.235349@fx04.iad>

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:
>> 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ó:
>> >> >> 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. 
>> >> > If it's a perl script, what do you save for not putting the propper .pl 
>> >> > name extension?
>> >> 
>> >> You prevent the situation that a foo.pl program is written in Python,
>> >> because the name had to be retained for compatibility when it was
>> >> rewritten in a different language.
>> >> 
>> >> You save the user from having to type some junk after the program
>> >> name.
>> >> 
>> >> 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 nobody is the
>> >> wiser (unless they don't have that language installed).
>> >> 
>> >> > When the scripts grown in number, and you can't remember which is which, 
>> >> > it will save you time.
>> >> 
>> >> Your ls program will show you which files are executable, at a glance.
>> >
>> > Hi Kaz,
>> >
>> > You do get the idea I'm after. Basically, using Perl (or, as you mention,
>> > Python) scripts w/o the need to either append an extension or prepend the
>> > 'perl' command. Thus far, it seems that the only choice to be able to use
>> 
>> No program on Windows can be run without an extension, period. Everything
>> in your C:\Windows\System32 has an extension.
>> 
>> These extensions, like .bat and .exe, of course are "hidden" from users
>> who are using Explorer, and do not have to be included when invoking
>> the programs from a command line.
>> 
>> > only the command name is to install some variation of Unix/Linux on top of
>> > Windows and just use plain Linux.
>> 
>> Backwards, ante-deluvial handling of executables: just one of the many reasons
>> to ditch Windows.
>> 
>> 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 permissions
>> on files, at least under NTFS.
>> 
>> It's a problem in the Explorer shell and CMD.EXE.
>> 
>> See for instance this:
>> 
>> http://stackoverflow.com/questions/12655314/open-an-executable-file-without-an-exe-extension-with-shellexecute
>> 
>> According to the accepted answer, the shell *can* be coaxed into executing a
>> suffix-less file, if you call it directly in C with your ShellExecuteEx API.
>> 
>> Of course, even though CreateProcess will execute a suffix-less file, it still
>> lacks the #! (shebang) mechanism for choosing an arbitrary interpreter for it.
>> 
>> In practice, what this means is that when "stand-alone executables" are
>> produced from scripting languages, this means creating an ordinary machine
>> language executable (actual binary .exe), or a batch file wrapper.
>> 
>> The .exe can be a wrapper, or it can actually contain the entire interpreter,
>> with the script appended to it. A wrapper .exe could contain a much smaller
>> binary program (not the entire interpreter) with the script appended to it;
>> whose job is to retrieve the script and pass it to the real interpreter.
>
> 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

-- 
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 4399
***************************************


home help back first fref pref prev next nref lref last post