Greetings,

I'd like to extract the command-line arguments passed to a DMDScript script. For example, if I enter the following command:

    ds myscript.ds 1 "aaa" DMD

I would like the values:

    1
    aaa
    DMD

to be accessable from within the script.

I am able to accomplish this task via the Windows Scripting Host using the following code:

    // Extract command-line arguments, and load into
    // 'arguments' array
    if (WScript.Arguments.length < 1)
    {
      arguments = new Array(0);
    }
    else
    {
      arguments = new Array(WScript.Arguments.length);

      for (var i = 0 ; i < arguments.length; ++i)
        arguments[i] = WScript.Arguments(i);
    }

    // Display command-line arguments
    for (var i = 0 ; i < arguments.length; ++i)
      WScript.Echo("Argument[" + i + "] is " + arguments[i]);

Using DMDScript, the 'println' function is the obvious analog of 'WScript.Echo'. However, I'm not aware of a global array, or function, of similar functionality to, 'WScript.Arguments'.

So my questions are:

* Is there such an array or function natively available in
   DMDScript ?

* If not, is it possible to perhaps 'hook into' a D function
   with this functionality *without* having to modify the
   DMDScript source code, and recompile the interpreter ?

* If not, are there plans add such functionality to future
   versions of DMDScript ?

I look forward to any response.

Cheers,

Anthony Borla

Anthony Borla escribió:
> Greetings,
> 
> I'd like to extract the command-line arguments passed to a DMDScript script.
> For example, if I enter the following command:
> 
>     ds myscript.ds 1 "aaa" DMD
> 
> I would like the values:
> 
>     1
>     aaa
>     DMD
> 
> to be accessable from within the script.
> 
> I am able to accomplish this task via the Windows Scripting Host using the
> following code:
> 
>     // Extract command-line arguments, and load into
>     // 'arguments' array
>     if (WScript.Arguments.length < 1)
>     {
>       arguments = new Array(0);
>     }
>     else
>     {
>       arguments = new Array(WScript.Arguments.length);
> 
>       for (var i = 0 ; i < arguments.length; ++i)
>         arguments[i] = WScript.Arguments(i);
>     }
> 
>     // Display command-line arguments
>     for (var i = 0 ; i < arguments.length; ++i)
>       WScript.Echo("Argument[" + i + "] is " + arguments[i]);
> 
> Using DMDScript, the 'println' function is the obvious analog of
> 'WScript.Echo'. However, I'm not aware of a global array, or function, of
> similar functionality to, 'WScript.Arguments'.
> 
> So my questions are:
> 
> * Is there such an array or function natively available in
>    DMDScript ?
> 
> * If not, is it possible to perhaps 'hook into' a D function
>    with this functionality *without* having to modify the
>    DMDScript source code, and recompile the interpreter ?
> 
> * If not, are there plans add such functionality to future
>    versions of DMDScript ?
> 
> I look forward to any response.
> 
> Cheers,
> 
> Anthony Borla
> 
> 

DMDScript treats its command line arguments rather oddly, but there's a global variable "arguments". There're two paths you can take: modify DMDScript source (maybe testscript.d would be enough) so command line arguments are not treated as more source files and then pass them to the program, or use Walnut, which already does that for you. The problem with Walnut is that it's kinda on extended hold by now because I'm busy with other things, but I think there's a compiled version available for Windows on www.dsource.org which you can use (I'm not telling you to compile it because I doubt it'll compile.)

-- 
Carlos Santander Bernal

"Carlos Santander" <csantander619@gmail.com> wrote in message news:dk6lfb$26pr$1@digitaldaemon.com...
> Anthony Borla escribió:
> > Greetings,
> >

Carlos,

> >
> > I'd like to extract the command-line arguments passed
> > to a DMDScript script. For example, if I enter the
> > following command:
> >
<SNIP>
>
> DMDScript treats its command line arguments rather
> oddly, but there's a global variable "arguments".
>

That was the first thing I tried. Yes, a global 'arguments' exists, but command-line values do not get passed to them. For example, issuing from the command-line:

    ds myscript.ds X Y Z

should see the following occur in the script:

    ...
    println(arguments[0]);  // X printed
    println(arguments[1]);  // Y printed
    println(arguments[2]);  // Z printed
    ...

Instead the observed behaviour is:

    ...
    println(arguments[0]);  // undefined
    println(arguments[1]);  // "
    println(arguments[2]);  // "
    ...

and DMDScript interprets the first command-line argument as a file name:

    Error: X.ds: The system cannot find the file specified.

This is unintuitive behaviour for a command-line tool whether executed in a Windows-family, or a *NIX environment.

>
> There're two paths you can take: modify DMDScript
> source (maybe testscript.d would be enough) so
> command line arguments are not treated as more
> source files and then pass them to the program,
>

Yes, I *could* modify the source code and add the requisite behaviour [including remedying the other behavioural 'anomolies' mentioned in my other posts].

However, not being a D expert, it would take a significant amount of my time. To be quite honest, if I'd wanted to write D code, I'd do so, and not bother using an ECMAScript interpreter :) ! In addition, any enhancements would only be of benefit to users of this customised version of the interpreter rather than to all those future downloaders of DMScript from the DigitalMars website. Rather a waste of effort I should think !

>
> or use Walnut, which already does that for you. The problem
> with Walnut is that it's kinda on extended hold by now because
> I'm busy with other things, but I think there's a compiled version
> available for Windows on www.dsource.org which you can use
> (I'm not telling you to compile it because I doubt it'll compile.)
>

I truly do appreciate your suggestion because you are making a constructive suggestion to help me solve a specific problem. However, I'm not sure that using yet another tool to remedy a 'problem' in an existing tool is the answer [IMO it does not adhere to the KISS principle].

What I'd really like to see for my, and I'm sure, many other people's benefit, is a revised version of DMDScript which remedies the 'problems' I mentioned here, and in related posts. My argument for suggesting this is as follows.

Whilst DMDScript is presented as both a 'showcase' product for the D language, and as an embeddable ECMAScript interpreter [both roles, I believe, it admirably fulfils], it is also presented in a command-line version, presumably to act as a 'command-line tool'. Sadly, owing a number of minor, but behaviourally significant, deficiencies, it does not effectively fulfil this role. For example, I can't use it in my script files [I have to, instead, use WSH 5.6] because it can neither accept command-line arguments, return an exit code, nor correctly read text files. I'm sure I'm not the only one hampered by such difficulties.

Sadly, this serves only to limit DMDScript's potential user base. Further, it may even leave others with a poor, or negative, opinion of the product. It seems a shame to tarnish the reputation of an otherwise fine product by not applying a few 'finishing touches' to it.

Finally, I'm not being critical just for the sake of it. If I was in a position to make the requisite improvements I would have done so [I much prefer action to words, but this isn't always possible]. I would have thought, though, that in the four months since I first mentioned these problems, that some action by the relevant experts would have been taken.

Cheers,

Anthony Borla

P.S.

The version I've been using is:

    Digital Mars DMDScript 1.06
    www.digitalmars.com
    Compiled by Digital Mars DMD D compiler
    Copyright (c) 1999-2005 by Digital Mars
    written by Walter Bright

which I believe is the latest.

Wow.

Thanks for the heads up Anthony.  I've got to go do a friend's website today, but tommorrow I'll work on implementing (at least) one of your changes.

I actually noticed a few of the same problems.  :p  Needless to say, I thought DMDScript was a little more capable as well.  My understanding is though that it, at one point, did support command line arguments (it seems to be just choking on the first one?)

This may also explain why it doesn't accept piped input too.  :p  I haven't done any real homework into how piping text around works.  (call myself a programmer, gawd)

"Dan" <Dan_member@pathlink.com> wrote in message news:dk9bd0$1l4d$1@digitaldaemon.com...
>

Dan,

>
> Wow.
>
> Thanks for the heads up Anthony.  I've got to go do a friend's
> website today, but tommorrow I'll work on implementing
> (at least) one of your changes.
>
> I actually noticed a few of the same problems.  :p  Needless to say, I thought DMDScript was a little more capable as well.
>

It *is* definitely capable [e.g. exception handling works fine whilst it doesn't do so in WSH 5.6], and is *fast*, but it just has a few command-line operation-oriented 'glitches' which, I think, are crying out to be remedied.

To recap, the important ones are:

* Command-line argument processing; probably best
   to properly fill the global 'arguments' object so that:

       arguments[0]   // ==> 1st argument
       arguments[1]   // ==> 2nd argument

   and so on

* An 'exit' function to return an arbitrary integer value to
   the OS

* Fix 'readln' so it distinguishes between an 'empty' line
   and EOF. I'd imagine the easiest approach would be
   to have 'null' returned on EOF, and a zero-length string
   for 'empty' lines [since it 'eats' the line terminator]

With these in place it should be possible to, quite effectively, use DMDScript for command-line scripting such as, for example, creating filters.

Optionally, I suppose, file-oriented I/O could be expanded:

* 'open', 'close' functions, returning / taking a file
    handle / descriptor etc

* Extend 'readln' to accept a file handle / descriptor
   so that an arbitrary file can be read [same with 'print' and
   'println', for output]

but this would obviously be for another time.

>
> My understanding is though that it, at one point, did support command line arguments (it seems to be just choking on the first one?)
>

I honestly don't know the history. I downloaded DMDScript 1.6 a few months ago hoping to use it in my scripts [both Windows 'batch' and *NIX 'bash' scripts] but the problems I mentioned pretty well hampered those efforts.

>
> This may also explain why it doesn't accept piped input too.  :p
>

Yes, another command-line operation-oriented glitch. This would, I'd imagine, come under the task of getting 'readln' to work correctly.

>
> I haven't done any real homework into how piping
> text around works.
>

No need to know everything, just enough to allow the job at hand to be completed.

>
>  (call myself a programmer, gawd)
>

So do I. However these days I avoid compiled / statically-typed languages like the plague [only digging such tools out when I absolutely have to], and will continue to do so for as long as I am able.

Cheers,

Anthony Borla

P.S.

I can't really help with programming tasks [these, I find, are *always* very time-consuming even when they are - supposedly - minor or simple], but am more than happy to help in testing, and related matters.

With any luck, a DMDScript version 1.6x will soon be a reality :) !

Phhhh...

I just spent the whole week working on my new Asma library.  It is a macro library that allows HLL programming in NASM, including explicit STD/Pascal/C/Fastcall declaration AND calls, local variables (managed differently by calling method), switches, loops, if/else/elseif/endif, multiple push/pops and stuff like that.

It goes very nicely with my new assembly Array function library (that interestingly has most of the same functionality as the ECMAScript Array object with the JavaScript 1.6 extensions)

I did not, however, do any work on my modified DMDScript engine.  At this point, I'm thinking it's about time I publish that... :p  I'll post back when I've done that.

Okay, here is a link to a fuuuugly page where you can get the code I've done so far.  So far, all I've done is run it through my home-brewed DTidy.js script, which atm is only slightly better than your average tidier upper.  It also does some neat stuff with cleaning up branching logic.

Some obvious bugfixes need to be done, as was said earlier.

Also, it's obvious that there would be some performance/codesize improvements to be gained from unifying errmsgs.d and text.d (and use constants instead of array offsets + enums).  I was working on making textgen handle both, but I started working on Asma before I was done.

The other biggie I noticed is that DMDScript uses *cough*crap*cough* like malloc and memset to do stuff.  Fugly.  For most of those routines, they could be rewritten in 'bout 20 lines of asm for a 10-100% boost in performance.  That's before I even touch the ECMAScript method implementations.

So DMDScript is ~sexy~ but, I think a dedicated hacker could easily pull another 200% time complexity out of it without getting his hands dirty.

EEP.. so the fugly page is at:

http://code.murpsoft.com/dmdScript/index.asp

"Dan" <Dan_member@pathlink.com> wrote in message news:dkj4qu$26nu$1@digitaldaemon.com...
>

Dan,

>
> EEP.. so the fugly page is at:
>
> http://code.murpsoft.com/dmdScript/index.asp
>

Sorry for the delay in looking at this [got caught up at work], but will do so this weekend.

Cheers,

Anthony Borla

In DMDScript, the Global object is creating an array called arguments (I saw some things about it in the source).  I tested it out and for some stupid reason or another in Windows (at least) it's claiming that arguments is undefined.

Perhaps the symbol is not being linked to the array, perhaps something is buggered or perhaps I misunderstood.  I'll work on this tonight.

My test script:

for(var i = arguments.length-1; i--;){
println(arguments[i]);
}

This currently loops infinitely btw.  :p
Wish me luck!