wrf@mab.ecse.rpi.edu (Wm Randolph Franklin) (11/13/90)
The interactive shell 'expect' looks useful according to the long shell summary. What is it and where would I get it? Thanks. -- Wm. Randolph Franklin Internet: wrf@ecse.rpi.edu (or @cs.rpi.edu) Bitnet: Wrfrankl@Rpitsmts Telephone: (518) 276-6077; Telex: 6716050 RPI TROU; Fax: (518) 276-6261 Paper: ECSE Dept., 6026 JEC, Rensselaer Polytechnic Inst, Troy NY, 12180
merlyn@iwarp.intel.com (Randal Schwartz) (11/14/90)
In article <~|&^%V&@rpi.edu>, wrf@mab (Wm Randolph Franklin) writes: | | The interactive shell 'expect' looks useful according to the long shell | summary. What is it and where would I get it? Thanks. Don Libes' 'expect' package comes from durer.cme.nist.gov near pub/expect.shar.Z. A Perl version with similar interfaces and the same functionality is in the works (if you're not interested in learning TCL, but already have some Perl experience)... see comp.lang.perl for details. Just another Perl hacker, -- /=Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 ==========\ | on contract to Intel's iWarp project, Beaverton, Oregon, USA, Sol III | | merlyn@iwarp.intel.com ...!any-MX-mailer-like-uunet!iwarp.intel.com!merlyn | \=Cute Quote: "Intel put the 'backward' in 'backward compatible'..."=========/
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (11/14/90)
In article <1990Nov13.212403.11129@iwarp.intel.com> merlyn@iwarp.intel.com (Randal Schwartz) writes: > In article <~|&^%V&@rpi.edu>, wrf@mab (Wm Randolph Franklin) writes: > | The interactive shell 'expect' looks useful according to the long shell > | summary. What is it and where would I get it? Thanks. > A Perl version with similar interfaces and the same functionality is > in the works (if you're not interested in learning TCL, but already > have some Perl experience)... see comp.lang.perl for details. And if you just want to stick to sh for the automation, do so. Why learn a different language---whether TCL or Perl---if you don't have to? Most ``interactive'' programs demand to talk to a tty; you'll have to use a tool like pty (comp.sources.unix volume 23, or ftp 128.122.128.22) to make them behave. But replacing ``telnet'' with ``pty telnet'' is a lot simpler than learning a new language for automation. ---Dan
tchrist@convex.COM (Tom Christiansen) (11/14/90)
In article <7316:Nov1408:33:0390@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes, quoting Randal: >And if you just want to stick to sh for the automation, do so. Why learn >a different language---whether TCL or Perl---if you don't have to? Because, Dan, when we're too old to learn something new, we're already dead and someone might as well just shoot us so the rest of the world can get on with life. TCL and Perl offer significant control advantages that are not simply expressible in that ancient and tired tool, the shell. Please stop disparaging other people's work, and please stop the constant commercials for your own, at least on a daily basis. There is a time and a place for everything. UNIX is an environment that well lends itself to multiple forms of expression. Pluralism is not a bug, but a feature. Learn something new every day. --tom
goer@quads.uchicago.edu (Richard L. Goerwitz) (11/15/90)
In <108721@convex.convex.com> tchrist@convex.COM (Tom Christiansen) writes: > >>And if you just want to stick to sh for the automation, do so. Why learn >>a different language---whether TCL or Perl---if you don't have to? > >Because, Dan, when we're too old to learn something new, we're already >dead and someone might as well just shoot us so the rest of the world can >get on with life.... > >Please stop disparaging other people's work, and please stop the constant >commercials for your own, at least on a daily basis. There is a time and >a place for everything.... > >Learn something new every day. A bit preachy, aren't we? Maybe it was called for. Anyway, this is not my battle. Most of us just don't have the time to get carried along by each new language, as it appears. We must be selective, learning thoroughly only those tools which are a) widely installed and b) sufficient for our purposes. While Perl might be sufficient for many purposes, it certainly isn't portable in the same sense that csh and sh are. I'm not defending the notion that no one should bother with Perl. In fact, I hope people do. If it does in fact stabilize, and get good documentation, and become widely installed, then I will most definitely want to use it in place of ugly conglomerations of sed, awk, and sh. -Richard (goer@sophist.uchicago.edu)
lerman@stpstn.UUCP (Ken Lerman) (11/16/90)
In article <1990Nov15.054937.27996@midway.uchicago.edu> goer@quads.uchicago.edu (Richard L. Goerwitz) writes:
[...]
->I'm not defending the notion that no one should bother with Perl. In
->fact, I hope people do. If it does in fact stabilize, and get good
->documentation, and become widely installed, then I will most definitely
->want to use it in place of ugly conglomerations of sed, awk, and sh.
->
->-Richard (goer@sophist.uchicago.edu)
Shouldn't you write:.........................then I will most definitely
wnat to use it in place of OTHER ugly conglomerations of sed, awk, and sh.
:-)
No, I am not disparaging perl, because I don't know enough about it.
But from the little I know about perl, I don't believe it solves what
I perceive to be the problem. What we (or I) need is a simple,
elegant, extensible tool that is easy to learn and use. Do people
seriously claim that perl is it? If so, then perhaps it is time for
me to spend some time with my perl manual.
Kenbrnstnd@kramden.acf.nyu.edu (Dan Bernstein) (11/17/90)
No technical content. In article <108721@convex.convex.com> tchrist@convex.COM (Tom Christiansen) writes: > In article <7316:Nov1408:33:0390@kramden.acf.nyu.edu> > brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes, quoting Randal: > >And if you just want to stick to sh for the automation, do so. Why learn > >a different language---whether TCL or Perl---if you don't have to? > Because, Dan, when we're too old to learn something new, we're already > dead and someone might as well just shoot us so the rest of the world can > get on with life. Did you wake up on the wrong side of the bed this morning? > TCL and Perl offer significant control advantages that are not simply > expressible in that ancient and tired tool, the shell. Obviously they are more powerful. That doesn't mean that they're necessary for solving real-world problems. As I said, if you just want to stick to sh for the automation, do so. Sometimes I find it easier to use sh and special-purpose tools; sometimes I find it easier to use general-purpose tools. It's just a personal decision, and I see no reason not to inform readers of the alternatives. > Please stop disparaging other people's work, Oh, grow up. Proposing alternatives is not ``disparaging'' anything. When Don posts an expect script or Larry posts a Perl script and I post an equivalent version in sh plus tools, I'm offering readers a choice. That's a lot more productive than posting a whining article like yours. Why don't you contribute something to the network before you disparage other people's contributions? ---Dan
libes@cme.nist.gov (Don Libes) (11/19/90)
In article <22547:Nov1620:27:0690@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >No technical content. > >> Please stop disparaging other people's work, [Tom Christiansen] >Oh, grow up. Proposing alternatives is not ``disparaging'' anything. [Dan B] Tom never said that your proposing alternatives was disparaging. What he was referring to was that your accompanying text often includes disparaging remarks. For example, in the followup to Tom you said "grow up", "wake up on the wrong side of the bed this morning?", "whining article like yours" and other ad hominem remarks. You often purposely misinterpret, such as taking Tom's remark to apply to posting alternatives, which he obviously didn't mean. It is easy to draw conclusions this way that have no relevance to the original discussion. >Why don't you contribute something to the network before you disparage >other people's contributions? >---Dan Your ignorance is no justification for denying Tom's opinions merit. In fact, Tom has produced excellent work that is available to the network.
peter@ficc.ferranti.com (Peter da Silva) (11/21/90)
In article <7316:Nov1408:33:0390@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > Most ``interactive'' programs demand to talk to a tty; you'll have to > use a tool like pty (comp.sources.unix volume 23, or ftp 128.122.128.22) > to make them behave. But replacing ``telnet'' with ``pty telnet'' is a > lot simpler than learning a new language for automation. Of course TCL is a whole lot more portable than Perl or PTY. I can run TCL on Xenix-286, with no PTY drivers and a compiler that gets the dry heaves when faced with Perl. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
thorinn@rimfaxe.diku.dk (Lars Henrik Mathiesen) (11/23/90)
lerman@stpstn.UUCP (Ken Lerman) writes: >In article <1990Nov15.054937.27996@midway.uchicago.edu> goer@quads.uchicago.edu (Richard L. Goerwitz) writes: >[...] >Shouldn't you write:.........................then I will most definitely > want to use it in place of OTHER ugly conglomerations of sed, awk, and sh. >No, I am not disparaging perl, because I don't know enough about it. >But from the little I know about perl, I don't believe it solves what >I perceive to be the problem. What we (or I) need is a simple, >elegant, extensible tool that is easy to learn and use. Do people >seriously claim that perl is it? If so, then perhaps it is time for >me to spend some time with my perl manual. Perl is a somewhat complex, somewhat kludgy tool which allows you to do (almost?) everything you can do in a Bourne shell script using sed, awk, test and expr. It is extensible in much the same way, by piping to or from other programs. It seems to me to have a good balance between simplicity and features, and between elegance and usefulness. The goal, after all, is to allow a system programmer to express the algorithms they need with a minimum of fuss. My first Perl script took me an afternoon of trying out versions with manual in hand. It involved taking a list of names in upper case, properly capitalizing them, and merging them into the gecos field of the password file. In this case, I might have been able to make an awk script in half the time, but next time I don't think Perl will be harder to write for. My feeling is that I will almost always be more sure of what a Perl script means than of the meaning of a shell script of similar complexity. A large part of this difference comes from the almost quoting-free regular expressions and the ``unifying'' of testing and control. And with the reputation of Larry Wall, I trust the core features of Perl to ``do what it means'' at least as much as I trust a 4.3BSD awk, for instance. So, elegant and simple: no. Simpler and easier to learn, write and maintain than sh, sed, awk, expr, test: yes, indeed. -- Lars Mathiesen, DIKU, U of Copenhagen, Denmark [uunet!]mcsun!diku!thorinn Institute of Datalogy -- we're scientists, not engineers. thorinn@diku.dk
dnb@meshugge.media.mit.edu (David N. Blank) (11/23/90)
> And with the reputation of Larry Wall, I trust the core features of > Perl to ``do what it means'' at least as much as I trust a 4.3BSD awk, > for instance. Well, I don't know much about Mr. Wall's reputation (so that's why people run away scared when they see him in a dark alley!), but I do add one more thing to your list: just next door in comp.lang.perl, Larry's presence is *constant* (pre-defined, beat you to the pun, nyah), answering questions, taking bug reports and suggestions, making recommendation on how to make the most of his tool and so on. When was the last time you saw Mr. Aho and his collegues here saying "Oh, no, you meant to say 'print $x', not 'sprint $x' here. And BTW, saying 'print <blah>' runs faster than 'print <bleh>'?" Peace, dNb P.S. no I'm not a perl groupie, and no this was not a paid endorsement by the Larry Wall for Netgod Committee.
rh@smds.UUCP (Richard Harter) (11/23/90)
In article <5808@stpstn.UUCP>, lerman@stpstn.UUCP (Ken Lerman) writes: > No, I am not disparaging perl, because I don't know enough about it. > But from the little I know about perl, I don't believe it solves what > I perceive to be the problem. What we (or I) need is a simple, > elegant, extensible tool that is easy to learn and use. Do people > seriously claim that perl is it? If so, then perhaps it is time for > me to spend some time with my perl manual. I have what you want. Trust me. :-) Seriously, I am working on a shell-like language which is supposed to meet those requirements; I am interested in comments on the features and capabilities that such a language should have. The first generation is in beta test now. I have taken exactly the opposite tack from perl -- the syntax has been stripped down as far as possible, and the temptation to use special characters has been ruthlessly rejected. If any one has comments about what features from sed/awk/perl/sh/find etc are particularly crucial I would be interested in hearing them. -- Richard Harter, Software Maintenance and Development Systems, Inc. Net address: jjmhome!smds!rh Phone: 508-369-7398 US Mail: SMDS Inc., PO Box 555, Concord MA 01742 This sentence no verb. This sentence short. This signature done.
tchrist@convex.COM (Tom Christiansen) (11/24/90)
In article <5808@stpstn.UUCP> lerman@stpstn.UUCP (Ken Lerman) writes: >No, I am not disparaging perl, because I don't know enough about it. >But from the little I know about perl, I don't believe it solves what >I perceive to be the problem. What we (or I) need is a simple, >elegant, extensible tool that is easy to learn and use. Do people >seriously claim that perl is it? If so, then perhaps it is time for >me to spend some time with my perl manual. Perl meets most of your criteria; the one it doesn't really satisfy is that of elegance. Quoting from the 3rd sentence of its man page: The language is intended to practical (easy-to-use, efficient, complete) rather than beautiful (tiny, elegant, minimal). So if you value elegance beyond all other virtues, then you might be a trifle scandalized by some of "features" lurking in dim corners of perl's baroque periphery. But if you want something that's easy to learn and use, as well as extensible and quick, then I think you might be doing yourself a favor by sitting down and looking at it. It may be pathologically eclectic, but it gets the job done, and well. At its most basic core, perl is about text processing. You can do a lot more with it than that, but this is the problem-area perl was developed to address. For example: if you look around at languages that recognize the symbols $1 through $9, you'll see these are used for the thing nearest to that language's main purpose. The shell sees $1 through $9 as command arguments; troff has them as macro arguments; yacc uses them in its parsing of productions; awk sees them as fields on each input line. Perl, however, uses those for subexpressions in the last pattern match. Here's a snippet of a perl program that shows you how the pattern matching has been merged in the with control flow in a way that I consider elegant, and which you should at least consider expedient: $now = `date`; # note backticks while ( <FILE> ) { # read a line into pattern space if (! s/red/blue/g) { print STDERR "i changed no red to blue on $now\n"; next; # like "continue" in C } if ( /^flag: (.*)/ ) { print STDERR "saw flag: $1\n"; $flags{$1}++; s/$&//; # $& is all of last match } if (/one: (.*) two: (.*) three: (.*)/) { do some_function($2, $3, $1); if ($flags{'silver'} || $flags{'gold'}) { tr/a-z/A-Z/; # capitalize s/$/wow!/; # append wow! to pattern space } } print; # print current pattern space } This doesn't really do anything useful, but it shows how the control flow and pattern operations can be used together. It also shows you how perl's quoting is like the shells, and introduces you the other of the two most powerful aspects of perl: the arrays that you can subscript with strings, as you can in awk. You can often use one reference to an array of this sort instead of a big, long looping algorithm in other languages. Was the code above too bizarre to even contemplate reading and understanding, or did you basically understand what was going on? I've taught perl to hundreds of people with some prior experience in other UNIX tools (sh, awk, sed, C) and they've all taken to it pretty quickly. This is enough to get you going, but there is more that you'd want to read up on eventually, because I didn't even mention how to do other kinds of file handling and I/O, subroutine and local variables, niftier regular expression stuff, or how your arrays can be bound to dbm files for persistent data and processing certain system databases quickly. Perl is by no means the right tool for every possible problem, but when it comes to simple text processing and report generation, it works quite well as a Practical Extraction and Report Language. There's a pretty active discussion and question/answer group next door in comp.lang.perl; you might want to check it out. --tom
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (11/26/90)
In article <109191@convex.convex.com> tchrist@convex.COM (Tom Christiansen) writes: | Perl meets most of your criteria; the one it doesn't really satisfy | is that of elegance. Quoting from the 3rd sentence of its man page: | | The language is intended to practical (easy-to-use, efficient, | complete) rather than beautiful (tiny, elegant, minimal). I personally find that "complex" and "easy to use" are somewhat at variance. If you don't use perl frequently you are unlikely to use it at all. It's just too large a language to use three times a year and remember any significant portion. Perl is the PL/I of implementation languages, and what we need is "subset G." -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
peter@ficc.ferranti.com (Peter da Silva) (11/27/90)
Perhaps Larry Wall can be talked into moderating comp.sources.something... :-> -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
peter@ficc.ferranti.com (Peter da Silva) (11/27/90)
In article <254@smds.UUCP> rh@smds.UUCP (Richard Harter) writes: > I have taken exactly the opposite tack from perl -- the syntax has been > stripped down as far as possible, and the temptation to use special > characters has been ruthlessly rejected. You mean like TCL? (well, at least THAT has something to do with the Subject:) -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (11/29/90)
In article <:E37D.6@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: > In article <7316:Nov1408:33:0390@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > > Most ``interactive'' programs demand to talk to a tty; you'll have to > > use a tool like pty (comp.sources.unix volume 23, or ftp 128.122.128.22) > > to make them behave. But replacing ``telnet'' with ``pty telnet'' is a > > lot simpler than learning a new language for automation. > Of course TCL is a whole lot more portable than Perl or PTY. I can run > TCL on Xenix-286, with no PTY drivers and a compiler that gets the dry > heaves when faced with Perl. Yes, and C is a whole lot more portable than TCL. I can run it on practically every machine bigger than a Sinclair. So? My point was that a tool is easier to use when you don't have to learn an entirely new language for it. sh, despite its flaws, is the scripting language of choice for most UNIX programmers; TCL and Perl are not (yet) even close to as widely available. A tool like pty can be applied from any language: sh, TCL, Perl, C, or whatever you like. Why bother learning a new language just to take advantage of a system feature? ---Dan