mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) (08/14/89)
In article <SHADOW.89Aug13081959@pawl.rpi.edu> shadow@pawl.rpi.edu (Deven T. Corzine) writes: <addison@pollux.usc.edu (Richard Addison) writes: <Richard> If I remember correctly, /bin/sh is the default shell for <Richard> executing scripts unless another shell is specified on the <Richard> first line. < <Yep. Actually, it depends on the shell you're using. And whether it depends on the first line, or just the first character, depends on both the shell & the kernel, as both might take a stab at it. There have been a number of different ways of dealing with having more than one command interpreter on Unix. This indicates to me that the Amiga community ought to find - and implement - a good solution before it becomes a serious problem. I don't think that adding ARexx to 1.4 will qualify as "a serious problem", so long as either 1) the WShell mechanism is used, or 2) No mechanism is used, and the "rx" remains. However, either case would only do as a temporary solution (or nonsolution, in the second case). One thing to note is what most Unix shells, and WShell/ARexx, have in common. The Unix shells try executing the program you asked it to run. If that fails because the program isn't an executable, they then try running it as a script. WShell tries feeding a command to ARexx, and if that fails, continues through the command search path. The common feature is the idea of "let this try, and if it fails, go on to the next thing." ARexx even allows for the specification of "the next thing to try" as a pointer to a port. Pushing this to the extreme, you wind up with something similar to the chain used for dealing with input events. I kind of like this - it allows the user to tweak priorities, add things to the chain, and so on, without having to reach in and mangle the code. That kind of thing is always a nice feature. Several questions remain: like 1) can we make this cover enough of the current ways of finding a program, and 2) can we do this "fast enough." If the answer to either of these is no, then we probably need to look elsewhere. If the answer to both is yes, then we need to consider whether RexxMsg is a general enough struct, and what would be better. <mike P.S. "we" in much of the above of course refers to people getting $'s from CPM, and not those of us talking about this problem... -- Love and affection, Mike Meyer Of the corporate kind. mwm@berkeley.edu It's just belly to belly, ucbvax!mwm Never eye to eye. mwm@ucbjade.BITNET
ml@eceris.ncsu.edu (08/14/89)
In a previous article, mwm@eris.berkeley.edu (Mike ... Meyer) wrote:
]There have been a number of different ways of dealing with having more
]than one command interpreter on Unix. This indicates to me that the
]Amiga community ought to find - and implement - a good solution before
]it becomes a serious problem.
Yes, I have to second this notion (as I'm sure many of us would). If
this hasn't yet made it to the 1.4 wishlist, let it hereby be added!
I don't think the solution should be so simple as merely recognizing
ARexx scripts from executables or CLI "scripts". A simple mechanism
really ought to be implemented whereby any program can be invoked as
the "script language".
I know that this is one feature I made heavy use of on Unix systems
(that is, the "#!interpreter" approach); as I wrote a number of various
interpreters and it was certainly very handy to create "commands"
(i.e. script files) which went through these alternate interpreters
without my having to do anything more complicated than typing the
filename to invoke the command. This is one feature I do miss on
the Amiga; especially since I've ported some of these interpreters
to it. [ & Note: interpreters don't necessarily have to be shells
in the traditional Unix sense. Mine were typically things like plotting
or rendering programs or graphics display utilities which understood
commands typed interactively. This was a great way to package canned
demos to be distributed -- the user would just type the name of the
script file, and didn't have to worry about having to do things
like invoking the program, and then loading in a script. Anyways,
enough rambling ... ]
One request: make the mechanism a little smarter than Unix's! The one
bad thing about "#!interpreter" is that Unix requires that the name
of the interpreter be fully qualified, ie: "#!/bin/csh" is good, but
"#!csh" is not (this stems from the fact that the "#!" mechanism is
handled by the kernel exec() calls and not the shells; and search paths
are just a convenience provided by the shell and not the core OS ---
let's do it differently on the Amiga).
Well anyways, sorry for running on so long on a comparatively minor
topic. Wait 'til I get really hyped up about something :-)
==[ ml@eceris.ncsu.edu (128.109.135.109) ]==peter@sugar.hackercorp.com (Peter da Silva) (08/16/89)
In article <1989Aug14.015608.21854@agate.berkeley.edu>, mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) writes: > Several questions remain: like 1) can we make this cover enough of the > current ways of finding a program, and 2) can we do this "fast > enough." If the command interpreter has to be loaded from disk, check if it's OK, and then pass it to the next... it'd be tolerable for a hard disk and too slow for floppies. The solution of using a #!-type flag followed bvy the name of the command interpreter is a good idea, but it can't be the first couple of bytes in the file since the different programs out there use different comment conventions. Having some sort of flag on the first line, however, would help. Alternatively, there is already a mechanism for doing this in Workbench. It uses a seperate ".info" file. Maybe something like that would be acceptable for shells... maybe even using the same file? -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U`
cosell@bbn.com (Bernie Cosell) (08/16/89)
In article <4117@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: }The solution of using a #!-type flag followed bvy the name of the command }interpreter is a good idea, but it can't be the first couple of bytes in }the file since the different programs out there use different comment }conventions. Having some sort of flag on the first line, however, would }help. Actually, the OS could just set up the file pointer to the script file to be _just_past_ the first line, so that the comment conventions of the particular program would be irrelevant. There's no reason I can see why the newly-spawned child process's standard input must be set to the *beginning* of the script file, when the OS knows that the first line is actually control info. /Bernie\
charles@hpcvca.CV.HP.COM (Charles Brown) (08/17/89)
>> FALSE. If the magic number does not match, and there is no #! >> interpreter specified, the exec call assumes /bin/sh as an >> interpreter. The syntax errors you get are bourne shell errors, from >> the shell execve() created, NOT your current shell. >> For example, if you have a csh shell script, and are using csh, >> executing the csh script will try to interpret it with sh unless you >> begin the file with "#!/bin/csh". Only typing "source <file>" will >> make the current shell execute the commands. > NOT TRUE :-) > If you have a csh script and you are using the csh, a comment as the > first line will give you a csh interpretation. If you do not have a > comment as the first line you will invoke /bin/sh to execute the script, > which of course will fail since the script was a csh script (unless it > is echo hello :-) > UUCP: ...!gatech!uflorida!sun.ufnet.ufl.edu!misterx Devine was correct, at least for some Unices. Under HP-UX, #!/bin/csh is interpreted by exec before csh OR sh sees it. The convention you describe (comment first -> /bin/csh, else /bin/sh) is older and is obsolete. I don't know if HP-UX inherited this behaviour from AT&T or from BSD. (HP-UX tries to take the best of both.) Anyway this would be a good convention for the Amiga to adopt. (If the first line is #!prog, then use prog to interpret the file.) -- Charles Brown charles@cv.hp.com or charles%hpcvca@hplabs.hp.com or hplabs!hpcvca!charles or "Hey you!" Not representing my employer. "The guy sure looks like plant food to me." Little Shop of Horrors
dan-hankins@cup.portal.com (Daniel B Hankins) (08/17/89)
Has anyone yet considered the simple, quick and dirty way to get this
function with the existing opsys? I can think of two ways:
1. Use WShell. It checks to see if an invoked name is an ARexx script.
2. Rename Execute as something else (I call it Ex), set the script bit on
all your ARexx execs, and rename rx to Execute. Then, when the 1.3 Shell
fails to find an executable program with the right name, it will look for
a file with the script bit set and invoke Execute on it. Voila! Instant
ARexx from the command line.
Dan Hankins
Regardless of management's wishes, computer engineers and programmers ar
*not* Field Replaceable Units.misterx@sun.ufnet.ufl.edu ( ) (08/18/89)
In article <1410024@hpcvca.CV.HP.COM> charles@hpcvca.CV.HP.COM (Charles Brown) writes: >Devine was correct, at least for some Unices. Under HP-UX, #!/bin/csh >is interpreted by exec before csh OR sh sees it. The convention you >describe (comment first -> /bin/csh, else /bin/sh) is older and is >obsolete. I don't know if HP-UX inherited this behaviour from AT&T or should read "... is older and unfortunately not obsolete." :-) >from BSD. (HP-UX tries to take the best of both.) > Charles Brown charles@cv.hp.com or charles%hpcvca@hplabs.hp.com > or hplabs!hpcvca!charles or "Hey you!" Well, I looked at some code, and it does seem that Devin was correct, the default action on BSD machines for the loader which does not find a magic cookie, is to pass the file to /bin/sh, sh then will decide what to do with it. /bin/sh decides by looking at the first line. -- "One, you lock the target. Two, you bait the line. Three, you slowly spread the net. And four, you catch the man." UUCP: ...!gatech!uflorida!sun.ufnet.ufl.edu!misterx Internet: misterx@sun.ufnet.ufl.edu | vishnu@pine.circa.ufl.edu
FelineGrace@cup.portal.com (Dana B Bourgeois) (08/18/89)
One kludgy way to get a command like stack to act differently in scripts and from the CLI would be to utilize the stderr and stdout handles. Now this is *real* kludgy but if "Your stack size is" comes out of stderr and "stack <bytes>" comes out of stdout then you kinda get what is needed. Of course your CLI will fill up with partial messages from the different programs in the pipe. But I *said* it was kludgy. I guess the better way would be to put that into the program as a command line flag. stack -l tells stack to skip the verbage and just output 'stack <bytes> <cr>'. Dana
usenet@cps3xx.UUCP (Usenet file owner) (08/19/89)
In article <21387@cup.portal.com> FelineGrace@cup.portal.com (Dana B Bourgeois) writes: [stuff removed about tricks with stderr and stdout] >command line flag. stack -l tells stack to skip the verbage and >just output 'stack <bytes> <cr>'. Better yet: Have things check IsInteractive(stdout); If it returns true, output stuff in the long format If it is false, output in easy to process format. Of couse, there should be switches to explicitly select either mode. Question: What does IsInteractive(pipehandle) return? REAL NAME: Joe Porkka jap@frith.cl.msu.edu
limonce@pilot.njin.net (Tom Limoncelli) (08/19/89)
Better yet, why not have the executable include info like what size the stack SHOULD be, then remove the STACK command from the C: directory and just rely on programmers to make sure that their executable have the right info. (Of course, in the phase-out stage the value set in the STACK command [which would have an -l option, of course] which would set up a default size for older programs. This, I believe, is what ARP does. -Tom (ooo! ahhh! a new signature!) -- Drew University -- Tom Limoncelli P O Box 802 -- limonce@pilot.njin.net C M Box 1060 -- tlimonce@drunivac.Bitnet Madison, NJ 07940 -- 201-408-5389
FelineGrace@cup.portal.com (Dana B Bourgeois) (08/22/89)
Joe, IsInteractive(pipehandle) returns the easy to process format. You don't want verbage cluttering up the pipe. Dana
darin@nova.laic.uucp (Darin Johnson) (08/22/89)
In article <44364@bbn.COM> cosell@BBN.COM (Bernie Cosell) writes: >Actually, the OS could just set up the file pointer to the script file to be >_just_past_ the first line, so that the comment conventions of the particular >program would be irrelevant. > /Bernie\ How about just using the comment field in the file header? Most people don't use these, and if they do, they can just put the magic sequence at the beginning and the comment afterwords. (Just keep the same syntax, but use an already existing field, seldom-use field, saving a very tiny bit of disk space) Darin Johnson (leadsv!laic!darin@pyramid.pyramid.com) We now return you to your regularly scheduled program.
shadow@pawl.rpi.edu (Deven T. Corzine) (08/24/89)
In article <44364@bbn.COM> cosell@BBN.COM (Bernie Cosell) writes:
Bernie> Actually, the OS could just set up the file pointer to the
Bernie> script file to be _just_past_ the first line, so that the
Bernie> comment conventions of the particular program would be
Bernie> irrelevant.
This I find to be a preferable solution by far. The interpreter gets
all the information in that line passed in its argument vector. It
should not need to parse out that first line which the kernal
interpreted in the first place.
On 22 Aug 89 02:21:22 GMT, darin@nova.laic.uucp (Darin Johnson) said:
Darin> How about just using the comment field in the file header?
Darin> Most people don't use these, and if they do, they can just put
Darin> the magic sequence at the beginning and the comment afterwords.
Darin> (Just keep the same syntax, but use an already existing field,
Darin> seldom-use field, saving a very tiny bit of disk space)
I don't like this idea. Putting information out of band like that is
just asking for it to get lost. Workbench's ".info" files are no
better. The comment field should be preserved for comments, and not
twisted into system use. (yes, you could do it, and it might be
reasonable for some situations, such as a simple implementation of
symlinks, but I don't like it as a general strategy.)
As for the disk space, it isn't worth worrying about. Adding the line
to the text of the script isn't particularly likely to push any given
script over a disk block border. So, on the average, it won't affect
disk space usage at all.
Basically, I see using the comment field as being more trouble in this
instance than it's worth.
Deven
--
Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu
Snail: 2214 12th Street, Troy, NY 12180 Phone: (518) 271-0750
Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven
Simple things should be simple and complex things should be possible.deraadt@enme3.ucalgary.ca (Theo Deraadt) (08/24/89)
I find this entire discussion rather silly; being as the Unix way is the most flexible. I mean, what part of the system knows better what shell interpreter a shell script should be run by, than the shell script file itself? Why not just use the #! syntax, and make the kernel know to follow the current system path. I swear, some people just have a deathwish for all Unix semantics. Gad.. <tdr. Theo de Raadt (403) 289-5894 Calgary, Alberta, Canada
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (08/27/89)
In <1989Aug27.034146.27086@agate.uucp>, mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) writes: >In article <1746@cs-spool.calgary.UUCP> deraadt@enme3.UUCP (Theo Deraadt) writes: ><I find this entire discussion rather silly; being as the Unix way is ><the most flexible. I mean, what part of the system knows better what ><shell interpreter a shell script should be run by, than the shell ><script file itself? Why not just use the #! syntax, and make the kernel ><know to follow the current system path. > >I find this statement rather silly; being that just implementing the >Unix semantics would mean that both ARexx scripts and CLI scripts >wouldn't work at all. Why? We can always consider the ARexx method of determining ARexxness to be 'prior art', and not step on that with whatever convention is decided upon. > It would also eliminate the ability to use ARexx >as macro langauge in a properly designed shell .... It would? I think it rather depends on what you call 'properly designed'. To me, that means that it can handle everything that is currently available, with provision for allowing it to handle whatever comes along next, and do it in a consistent manner. All that is neded to allow ARexx to run properly is to look for the first two non-whitespace characters in the file. If they are '/*', pass it to ARexx. It works that way now. If it happens to be a C source code file, ARexx will figure it out pretty quick, just as it does now. We just have to reserve '/*' as the magic cookie for ARexx. No big deal. >You could solve the problem by making '#' a comment in all scripting >languages. This is rather ugly. # is the '# any uglier than // any other comment REM delimiter? Personally, /* I think that the lack of */ C a 'single line comment' * in C and Pascal is a real failing, ; not to mention the way some (* braindead compilers prohibit *) -- nesting comments. Don't you ( think that ugly is in the ) % eye of the beholder? % -larry -- The Mac? Oh, that's just like a computer, only slower. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) (08/27/89)
In article <1746@cs-spool.calgary.UUCP> deraadt@enme3.UUCP (Theo Deraadt) writes:
<I find this entire discussion rather silly; being as the Unix way is
<the most flexible. I mean, what part of the system knows better what
<shell interpreter a shell script should be run by, than the shell
<script file itself? Why not just use the #! syntax, and make the kernel
<know to follow the current system path.
I find this statement rather silly; being that just implementing the
Unix semantics would mean that both ARexx scripts and CLI scripts
wouldn't work at all. It would also eliminate the ability to use ARexx
as macro langauge in a properly designed shell, as opposed to an
interpreted programming language that gives you access to Execute().
You could solve the problem by making '#' a comment in all scripting
languages. This is rather ugly. You could also make the kernel skip
the first line, and start the script executing on the second line.
It's not clear that this will work for Rexx at all, and if it does,
you have to decide how sourceline() is going to deal with that first
line. Both solutions also are hazardous to the portability of Rexx
scripts to other Rexx platforms, and neither deals with the loss of
ARexx as a macro langauge for your shell.
<I swear, some people just have a deathwish for all Unix semantics. Gad..
I swear, some people think Unix semantics are the solution to all
problems, even if these are problems that don't exist on Unix. Gad..
<mike
--
ICUROK2C, ICUROK2. Mike Meyer
ICUROK2C, ICWR2. mwm@berkeley.edu
URAQT, I WANT U2. ucbvax!mwm
OO2EZ, I WANT U2. mwm@ucbjade.BITNETpeter@sugar.hackercorp.com (Peter da Silva) (08/27/89)
In article <1989Aug27.034146.27086@agate.uucp>, mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) writes: > I swear, some people think Unix semantics are the solution to all > problems, even if these are problems that don't exist on Unix. Gad.. I swear, some people are more interested in shooting down an idea instead of trying to solve a problem. All scripting languages worth their salt have some sort of comment syntax. So, make some unique pattern that can be used to identify a script language, and allow it anywhere in the first couple of lines of the script (in the first couple of lines to allow for programs that use a seperate line to indicate a comment pseudo-op, or need some magic on line 1): ----- /* $$SCRIPT(RX $*) */ ----- .key whatever ; $$SCRIPT(EXECUTE $*) ----- # $$SCRIPT(BAWK -F: $*) ----- %{ /* $$SCRIPT(INSTANT-LEX $* S:MAIN.C) ----- -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U` "before making up your mind, please read the book." -- sherry.mann "This is contrary to the spirit of rec.arts.sf-lovers" -- Jim Winer
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (08/28/89)
In <1989Aug29.031707.9022@agate.uucp>, mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) writes: >In article <721@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: ><In <1989Aug27.034146.27086@agate.uucp>, mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) writes: ><> It would also eliminate the ability to use ARexx ><>as macro langauge in a properly designed shell .... >< All that is neded to allow ARexx to run properly is to look ><for the first two non-whitespace characters in the file. If they are '/*', pass ><it to ARexx. > >Yes, but you can't just "hand it" to ARexx. ARexx gets passed a packet >with the file name in it, and a port to send commands (those generated >in the process of "macro expansion") to. There are problems with >getting Execute to do this - like, where does it find the port to put >into that packet? Since ARexx will be the 'native' script interpreter in 1.4 (with Amigados script capability retained, most likely), it would seem to me that this is not a hurdle at all. I can see it would be if implemented before 1.4 arrives. Perhaps we are talking about different things here. I am speaking in terms of what could be implemented in a future (perhaps 1.4) release, with the hooks built in to the system for allowing a variety of interpreted languages to coexist peacefully. >< We just have to reserve '/*' as the magic cookie for ARexx. No big deal. > >Yes, it's a big deal. It defeats the point of the system. If you have >to reserve a different magic number for each interpreted langauge, >then the user can't get a new interpreter and have it's source files >work as executables - not unless things have been arranged so the user >can change the list of magic cookies. Isn't that what the 'generic, named interpreter' is for? ie. the magic number specifies that the rest of the line names the interpreter. Perhaps the answer is to remove the magic number to somewhere else, like the file header, so that the interpreter doesn't actually get it as part of the file. ><# is the '# any uglier than ><// any other comment ><REM delimiter? > >No - but having to add it to both languages regardless of what it's >otherwise used for is ugly. I'll agree wholeheartedly with that. >Fixing the recognition problem isn't hard - you just have to find a >method that doesn't break Rexx (Rexx exists elsewhere - CLI scripts >are pretty much Amiga specific, so breaking those is somewhat >acceptable), which means working with multiple different comment >methods, doesn't die if you feed it an arbitrary binary (for instance, >by looking for some character that may never occur), and can't >possibly collide with any existing thing Execute recognizes. I don't mind if Amigados scripts get broken, as long as there is a way to tell when they are broken because of the changes. That would entail an error message to the effect: 'No magic number'. It would be a small price to pay for the transition, and would be relatively easy to fix. We might even end up with someone writing a utility to make Amigados scripts into ARex scripts. (Hmm... that would be a good utility now, even) I don't see arbitrary binaries as a problem. The rule would be to look at the first non-whitespace character(s). If they happen to be something used by an interpreter, what are the chances that the rest of the passed file will be a legal interpreter program? > However, that ignores the more important problem - that ARexx expects a wider >communications path to the invoking program than Execute provides. Yes, and that's now, as things stand under the current rev of the OS. I think you'll find that there are sufficient hooks coming to fill the requirements of ARexx, and that many of the problems will disappar entirely. My main concern is that we have a method to allow virtually unlimited capability to add interpreted languages transparently, and in a manner consistent with each language's implementation. Thanks for pointing out the pitfalls. -larry -- The Mac? Oh, that's just like a computer, only slower. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
limonce@pilot.njin.net (Tom Limoncelli) (08/29/89)
In article <721@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: > # is the '# any uglier than > // any other comment > REM delimiter? Personally, > /* I think that the lack of */ > C a 'single line comment' > * in C and Pascal is a real failing, So did ANSI XJ11. That's why // is a valid comment-until-then-end-of-line sequence now. (Just like in C++) > | // Larry Phillips | > | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | -- Drew University -- Tom Limoncelli C M Box 1060 -- limonce@pilot.njin.net P O Box 802 -- tlimonce@drunivac.Bitnet Madison, NJ 07940 -- 201-408-5389
charles@hpcvca.CV.HP.COM (Charles Brown) (08/29/89)
> All scripting languages worth their salt > have some sort of comment syntax. So, make some unique pattern that can be > used to identify a script language, and allow it anywhere in the first couple > of lines of the script (in the first couple of lines to allow for programs > that use a seperate line to indicate a comment pseudo-op, or need some magic > on line 1): Oh joy! A breath of fresh air! This proposal takes the desirable part of what was proposed earlier while nicely avoiding the pitfalls. > /* $$SCRIPT(RX $*) */ > .key whatever > ; $$SCRIPT(EXECUTE $*) > # $$SCRIPT(BAWK -F: $*) > %{ > /* $$SCRIPT(INSTANT-LEX $* S:MAIN.C) > Peter "Have you hugged your wolf today" da Silva `-_-' Thank you Peter. -- Charles Brown charles@cv.hp.com or charles%hpcvca@hplabs.hp.com or hplabs!hpcvca!charles or "Hey you!" Not representing my employer.
mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) (08/29/89)
In article <721@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: <In <1989Aug27.034146.27086@agate.uucp>, mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) writes: <> It would also eliminate the ability to use ARexx <>as macro langauge in a properly designed shell .... < <It would? I think it rather depends on what you call 'properly designed'. To <me, that means that it can handle everything that is currently available, with <provision for allowing it to handle whatever comes along next, and do it in a <consistent manner. All that is neded to allow ARexx to run properly is to look <for the first two non-whitespace characters in the file. If they are '/*', pass <it to ARexx. Yes, but you can't just "hand it" to ARexx. ARexx gets passed a packet with the file name in it, and a port to send commands (those generated in the process of "macro expansion") to. There are problems with getting Execute to do this - like, where does it find the port to put into that packet? <It works that way now. If it happens to be a C source code file, <ARexx will figure it out pretty quick, just as it does now. We just have to <reserve '/*' as the magic cookie for ARexx. No big deal. Yes, it's a big deal. It defeats the point of the system. If you have to reserve a different magic number for each interpreted langauge, then the user can't get a new interpreter and have it's source files work as executables - not unless things have been arranged so the user can change the list of magic cookies. <# is the '# any uglier than <// any other comment <REM delimiter? No - but having to add it to both languages regardless of what it's otherwise used for is ugly. Fixing the recognition problem isn't hard - you just have to find a method that doesn't break Rexx (Rexx exists elsewhere - CLI scripts are pretty much Amiga specific, so breaking those is somewhat acceptable), which means working with multiple different comment methods, doesn't die if you feed it an arbitrary binary (for instance, by looking for some character that may never occur), and can't possibly collide with any existing thing Execute recognizes. However, that ignores the more important problem - that ARexx expects a wider communications path to the invoking program than Execute provides. I don't see an easy solution to that, other than leaving the ARexx method as an alternative. In which case, making the ARexx method subsume the BSD method should be given a serious look. And you probably want to do that to begin with, as the results might be better than going the other way. <mike -- Tried to amend my carnivorous habits Mike Meyer Made it nearly seventy days mwm@berkeley.edu Loosing weight without speed ucbvax!mwm Eatin' sunflower seeds mwm@ucbjade.BITNET
jac@muslix.llnl.gov (James Crotinger) (08/29/89)
In article <Aug.28.20.36.04.1989.10186@pilot.njin.net> limonce@pilot.njin.net (Tom Limoncelli) writes: >In article <721@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: > >So did ANSI XJ11. That's why // is a valid comment-until-then-end-of-line >sequence now. (Just like in C++) >-- This is the third time I've heard this. Can someone verify this? I've asked both Lattice, and our local ANSI expert (who was on the committee), and both have said "no". Similarly, I've yet to C a book on the ANSI standard which says it supports // comments. I hope that ANSI did decide to add these at the last minute. I certainly can't see any harm in doing so... Jim
rap@peck.ardent.com (Rob Peck) (08/30/89)
In article <1410026@hpcvca.CV.HP.COM> charles@hpcvca.CV.HP.COM (Charles Brown) writes: >> All scripting languages worth their salt >> have some sort of comment syntax. So, make some unique pattern that can be >> used to identify a script language, and allow it anywhere in the first couple >> of lines of the script (in the first couple of lines to allow for programs >> that use a seperate line to indicate a comment pseudo-op, or need some magic >> on line 1): > >Oh joy! A breath of fresh air! This proposal takes the desirable >part of what was proposed earlier while nicely avoiding the pitfalls. > >> /* $$SCRIPT(RX $*) */ [[ more suggestions deleted, all containing $$ in some fashion ]] Yes, thanks to Peter, we do have some reasonable suggestions. Just my $0.02 that one might consider avoiding $$ and use ## instead, or any other similar combination. Though I believe that it is not a "collision", remember that starting with 1.3, the EXECUTE command substitutes the CLI number running the command for a "$$" that it finds in angle-brackets (<$$>). Just thought it best to leave fewer chances to confuse the (new?) user of execute scripts by choosing something else for this purpose. Rob Peck
mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) (08/30/89)
In article <1410026@hpcvca.CV.HP.COM> charles@hpcvca.CV.HP.COM (Charles Brown) writes:
<> All scripting languages worth their salt
<> have some sort of comment syntax. So, make some unique pattern that can be
<> used to identify a script language, and allow it anywhere in the first couple
<> of lines of the script (in the first couple of lines to allow for programs
<> that use a seperate line to indicate a comment pseudo-op, or need some magic
<> on line 1):
<
<Oh joy! A breath of fresh air! This proposal takes the desirable
<part of what was proposed earlier while nicely avoiding the pitfalls.
Like most simple solutions to complex problems, this one doesn't work.
First problem: Line? What's a line in a binary file? I really don't
want the system looking through 300K or so of a databse for a newline
character that isn't in it. This actually has an easy solution:
instead of limiting it to the first couple of lines, limit it to the
first N bytes, for reasonable N - the first block sounds good.
Second problem: The string needs to be something that isn't likely to
appear in a binary file - or an arbitrary text file - by chance. Once
again, the solution is simple.
Third problem: This is ugly. The real BSD solution is clean, simple,
and fit well with the existing system on Unix. This doesn't fit well
with what's already on the Amiga (though the Unix solution would).
Fourth problem: Having Execute feed an ARexx script to ARexx cuts off
the major part of ARexx's usefullness as a scripting language.
One more time: Unix doesn't have a mechanism similar to ARexx.
Adopting the BSD solution to the problem of multiple scripting
languages doesn't solve any existing problems - you still have to have
two seperate mechanisms, one for ARexx and one for everything else. In
this case, "everything else" is only one thing. So why bother?
Especially when ARexx _already has_ a mechanism allowing for multiple
scripting languages.
<mike
--
Take a magic carpet to the olden days Mike Meyer
To a mythical land where everybody lays mwm@berkeley.edu
Around in the clouds in a happy daze ucbvax!mwm
In Kizmiaz ... Kizmiaz mwm@ucbjade.BITNETjesup@cbmvax.UUCP (Randell Jesup) (08/30/89)
In article <1989Aug29.031707.9022@agate.uucp> mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) writes: >Fixing the recognition problem isn't hard - you just have to find a >method that doesn't break Rexx (Rexx exists elsewhere - CLI scripts >are pretty much Amiga specific, so breaking those is somewhat >acceptable), which means working with multiple different comment >methods, doesn't die if you feed it an arbitrary binary (for instance, >by looking for some character that may never occur), and can't >possibly collide with any existing thing Execute recognizes. This was discussed at length months ago on BIX in amiga.dev/ suggestions. The final more-or-less consensus was that you should look for the string #!...!# (... being name of interpreter) anywhere in the first line. This allows embedding it in any type of comment. It still has a few problems, but seems to handle most of the problems. There still needs to be some hard-coded recognitions of executables, AmigaDos scripts, and _perhaps_ ARexx scripts. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
dbk@teroach.UUCP (Dave Kinzer) (08/30/89)
In article <724@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: > Perhaps the answer >is to remove the magic number to somewhere else, like the file header, so that >the interpreter doesn't actually get it as part of the file. I think that this is a good answer in general, and this is my admittedly offhanded thought as a specific implementation. Either add a new linked field in the directory structure or re-use the comment field as a statement to be loaded and run. This would be combined with an as-yet unallocated protection bit which would say to use the field as a command. In the case of ARexx, the command field would simply be 'rx'. The original command line would be appended to the command field with the resulting line being passed to the program loader. This concept could be expanded to allow for positional parameter placement and other complex constructs not important to getting this idea across. EXAMPLE: ARexx file named 'Print' with command field 'rx Print SER:' typing the command: SHELL> Print myfile would result in a statement of: rx Print SER: myfile Additional info: I never use the comment field, so it's re-use in this manner is OK with me. In addition, the list command would let you see what your calling conventions are very easily. Other people may not like giving up comments. This scheme is easily expanded to any scripting language, including Execute (heck, we could even re-use the script bit). (Blank comment field would default to Execute. Again, your mileage may vary.) If links are made available, and the command field is associated with the link, it is easy to call the same script with different parameters. The example above could have a link that calls the file with PAR: as a parameter to print the file on a different printer. A well thought out system would probably contain positional parameters that could place the original command line parameters arbitrairly on the constructed command line. OK, asbestos suit is on, constructively flame away! * * * Imminent use of deathnet predicted. * * * // Dave Kinzer (602)897-3085 asuvax!mcdphx!teroach!dbk Opinions are mine. \X/ ...Still looking for an AmiExpo-Usenet party sponser.
utoddl@ecsvax.uncecs.edu (Todd M. Lewis) (08/31/89)
In article <31742@lll-winken.LLNL.GOV>, jac@muslix.llnl.gov (James Crotinger) writes: > and both have said "no". Similarly, I've yet to C a book on the ANSI > standard which says it supports // comments. I hope that ANSI > did decide to add these at the last minute. I certainly can't see any > harm in doing so... a = b //* Go ahead, break my code! */ c; _____ | Todd M. Lewis Disclaimer: If you want my employer's ||\/| utoddl@ecsvax.uncecs.edu ideas, you'll have to || || utoddl@ecsvax.bitnet _buy_ them. | || |___ (Never write a program bigger than your screen.)
mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) (08/31/89)
In article <7782@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: <In article <1989Aug29.031707.9022@agate.uucp> mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) writes: <>Fixing the recognition problem isn't hard - you just have to find a < < This was discussed at length months ago on BIX in amiga.dev/ <suggestions. The final more-or-less consensus was that you should look <for the string #!...!# (... being name of interpreter) anywhere in the <first line. This allows embedding it in any type of comment. Someone who knows what's going to happen. Lotsa question... Is the search going to be length-limited, as well? Or will it search in vain through a megabyte of database for the newline that isn't there? Did anyone consider the advisability of using a character that has different graphics representations in different countries (#) as one of the magic characters? One of the first uses of #! on Unix was for a Pascal P-code interpreter - the interpreter was tweaked to skip the first line, and the compiler generated "#! pcodeinterpreter" as the first line, followed by binary. What happens if someone has a similar binary "script", the first word of which is 0x00000f3f? Or will that be considered an error on the part of the compiler? I assumes this code is going into Execute(), as it needs to read the first part of the binary in any case. That is the case, isn't it? It's not going into the shell, is it? If Execute() fires off an ARexx script, how will the script communicate with the shell as a client? Or will the default shell not be a client? (Does the contract with Hawes specify that CBM not provide a client shell, so he can still sell copies of WShell? :-) <There still needs to be some hard-coded recognitions of executables, <AmigaDos scripts, and _perhaps_ ARexx scripts. Why? Backwards compatability, or does #!Execute!# fail? Thanx, <mike -- [Our regularly scheduled .signature preempted.] Mike Meyer The Amiga 1000: Let's build _the_ hackers machine. mwm@berkeley.edu The Amiga 500: Let's build one as cheaply as possible! ucbvax!mwm The Amiga 2000: Let's build one inside an IBM PC! mwm@ucbjade.BITNET
peter@sugar.hackercorp.com (Peter da Silva) (08/31/89)
In article <1989Aug29.233027.4285@agate.uucp>, mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) writes: > Third problem: This is ugly. The real BSD solution is clean, simple, > and fit well with the existing system on Unix. This doesn't fit well > with what's already on the Amiga (though the Unix solution would). Arexx didn't fit well with what's already on the Amiga in the first place. I personally find the Arexx program interface ugly. You can't let this sort of thing stand in your way. Aesthetics aside, what's wrong with it? I use a similar mechanism to stick Makefiles in small single-file C programs on UNIX... "compile foo.c" extracts a Makefile from foo.c and runs Make. > Fourth problem: Having Execute feed an ARexx script to ARexx cuts off > the major part of ARexx's usefullness as a scripting language. So your fancy Arexx shell uses a special mechanism for Arexx files, and keeps the existing mechanism for everything else. > Especially when ARexx _already has_ a mechanism allowing for multiple > scripting languages. The problem is that there are dozens, if not hundreds, of scripting languages waiting in the wings that will work just fine with the mechanism I proposed, and I'm not planning on Arexxising them. Are you volunteering to do the hard work? -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U` "before making up your mind, please read the book." -- sherry.mann "This is contrary to the spirit of rec.arts.sf-lovers" -- Jim Winer
peter@sugar.hackercorp.com (Peter da Silva) (08/31/89)
In article <7782@cbmvax.UUCP>, jesup@cbmvax.UUCP (Randell Jesup) writes: > This was discussed at length months ago on BIX in amiga.dev/ > suggestions. The final more-or-less consensus was that you should look > for the string #!...!# (... being name of interpreter) anywhere in the > first line. Isn't it nice when things fall together like this? I would recommend allowing it in more than just the first line, though, since some scripting languages like having the first line magic. Also, having some mechanism for passing extra arguments to the command interpreter would be useful. -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U` "before making up your mind, please read the book." -- sherry.mann "This is contrary to the spirit of rec.arts.sf-lovers" -- Jim Winer
rap@peck.ardent.com (Rob Peck) (08/31/89)
In article <1989Aug31.004647.12718@agate.uucp> mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) writes: >Did anyone consider the advisability of using a character that has >different graphics representations in different countries (#) as one >of the magic characters? > ... > ... >I assumes this code is going into Execute(), as it needs to read the >first part of the binary in any case. That is the case, isn't it? It's >not going into the shell, is it? > I would certainly hope that some of this special code would go into the Shell as well as into Execute() ... I would certainly like to have the basic environment do as WShell does now, meaning "if the command name is not in the search path, is it in the REXX: directory with an appended .rexx at the end... in that case I have to "rx" it. It's in there????? Or, as Mike says, does everyone still have to buy WShell to get this capability. Good for Bill Hawes, but seems to defeat the purpose of building in AREXX if the Amiga Shell (and Execute) cannot be made to recognize AREXX scripts and execute-scripts interchangeably. Rob Peck
xanthian@well.UUCP (Kent Paul Dolan) (09/01/89)
In article <724@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: > >Since ARexx will be the 'native' script interpreter in 1.4 (with Amigados >script capability retained, most likely), [...] The AmigaDOS script, while it can have lots of .key, .bra, .ket, and line parameter embellishments, has the wonderful advantage to the new user that s/he can simply type a list, made up of the identical commands used at the CLI interface, into a file, save the file, and "execute" it, without having to learn a new programming language. Syntactically and semantically, AREXX simply does not provide the same ability. The command script used to replace the user's keystrokes at the CLI, done in AREXX, is longer, more complex, contains extra setup items, is rife with obscure punctuation, bears little resemblance to the typing it is meant to replace, and is in general a chore to learn. I suggest that this makes it unacceptable as a primary script language; it is very powerful, but it is a specialists' tool. It sure seems, again, to me, like there is no one minding the store at C=A wherein the needs of the new user are kept forefront in every system software decision. We're talking lost market share again here, gentlebeings, and that saddens me as a loyal Amiga gadfly. I have no quarrel with AREXX being added to the Amiga's set of Extras tools, in fact that is a fine idea, but I would have had to learn a whole new programming language to make a few simple modifications to s:startup-sequence, had it been written in AREXX instead of in AmigaDOS commands. This would not have been the way to have made a good impression on a new customer. >The Mac? Oh, that's just like a computer, only slower. [Fun game, and a wonderful way to avoid computer system religious wars!] The Next? Oh, that's just like a Mac, only slower. Again, please excuse my ranting; I just have this completely impractical vision of the Amiga product line being a market success based on its obvious technical merit and price/capabilities leadership, and I hate to see all these advantages sacrificed by making the machine hard to use. well!xanthian Kent, the man from xanth, now just another echo from The Well.
charles@hpcvca.CV.HP.COM (Charles Brown) (09/01/89)
> Like most simple solutions to complex problems, this one doesn't work. This looks like a case of saying the glass is half empty rather than half full. > First problem: Line? What's a line in a binary file? I really don't > want the system looking through 300K or so of a databse for a newline > character that isn't in it. This actually has an easy solution: > instead of limiting it to the first couple of lines, limit it to the > first N bytes, for reasonable N - the first block sounds good. I noticed this after my last posting. I think it would be best to limit it to 2 lines or 200 bytes/characters, whichever comes first. > Second problem: The string needs to be something that isn't likely to > appear in a binary file - or an arbitrary text file - by chance. Once > again, the solution is simple. The proposed string is already not likely to appear in a binary file by chance. What were you thinking? > Third problem: This is ugly. The real BSD solution is clean, simple, > and fit well with the existing system on Unix. This doesn't fit well > with what's already on the Amiga (though the Unix solution would). I disagree. But then esthetics is always a matter of opinion. The Unix solution is inflexible. It requires the first character in the file to be a "#". That breaks script languages which do not have "#" as a comment character. This is a problem under Unix today. If Peter's proposal had instead been used under Unix, those script languages would work gracefully with #!program. The Amiga has the same situation. Script languages would be broken by the use of #!program. They would not be broken by Peter's proposal. So you have it exactly backward. > Fourth problem: Having Execute feed an ARexx script to ARexx cuts off > the major part of ARexx's usefullness as a scripting language. I don't understand. If I give an ARexx script name as the command to Execute and it automagically hands it to ARexx rather than trying to do something else, what is wrong? That is just what I want it to do. > One more time: Unix doesn't have a mechanism similar to ARexx. > Adopting the BSD solution to the problem of multiple scripting > languages doesn't solve any existing problems - you still have to have > two seperate mechanisms, one for ARexx and one for everything else. In > this case, "everything else" is only one thing. So why bother? > Especially when ARexx _already has_ a mechanism allowing for multiple > scripting languages. > -- > Take a magic carpet to the olden days Mike Meyer Everything else? Which "one thing" did you have in mind? Basic? sh? csh? awk? dpslide? ... -- Charles Brown charles@cv.hp.com or charles%hpcvca@hplabs.hp.com or hplabs!hpcvca!charles or "Hey you!" Not representing my employer.
charles@hpcvca.CV.HP.COM (Charles Brown) (09/01/89)
> Perhaps the answer is to remove the magic number to somewhere else, > like the file header, so that the interpreter doesn't actually get it > as part of the file. A disadvantage to this is that the magic number is lost if I move the file using arc, shar, cpio, tar, ... > I don't mind if Amigados scripts get broken, as long as there is a way > to tell when they are broken because of the changes. That would entail > an error message to the effect: 'No magic number'. It would be a small > price to pay for the transition, and would be relatively easy to fix. That is not a small price to pay. Any time you break existing programs (especially those used by novices) you are asking to loose market share. > I don't see arbitrary binaries as a problem. The rule would be to look > at the first non-whitespace character(s). If they happen to be > something used by an interpreter, what are the chances that the rest > of the passed file will be a legal interpreter program? And the interpreter gags on it. That is not friendly. The idea is to recognize that it is binary and NOT interpret it. >> However, that ignores the more important problem - that ARexx >> expects a wider communications path to the invoking program than >> Execute provides. > Yes, and that's now, as things stand under the current rev of the OS. > I think you'll find that there are sufficient hooks coming to fill the > requirements of ARexx, and that many of the problems will disappar > entirely. My main concern is that we have a method to allow virtually > unlimited capability to add interpreted languages transparently, and > in a manner consistent with each language's implementation. > -larry This is music to my ears. -- Charles Brown charles@cv.hp.com or charles%hpcvca@hplabs.hp.com or hplabs!hpcvca!charles or "Hey you!" Not representing my employer.
jesup@cbmvax.UUCP (Randell Jesup) (09/02/89)
In article <1989Aug31.004647.12718@agate.uucp> mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) writes: >In article <7782@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: >< This was discussed at length months ago on BIX in amiga.dev/ ><suggestions. The final more-or-less consensus was that you should look ><for the string #!...!# (... being name of interpreter) anywhere in the ><first line. This allows embedding it in any type of comment. > >Someone who knows what's going to happen. Lotsa question... Note: I said the developers on Bix come to a consensus. Doesn't necessarily mean it will occur. >Is the search going to be length-limited, as well? Or will it search >in vain through a megabyte of database for the newline that isn't >there? I think the stipulation they said was 512 bytes max. >One of the first uses of #! on Unix was for a Pascal P-code >interpreter - the interpreter was tweaked to skip the first line, and >the compiler generated "#! pcodeinterpreter" as the first line, >followed by binary. What happens if someone has a similar binary >"script", the first word of which is 0x00000f3f? Or will that be >considered an error on the part of the compiler? I think you mean 0x3f3 (hunk_header). Sounds like a strange example. >I assumes this code is going into Execute(), as it needs to read the >first part of the binary in any case. That is the case, isn't it? It's >not going into the shell, is it? I didn't say it's going in anywhere. Might be, though. >If Execute() fires off an ARexx script, how will the script >communicate with the shell as a client? Or will the default shell not >be a client? I think ARexx support in the Shell is a good thing. ><There still needs to be some hard-coded recognitions of executables, ><AmigaDos scripts, and _perhaps_ ARexx scripts. > >Why? Backwards compatability, or does #!Execute!# fail? Because there are many scripts already written that we should not force people to rewrite. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
shadow@pawl.rpi.edu (Deven T. Corzine) (09/19/89)
In article <7782@cbmvax.UUCP>, jesup@cbmvax.UUCP (Randell Jesup) writes:
jesup> This was discussed at length months ago on BIX in
jesup> amiga.dev/ suggestions. The final more-or-less consensus was
jesup> that you should look for the string #!...!# (... being name of
jesup> interpreter) anywhere in the first line.
On 31 Aug 89 12:01:08 GMT,
peter@sugar.hackercorp.com (Peter da Silva) said:
peter> Isn't it nice when things fall together like this?
peter> I would recommend allowing it in more than just the first line,
peter> though, since some scripting languages like having the first
peter> line magic. Also, having some mechanism for passing extra
peter> arguments to the command interpreter would be useful.
I don't see that this is necessary. It looks to me that the best
solution is very much like Unix with a slight change. First line,
"#!" followed by interpreter location and optional args before script
arg. Stdin of interpreter is set to the script file, starting at the
SECOND line. That way, you don't have to worry about comment syntax.
(Granted, it could be a problem if you try to execute the script
without using the kernal call, then it would start at the first line
and comment syntax would matter.)
Deven
--
Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu
Snail: 2151 12th St. Apt. 4, Troy, NY 12180 Phone: (---) --none--
Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven
Simple things should be simple and complex things should be possible.jesup@cbmvax.UUCP (Randell Jesup) (09/20/89)
In article <SHADOW.89Sep19065156@pawl.rpi.edu> shadow@pawl.rpi.edu (Deven T. Corzine) writes: >peter> I would recommend allowing it in more than just the first line, >peter> though, since some scripting languages like having the first >peter> line magic. Also, having some mechanism for passing extra >peter> arguments to the command interpreter would be useful. > >I don't see that this is necessary. It looks to me that the best >solution is very much like Unix with a slight change. First line, >"#!" followed by interpreter location and optional args before script >arg. Stdin of interpreter is set to the script file, starting at the >SECOND line. That way, you don't have to worry about comment syntax. >(Granted, it could be a problem if you try to execute the script >without using the kernal call, then it would start at the first line >and comment syntax would matter.) Most interpreters don't take stdin as input, because (for example) you may not be able to Seek() stdin (pipes). Seeking is useful for loops and the like. Not being able to execute it directly from the interpreter is a big minus, too. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
cosell@bbn.com (Bernie Cosell) (09/20/89)
In article <7951@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: }In article <SHADOW.89Sep19065156@pawl.rpi.edu> shadow@pawl.rpi.edu (Deven T. Corzine) writes: }>peter> I would recommend allowing it in more than just the first line, }>peter> though, since some scripting languages like having the first }>peter> line magic. Also, having some mechanism for passing extra }>peter> arguments to the command interpreter would be useful. }> }>I don't see that this is necessary. It looks to me that the best }>solution is very much like Unix with a slight change. First line, }>"#!" followed by interpreter location and optional args before script }>arg. Stdin of interpreter is set to the script file, starting at the }>SECOND line. That way, you don't have to worry about comment syntax. }>(Granted, it could be a problem if you try to execute the script }>without using the kernal call, then it would start at the first line }>and comment syntax would matter.) } } Most interpreters don't take stdin as input, because (for }example) you may not be able to Seek() stdin (pipes). Seeking is useful }for loops and the like. Not being able to execute it directly from the }interpreter is a big minus, too. Actually, the problems are more significant than that: if you do as Deven suggested then you can't do pipes at all any more (since stdin is now consumed with the script, it cannot be the input from the previous process any more). To really make it all work, you have to establish a standard of having a *fourth* "default" file desciptor open "stdscript". [contrast the difference between doing "cat xxx | sh" and "cat yyy | sh xxx" ] /Bernie\
peter@sugar.hackercorp.com (Peter da Silva) (09/23/89)
I was talking about multiple scripting languages. On BIX they're suggesting using #!command!# to tell what the command interpreter is, anywhere on the first line... I continued: > peter> I would recommend allowing it in more than just the first line, > peter> though, since some scripting languages like having the first > peter> line magic. Also, having some mechanism for passing extra > peter> arguments to the command interpreter would be useful. Deven suggested doing it just like UNIX, except that when the interpreter is started up... In article <SHADOW.89Sep19065156@pawl.rpi.edu>, shadow@pawl.rpi.edu (Deven T. Corzine) writes: > Stdin of interpreter is set to the script file, starting at the > SECOND line. That way, you don't have to worry about comment syntax. Two problems: (1) This has to work with existing programs, that might not work with the script on Input(). (2) This has to allow interactive input, which goes by the wayside if Input() has been stolen. The best solution, if you want to change things, is to add a standard command input seperate from stdin (oddly, there are multiple input and output streams in struct CLI. Anyone care to compare and contrast: cli_StandardInput cli_CurrentInput cli_StandardOutput cli_CurrentOutput ????). -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U` "before making up your mind, please read the book." -- sherry.mann "This is contrary to the spirit of rec.arts.sf-lovers" -- Jim Winer
peter@sugar.hackercorp.com (Peter da Silva) (09/23/89)
In article <45815@bbn.COM>, cosell@bbn.com (Bernie Cosell) writes: > To really make it all work, you have to establish a standard of > having a *fourth* "default" file desciptor open "stdscript". Well, it'd be either a 3rd (there being pr_CIS and pr_COS already, but no stderr, making it a 3rd standard handle...) or a 5th (after cli_StandardInput, cli_CurrentInput, cli_StandardOutput, and cli_CurrentOutput). I think stdcmd is a good idea, by the way. -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U` "before making up your mind, please read the book." -- sherry.mann "This is contrary to the spirit of rec.arts.sf-lovers" -- Jim Winer
shadow@pawl.rpi.edu (Deven T. Corzine) (09/27/89)
On 22 Sep 89 17:12:51 GMT, peter@sugar.hackercorp.com (Peter da Silva) said: peter> Deven suggested doing it just like UNIX, except that when the peter> interpreter is started up... In article <SHADOW.89Sep19065156@pawl.rpi.edu>, shadow@pawl.rpi.edu (Deven T. Corzine) writes: Deven> Stdin of interpreter is set to the script file, starting at the Deven> SECOND line. That way, you don't have to worry about comment Deven> syntax. peter> Two problems: peter> (1) This has to work with existing programs, that might peter> not work with the script on Input(). But then you're right back to the same problem of the interpreter needing to filter it out. (though I suppose it would be easier to imbed in some other comment syntax...) peter> (2) This has to allow interactive input, which goes by the peter> wayside if Input() has been stolen. Good point. peter> The best solution, if you want to change things, is to add a peter> standard command input seperate from stdin [...] Maybe. Is it worth it? -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2151 12th St. Apt. 4, Troy, NY 12180 Phone: (---) --none-- Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.
peter@sugar.hackercorp.com (Peter da Silva) (09/28/89)
In article <SHADOW.89Sep27124548@pawl.rpi.edu>, shadow@pawl.rpi.edu (Deven T. Corzine) writes: > peter> The best solution, if you want to change things, is to add a > peter> standard command input seperate from stdin [...] > Maybe. Is it worth it? All the people adding REXX ports to programs think so. This is a different implementation of the same model. And one a lot easier to program. -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U` "before making up your mind, please read the book." -- sherry.mann "This is contrary to the spirit of rec.arts.sf-lovers" -- Jim Winer
shadow@pawl.rpi.edu (Deven T. Corzine) (10/06/89)
On 28 Sep 89 11:06:55 GMT, peter@sugar.hackercorp.com (Peter da Silva) said: peter> The best solution, if you want to change things, is to add a peter> standard command input seperate from stdin [...] Deven> Maybe. Is it worth it? peter> All the people adding REXX ports to programs think so. This is peter> a different implementation of the same model. And one a lot peter> easier to program. Not quite the same model. It's more of a datagram approach, as opposed to a sequenced stream... Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2151 12th St. Apt. 4, Troy, NY 12180 Phone: (518) 274-0327 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.