www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - the D scripting language -- command line

reply spir <denis.spir gmail.com> writes:
[started separate thread]

On Thu, 11 Nov 2010 00:58:31 +0100
Tomek Sowi=C5=84ski <just ask.me> wrote:

 Andrei Alexandrescu napisa=C5=82:
=20
 Speaking of getopt, when writing the 'grep' snippet I missed anonymous
 options a lot:

 bool h, i; string expr; string[] files;
 getopt(args, "h",&h, "i",&i,&expr,&files);

 They can be implemented with relatively little effort.
=20 Not getting the example. How would anonymous options work?
=20 // Let's match assignments. auto args =3D ["program.exe", ".*=3D.*;", "file1.d", "file2.d", "file3.d"=
];
 bool h, i; string expr; string[] files;
 getopt(args, "h",&h, "i",&i, &expr, &files);
 assert(!h);
 assert(!i);
 assert(expr =3D=3D ".*=3D.*;");
 assert(files =3D=3D ["file1.d", "file2.d", "file3.d"]);
 assert(args =3D=3D ["program.exe"]);
=20
 Staying conservative, anonymous options would only be allowed at the end =
of the=20
 option list, because their order matters (unlike named options). Perhaps =
this can=20
 be relaxed with time.
I thought once at a default interface between the command-line and a progra= m's startup routine, main(). The idea would be for main to have parameters = automagically fed from whatever the user provides. With a command-line synt= ax inspired by named func call. It lets the program itself be called more o= r less like a func, via program-level parameter definition: // program "findword" int main (string filename, string word, bool verbose=3Dfalse) {...} // use it $ findword filename=3Dfoo.txt word=3Dfoo verbose=3Dtrue Parameters having default value can indeed be omitted by the user. Optional= ly, the first arg (often corresponding to the "object" on which a command a= pplies, like the receiver in OO, and thus usually "obvious") can be automat= ically mapped to the first param of main: $ findword foo.txt word=3Dfoo This is, indeed, a language-specific feature. On the other hand, it brings = to the user consistent program-call format -- rather than each program defi= ning its own. Maybe after sometime the same syntax trick and syntax would a= dopted by other languages. I find this very coool on the programmer side as well. It must indeed by im= plemented in the language('s runtime) itself. To have such a feature withou= t breaking any code, a possibility may be to use a different name than "mai= n", eg "script". (I guess such a feature would make some difference in judging a language's = adequacy to scripting.) What do you think? Denis -- -- -- -- -- -- -- vit esse estrany =E2=98=A3 spir.wikidot.com
Nov 11 2010
next sibling parent reply ruben niemann <replies here.zzz> writes:
spir Wrote:

 [started separate thread]
 
 On Thu, 11 Nov 2010 00:58:31 +0100
 Tomek Sowiński <just ask.me> wrote:
 
 Andrei Alexandrescu napisał:
 
 Speaking of getopt, when writing the 'grep' snippet I missed anonymous
 options a lot:

 bool h, i; string expr; string[] files;
 getopt(args, "h",&h, "i",&i,&expr,&files);

 They can be implemented with relatively little effort.
Not getting the example. How would anonymous options work?
// Let's match assignments. auto args = ["program.exe", ".*=.*;", "file1.d", "file2.d", "file3.d"]; bool h, i; string expr; string[] files; getopt(args, "h",&h, "i",&i, &expr, &files); assert(!h); assert(!i); assert(expr == ".*=.*;"); assert(files == ["file1.d", "file2.d", "file3.d"]); assert(args == ["program.exe"]); Staying conservative, anonymous options would only be allowed at the end of the option list, because their order matters (unlike named options). Perhaps this can be relaxed with time.
I thought once at a default interface between the command-line and a program's startup routine, main(). The idea would be for main to have parameters automagically fed from whatever the user provides. With a command-line syntax inspired by named func call. It lets the program itself be called more or less like a func, via program-level parameter definition: // program "findword" int main (string filename, string word, bool verbose=false) {...} // use it $ findword filename=foo.txt word=foo verbose=true Parameters having default value can indeed be omitted by the user. Optionally, the first arg (often corresponding to the "object" on which a command applies, like the receiver in OO, and thus usually "obvious") can be automatically mapped to the first param of main: $ findword foo.txt word=foo This is, indeed, a language-specific feature. On the other hand, it brings to the user consistent program-call format -- rather than each program defining its own. Maybe after sometime the same syntax trick and syntax would adopted by other languages. I find this very coool on the programmer side as well. It must indeed by implemented in the language('s runtime) itself. To have such a feature without breaking any code, a possibility may be to use a different name than "main", eg "script". (I guess such a feature would make some difference in judging a language's adequacy to scripting.) What do you think?
That's a nifty feature. I took a look at the scriptometer page. It looks like if more real scripting languages are coming there (one or two more), D will be out from the top-20. The script library and shortcuts are badly needed. D isn't (yet) even the best static compiled language in the test. At least two Java/JVM languages beat D and it doesn't yet even have the super tight Groovy. It's also still missing Clojure, Io, Factor, and those other "tight" languages. Looking bad without a dedicated library. The library might be good to contain features 'sed', 'grep', and fill the namespace with name globals. std.s sounds like a good name.
Nov 11 2010
parent sop <phobos std.s> writes:
ruben niemann Wrote:

 spir Wrote:
 
 [started separate thread]
 
 On Thu, 11 Nov 2010 00:58:31 +0100
 Tomek Sowiński <just ask.me> wrote:
 
 Andrei Alexandrescu napisał:
 
 Speaking of getopt, when writing the 'grep' snippet I missed anonymous
 options a lot:

 bool h, i; string expr; string[] files;
 getopt(args, "h",&h, "i",&i,&expr,&files);

 They can be implemented with relatively little effort.
Not getting the example. How would anonymous options work?
// Let's match assignments. auto args = ["program.exe", ".*=.*;", "file1.d", "file2.d", "file3.d"]; bool h, i; string expr; string[] files; getopt(args, "h",&h, "i",&i, &expr, &files); assert(!h); assert(!i); assert(expr == ".*=.*;"); assert(files == ["file1.d", "file2.d", "file3.d"]); assert(args == ["program.exe"]); Staying conservative, anonymous options would only be allowed at the end of the option list, because their order matters (unlike named options). Perhaps this can be relaxed with time.
I thought once at a default interface between the command-line and a program's startup routine, main(). The idea would be for main to have parameters automagically fed from whatever the user provides. With a command-line syntax inspired by named func call. It lets the program itself be called more or less like a func, via program-level parameter definition: // program "findword" int main (string filename, string word, bool verbose=false) {...} // use it $ findword filename=foo.txt word=foo verbose=true Parameters having default value can indeed be omitted by the user. Optionally, the first arg (often corresponding to the "object" on which a command applies, like the receiver in OO, and thus usually "obvious") can be automatically mapped to the first param of main: $ findword foo.txt word=foo This is, indeed, a language-specific feature. On the other hand, it brings to the user consistent program-call format -- rather than each program defining its own. Maybe after sometime the same syntax trick and syntax would adopted by other languages. I find this very coool on the programmer side as well. It must indeed by implemented in the language('s runtime) itself. To have such a feature without breaking any code, a possibility may be to use a different name than "main", eg "script". (I guess such a feature would make some difference in judging a language's adequacy to scripting.) What do you think?
That's a nifty feature. I took a look at the scriptometer page. It looks like if more real scripting languages are coming there (one or two more), D will be out from the top-20. The script library and shortcuts are badly needed. D isn't (yet) even the best static compiled language in the test. At least two Java/JVM languages beat D and it doesn't yet even have the super tight Groovy. It's also still missing Clojure, Io, Factor, and those other "tight" languages. Looking bad without a dedicated library. The library might be good to contain features 'sed', 'grep', and fill the namespace with name globals. std.s sounds like a good name.
Indeed. The many feces of d doesnt include sop " script oriented prog...
Nov 11 2010
prev sibling next sibling parent reply Adam Ruppe <destructionator gmail.com> writes:
spir wrote:
 I thought once at a default interface between the command-line and a
 program's startup routine, main().
We could actually do this with a mixin. ====== int findword (string filename, string word, bool verbose=false) {...} mixin MakeMain!(findword); ====== And that MakeMain template reads the arguments off findword() and creates a traditional main() that translates its args into the needed arguments of the function. I actually wrote something that does this already, though my goal was to automate the creation of web apps, it also (used to - I broke it in my last revision) works for command line programs. http://arsdnet.net/dcode/web.d See it in action with an example. Given this function: void addTopicToForum(int topicId, int forumId) { assert(0, "not implemented"); } We get this page: http://arsdnet.net/cgi-bin/forum/add-topic-to-forum?topicId=10 From just the function signature, it creates a form, populating it with all the arguments given on the URL, asking the user for the rest. If you give it all the arguments needed up front, it just skips to executing the function. The command line interface worked basically the same way. $ ./forum forumId=30 topidId=10 Assert error: not implemented But when adding support for array arguments in CGI, I broke the command line reader so I commented it out and haven't gotten back to fixing it yet. While my code is based on taking a struct to the make main mixin, so it can do multiple functions at once, it'd be pretty easy to modify it to just take one function directly too. You're free to take it and do whatever you want with it if you're interested.
Nov 11 2010
parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Thu, 11 Nov 2010 13:45:33 +0000, Adam Ruppe wrote:

 I actually wrote something that does this already, though my goal was to
 automate the creation of web apps, it also (used to - I broke it in my
 last revision) works for command line programs.
 
 http://arsdnet.net/dcode/web.d
 
 [...]
I briefly browsed through some of your modules now, and the web stuff (cgi, dom, web) is very interesting. I was actually looking for something like your CGI module just the other day. Have you ever considered cleaning it up and publishing it as a web app library for D, either on dsource or somewhere similar? -Lars
Nov 11 2010
parent Adam Ruppe <destructionator gmail.com> writes:
Lars T. Kyllingstad wrote:
 Have you ever considered cleaning it up and publishing it as
 a web app library for D, either on dsource or somewhere similar?
Yes, I'd like to do that eventually, but haven't gotten around to it yet. You can see, looking through the code, that I've been lax on documentation and there's a lot of half-baked things in there still. (Even some of the solider things feel incomplete to me, though I'm happy with it. For example, my mysql.d file always returns results as strings, so the client code has to check and convert data types without the help of the column info or anything like that. While it seems like it should be a tagged variant or something like that, using the raw strings has been so easy that I don't care to change it. int a = to!int(line[1]); is remarkably simple.) But, yeah, publishing it is the ultimate goal but I've gotta find the time to at least document it a little better first.
Nov 11 2010
prev sibling parent Tomek =?UTF-8?B?U293acWEc2tp?= <just ask.me> writes:
spir napisał:

 // Let's match assignments.
 auto args = ["program.exe", ".*=.*;", "file1.d", "file2.d", "file3.d"];
 bool h, i; string expr; string[] files;
 getopt(args, "h",&h, "i",&i, &expr, &files);
 assert(!h);
 assert(!i);
 assert(expr == ".*=.*;");
 assert(files == ["file1.d", "file2.d", "file3.d"]);
 assert(args == ["program.exe"]);

 Staying conservative, anonymous options would only be allowed at the end
 of the option list, because their order matters (unlike named options).
 Perhaps this can be relaxed with time.
I thought once at a default interface between the command-line and a program's startup routine, main(). The idea would be for main to have parameters automagically fed from whatever the user provides. With a command-line syntax inspired by named func call. It lets the program itself be called more or less like a func, via program-level parameter definition: // program "findword" int main (string filename, string word, bool verbose=false) {...} // use it $ findword filename=foo.txt word=foo verbose=true Parameters having default value can indeed be omitted by the user. Optionally, the first arg (often corresponding to the "object" on which a command applies, like the receiver in OO, and thus usually "obvious") can be automatically mapped to the first param of main: $ findword foo.txt word=foo This is, indeed, a language-specific feature. On the other hand, it brings to the user consistent program-call format -- rather than each program defining its own. Maybe after sometime the same syntax trick and syntax would adopted by other languages. I find this very coool on the programmer side as well. It must indeed by implemented in the language('s runtime) itself. To have such a feature without breaking any code, a possibility may be to use a different name than "main", eg "script". (I guess such a feature would make some difference in judging a language's adequacy to scripting.) What do you think?
Nice and terse, but let's not get carried away with the whole scripting thing. I'd be more than happy with getopt working at capacity. It can easily phase out most common boilerplate arg parsing. -- Tomek
Nov 11 2010