1. Another suggestion
- Posted by Daniel Johnson <dpj22 at CAM.AC.UK>
Feb 12, 2000
-
Last edited Feb 13, 2000
Rob et al
I have become spoilt by the wonderful "executableness" of euphoria progs on
Linux (compulsory file extension aside) eg
#!/bin/euphoria
and I am dreading going back to DOS one day and having to type ex <filename>
or create batch files. Can I suggest a botch solution to this ?
in the same way as a #! is ignored as the first line of a file, could we start
a prog with
@ex %0
and call it *.bat and thus execute it directly ? I doubt very much that any
Euphoria prog will ever contain @ex at the beginning of its first line unless
you decide to go completely OO bananas.
--
Daniel Johnson Engineer, smartypants and clown
Jesus College, Cambridge all at a very reasonable price
dpj22 at cam.ac.uk
zeus.jesus.cam.ac.uk/~dpj22 talk dpj22 at jewish.jesus.cam.ac.uk
2. Re: Another suggestion
On Sat, 12 Feb 2000, Daniel Johnson wrote:
> in the same way as a #! is ignored as the first line of a file, could we start
> a prog with
>
> @ex %0
>
You've got a problem with the code being executed after the first
line, since it /really/ looks like this:
@ex %0
<code>
which will cause a bad command errors, et al. There's probably a
replacement command interpreter out there somewhere that will allow you to
have very similar functionality to the 'hash-bang' convention in unix. If
not, one could always grab the source to one of the open ones and
recompile it.
3. Re: Another suggestion
Daniel Johnson wrote:
> in the same way as a #! is ignored as the first line of a file,
> could we start a prog with
>
> @ex %0
>
> and call it *.bat and thus execute it directly ? I doubt very
> much that any Euphoria prog will ever contain @ex at the beginning
> of its first line unless you decide to go completely OO bananas.
This is an interesting idea. If you can't wait to use it, here's a
suggestion which will work with the current Euphoria version.
Create a file named '--.bat' in the euphoria\bin directory with
the following:
@echo off
if not exist %1 goto add_ext
%EUDIR%\bin\ex.exe %1 %2 %3 %4 %5 %6 %7 %8 %9
goto end
:add_ext
%EUDIR%\bin\ex.exe %1.bat %2 %3 %4 %5 %6 %7 %8 %9
:end
In your Euphoria program, include this as the first line:
-- %0 %1 %2 %3 %4 %5 %6 %7 %8 %9
Give the program a .bat extension.
When you run the program, it will call --.bat, which will in turn
run the interpreter. The control does not return to the first .bat
file after the second is finished, so the rest of the program will
not be interpreted as DOS commands.
There is a small problem with this method: before the program is
run, the call to --.bat is displayed in the screen. You can add CLS
as the second line in --.bat, so the screen will be cleared and you
will not see the call. However, sometimes you don't want the screen
to be cleared before the program runs. It's your choice.
I hope it helps!
Regards,
Davi Figueiredo
davitf at usa.net
4. Re: Another suggestion
On Sun, 13 Feb 2000 00:00:35 -0500, Daniel Johnson
<dpj22 at CAM.AC.UK> wrote:
>Rob et al
>I have become spoilt by the wonderful "executableness" of euphoria progs on
>Linux (compulsory file extension aside) eg
>#!/bin/euphoria
>and I am dreading going back to DOS one day and having to type ex <filename>
>or create batch files. Can I suggest a botch solution to this ?
>in the same way as a #! is ignored as the first line of a file, could we start
>a prog with
>@ex %0
>and call it *.bat and thus execute it directly ? I doubt very much that any
>Euphoria prog will ever contain @ex at the beginning of its first line unless
>you decide to go completely OO bananas.
Daniel, there's a better solution - if you visit
http://www.jpsoft.com, you'll find information on a product
called '4DOS'. This is a program that replaces the COMMAND.COM
on your system, and provides extended batch capabilities - very
nearly equal in power to the typical *ix shell. One of the
things that it can do is allow you do insert a line in the
environment
SET .EX=C:\EUPHORIA\BIN\EX.EXE
and all of a sudden, files with .EX extensions become executable!
So, to run PHOOBAR.EX, all you would need to do would be to type
PHOOBAR at the prompt, and away you go. Really, it's worth it.
--
Jeff Zeitlin
jzeitlin at cyburban.com
5. Re: Another suggestion
- Posted by Daniel Johnson <dpj22 at CAM.AC.UK>
Feb 13, 2000
-
Last edited Feb 14, 2000
#> @ex %0
# You've got a problem with the code being executed after the first
#line, since it /really/ looks like this:
#@ex %0
#<code>
#which will cause a bad command errors, et al
Actually if you call a programme in this way from a DOS batch file it
normally runs the app and quits unless you did it using the 'call'
command. Perhaps somebody can confirm whether or not ex.exe does this ?
# --.bat
I thought that as a general rule, a minus character was not allowed in DOS
8.3 filenames so I did not suggest this.
# 4DOS
It's not free ! If I can use Linux for free why am I going to pay for DOS
?
Daniel
6. Re: Another suggestion
- Posted by Steve Mosher <farq at KILN.ISN.NET>
Feb 13, 2000
-
Last edited Feb 14, 2000
> Daniel, there's a better solution - if you visit
> http://www.jpsoft.com, you'll find information on a product
> called '4DOS'. This is a program that replaces the COMMAND.COM
> on your system, and provides extended batch capabilities - very
> nearly equal in power to the typical *ix shell. One of the
> things that it can do is allow you do insert a line in the
> environment
>
> SET .EX=C:\EUPHORIA\BIN\EX.EXE
>
> and all of a sudden, files with .EX extensions become executable!
> So, to run PHOOBAR.EX, all you would need to do would be to type
> PHOOBAR at the prompt, and away you go. Really, it's worth it.
Yeah, I was thinking 4DOS might have this capability, but it's
been a while since I used it (messes up a few of my programs). I was going
to suggest it, but I wasn't sure it could actually do that.
7. Re: Another suggestion
- Posted by Steve Mosher <farq at KILN.ISN.NET>
Feb 13, 2000
-
Last edited Feb 14, 2000
On Sun, 13 Feb 2000, Daniel Johnson wrote:
> Actually if you call a programme in this way from a DOS batch file it
> normally runs the app and quits unless you did it using the 'call'
> command. Perhaps somebody can confirm whether or not ex.exe does this ?
Really? I've had experience to the contrary. I haven't messed
with DOS batch programming in years. I knew that -sometimes- the batch
file would continue, and other times it wouldn't, depending on the
program. Anyhow, you're probably right, I'm sticking with Linux.
> # 4DOS
>
> It's not free ! If I can use Linux for free why am I going to pay for DOS
> ?
It's not? I had a copy of it once, and I didn't have to pay money.
Perhaps it was shareware or somesuch. I didn't have any functionality
reduction in the copy I had.
Ciao
8. Re: Another suggestion
On Mon, 14 Feb 2000 00:00:16 -0500, Steve Mosher
<farq at KILN.ISN.NET> wrote:
>On Sun, 13 Feb 2000, Daniel Johnson wrote:
>> Actually if you call a programme in this way from a DOS batch file it
>> normally runs the app and quits unless you did it using the 'call'
>> command. Perhaps somebody can confirm whether or not ex.exe does this ?
> Really? I've had experience to the contrary. I haven't messed
>with DOS batch programming in years. I knew that -sometimes- the batch
>file would continue, and other times it wouldn't, depending on the
>program. Anyhow, you're probably right, I'm sticking with Linux.
>> # 4DOS
>> It's not free ! If I can use Linux for free why am I going to pay for DOS
>> ?
> It's not? I had a copy of it once, and I didn't have to pay money.
>Perhaps it was shareware or somesuch. I didn't have any functionality
>reduction in the copy I had.
It's shareware - if you don't register it, when you first start
it, you get a nag, and an increasing delay (1 second per day
after the evaluation period expires) before you can actually do
anything, although I think the delay maxes out at 60 seconds.
There have been rumors that they are going to put in a 'hard
timeout' so that it won't work after the evaluation period - but
I don't consider the source of the rumors to be a 'reliable
source', so don't worry about it until it actually happens.
--
Jeff Zeitlin
jzeitlin at cyburban.com
9. Re: Another suggestion
Jeff Zeitlin wrote:
Steve Mosher wrote:
>
>>On Sun, 13 Feb 2000, Daniel Johnson wrote:
>
>>> Actually if you call a programme in this way from a DOS batch file it
>>> normally runs the app and quits unless you did it using the 'call'
>>> command. Perhaps somebody can confirm whether or not ex.exe does this ?
>
>> Really? I've had experience to the contrary. I haven't messed
>>with DOS batch programming in years. I knew that -sometimes- the batch
>>file would continue, and other times it wouldn't, depending on the
>>program. Anyhow, you're probably right, I'm sticking with Linux.
>
Actually, you're all right as far as each of you goes. DOS batch files that
include an execution of another batch file will not return unless call is used.
Individual programs that are called by DOS batch files will return to the batch
unless the return pointer is destroyed by the program...as in most VB
programs. Many times, a recalcitrant program can be caused to return
to a batch file by using the call verb on the program, but not always.
Changes made to the environment in a "called" batch or program will not
be returned to the environment of the calling batch file, so people that are
expecting "sets" back from a called batch are disappointed. However,
changes made in the calling batch before the point of the call are passed
to the called program or batch's environment as it is copied from the
caller's environment.
Everett L.(Rett) Williams
rett at gvtc.com
10. Re: Another suggestion
- Posted by Joe Otto <joeotto at SWBELL.NET>
Feb 14, 2000
-
Last edited Feb 15, 2000
Everett,
That's a good summary of what happens except for the SET rules. SETs that
are done in a CALLed batch file are definitely returned since a new
environment is not created. In other words CALL doesn't invoke a new
instance of the command interpreter, therefore the same environment is used.
Since CALL didn't appear on the scene until MSDOS 3.3, the old workaround of
running COMMAND /C with the batch file as a parameter was used. In this
scenario a new instance of the command interpreter *is* created with it's
own copy of the environment. SETs made in this fashion are not returned.
The only way to modify the environment in this scenario is to make the
change with an executable program that's smart enough to backtrace through
the DOS pointers to locate the parent's environment and modify it directly.
Joe
-----Original Message-----
From: Euphoria Programming for MS-DOS
[mailto:EUPHORIA at LISTSERV.MUOHIO.EDU]On Behalf Of Everett Williams
Sent: Monday, February 14, 2000 3:36 PM
To: EUPHORIA at LISTSERV.MUOHIO.EDU
Subject: Re: Another suggestion
Jeff Zeitlin wrote:
Steve Mosher wrote:
>
>>On Sun, 13 Feb 2000, Daniel Johnson wrote:
>
>>> Actually if you call a programme in this way from a DOS batch file it
>>> normally runs the app and quits unless you did it using the 'call'
>>> command. Perhaps somebody can confirm whether or not ex.exe does this ?
>
>> Really? I've had experience to the contrary. I haven't messed
>>with DOS batch programming in years. I knew that -sometimes- the batch
>>file would continue, and other times it wouldn't, depending on the
>>program. Anyhow, you're probably right, I'm sticking with Linux.
>
Actually, you're all right as far as each of you goes. DOS batch files that
include an execution of another batch file will not return unless call is
used.
Individual programs that are called by DOS batch files will return to the
batch
unless the return pointer is destroyed by the program...as in most VB
programs. Many times, a recalcitrant program can be caused to return
to a batch file by using the call verb on the program, but not always.
Changes made to the environment in a "called" batch or program will not
be returned to the environment of the calling batch file, so people that are
expecting "sets" back from a called batch are disappointed. However,
changes made in the calling batch before the point of the call are passed
to the called program or batch's environment as it is copied from the
caller's environment.
Everett L.(Rett) Williams
rett at gvtc.com
11. Re: Another suggestion
- Posted by Everett Williams <rett at GVTC.COM>
Feb 14, 2000
-
Last edited Feb 15, 2000
I just ran a test on DOS 7.0 ugh! and it performed just as you say. I would
have sworn that call had the same effect on environment as command /c
under DOS through 6.0, but have no way to test it, having given up my last
"real" DOS about six months ago. Until I can at least look at one of my old
manuals, I will accept your correction. You are most probably correct, but
my memory just won't leave me alone. Sometimes, it leaves me very alone...
as in, where DID I leave my car...keys...etc?
It doesn't really matter, since
most of these people will be running DOS 7 and that works as you say.
Everett L.(Rett) Williams
rett at gvtc.com
12. Re: Another suggestion
- Posted by Joe Otto <joeotto at SWBELL.NET>
Feb 14, 2000
-
Last edited Feb 15, 2000
I know what you mean about the car keys... :)
I've been doing batch files since DOS 3.2. Sadly, I haven't kept copies of
the old versions as I upgraded through the years. I *know* that CALL works
as I stated with the current version and with 6.2x. Beyond than that I only
have my memory to go on (although I am fairly sure about it).
Please let me know if you find out anything to the contrary.
Joe
-----Original Message-----
From: Euphoria Programming for MS-DOS
[mailto:EUPHORIA at LISTSERV.MUOHIO.EDU]On Behalf Of Everett Williams
Sent: Monday, February 14, 2000 8:14 PM
To: EUPHORIA at LISTSERV.MUOHIO.EDU
Subject: Re: Another suggestion
I just ran a test on DOS 7.0 ugh! and it performed just as you say. I would
have sworn that call had the same effect on environment as command /c
under DOS through 6.0, but have no way to test it, having given up my last
"real" DOS about six months ago. Until I can at least look at one of my old
manuals, I will accept your correction. You are most probably correct, but
my memory just won't leave me alone. Sometimes, it leaves me very alone...
as in, where DID I leave my car...keys...etc? It doesn't really matter,
since
most of these people will be running DOS 7 and that works as you say.
Everett L.(Rett) Williams
rett at gvtc.com
13. Re: Another suggestion
I have DOS v6.2, v6.22 available as well as v3.3. I had v2.11 until my
Tandy 1000Hx
died a few years ago. It was hard coded into the CMOS for that system. I
never bothered
to copy it throughout all those years. Never even used v2.11. I always
loaded from a
floppy that had v3.3 instead. Thus, a brief description of my DOS history.
I also do DOS
batch programming.
Lucius L. Hilley III
lhilley at cdc.net
+----------+--------------+--------------+
| Hollow | ICQ: 9638898 | AIM: LLHIII |
| Horse +--------------+--------------+
| Software | http://www.cdc.net/~lhilley |
+----------+-----------------------------+
----- Original Message -----
From: Joe Otto <joeotto at SWBELL.NET>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Tuesday, February 15, 2000 12:25 AM
Subject: Re: Another suggestion
> ---------------------- Information from the mail
header -----------------------
> Sender: Euphoria Programming for MS-DOS
<EUPHORIA at LISTSERV.MUOHIO.EDU>
> Poster: Joe Otto <joeotto at SWBELL.NET>
> Subject: Re: Another suggestion
> --------------------------------------------------------------------------
-----
>
> I know what you mean about the car keys... :)
>
> I've been doing batch files since DOS 3.2. Sadly, I haven't kept copies
of
> the old versions as I upgraded through the years. I *know* that CALL
works
> as I stated with the current version and with 6.2x. Beyond than that I
only
> have my memory to go on (although I am fairly sure about it).
>
> Please let me know if you find out anything to the contrary.
>
> Joe
>
> -----Original Message-----
> From: Euphoria Programming for MS-DOS
> [mailto:EUPHORIA at LISTSERV.MUOHIO.EDU]On Behalf Of Everett Williams
> Sent: Monday, February 14, 2000 8:14 PM
> To: EUPHORIA at LISTSERV.MUOHIO.EDU
> Subject: Re: Another suggestion
>
>
> I just ran a test on DOS 7.0 ugh! and it performed just as you say. I
would
> have sworn that call had the same effect on environment as command /c
> under DOS through 6.0, but have no way to test it, having given up my last
> "real" DOS about six months ago. Until I can at least look at one of my
old
> manuals, I will accept your correction. You are most probably correct, but
> my memory just won't leave me alone. Sometimes, it leaves me very alone...
> as in, where DID I leave my car...keys...etc? It doesn't really matter,
> since
> most of these people will be running DOS 7 and that works as you say.
>
> Everett L.(Rett) Williams
> rett at gvtc.com
>
14. Re: Another suggestion
Hi, I'm not sure if the following EX.BAT helps:
1) assume the path contains: PATH=....;C:\BAT;... and
2) EUPHORIA is installed in: C:\EUPHORIA,
then the following EX.BAT let you set especially an ENVIRONMENT only for
your EUPHORIA (after execution your old environment is again available):
@ECHO OFF
:: *** C:\BAT\EX.BAT *** R.Schröder
2000-02-02
:: -------------
:: Call of DOS32-EUPHORIA
::
:: Set environment for EUPHORIA 2.2
::
IF "%1"=="#@!001" GOTO LBL1
%COMSPEC% /E:1024 /C %0 #@!001 %1 %2 %3 %4 %5
GOTO ENDE
:LBL1
SHIFT
PATH C:\EUPHORIA\BIN;%PATH%
SET EUDIR=C:\EUPHORIA
SET CAUSEWAY=BIG1
EX.EXE %1 %2 %3 %4 %5
:ENDE
Similarly you may call the EUPHORIA editor:
@ECHO OFF
:: *** C:\BAT\ED.BAT *** R.Schröder
2000-02-02
:: -------------
:: Call of EUPHORIA Editor for DOS32
::
IF "%1"=="#@!001" GOTO LBL1
%COMSPEC% /E:1024 /C %0 #@!001 %1 %2 %3
GOTO ENDE
:LBL1
SHIFT
SET EUDIR=C:\EUPHORIA
SET CAUSEWAY=BIG1
PATH %EUDIR%\BIN;%PATH%
EX.EXE ED.EX %1 %2 %3
:ENDE
I didn't follow the discussion, so I'm not sure if this is useful. Rolf
