| View previous topic :: View next topic |
| Author |
Message |
Holysword
l33t
Joined: 19 Nov 2006
Posts: 683
Location: Greece
|
 Posted: Fri Apr 27, 2012 8:54 am Post subject: Scripting Language - Advices? |
 |
|
Hi there!
I have been working on tons of scripts to perform some boring tasks using simply bash, but they are growing in complexity and I am afraid it would be better to start re-writting everything.
Things that annoys me in bash:
- Lack of mathematical stuffs (cannot use if [ 3.2 < 8.9 ], have to use bc for doing that)
- Cannot "return" a value from a function, even less an array of values! (have to echo it in a weird way)
- Error handling is quite challenging, but possible
Things I love in bash:
- Accept function names with weird characters (αδσφγ for instance). And I like it.
- My parameter file (or any variables file) can be stored in another bash file and a simple "source $filename" loads everything - no need to parse parameters
- Oh yeah, parameter files are human-readable and can be modified by hand if needed
- Using external commands is just plain straightforward
- Few things are simpler than bash
- Wildcards, regular expressions, piping
- ${MYSTRING#$A} and its relatives
Of course, there are many other issues in bash (lack of classes, debugger, etc), but currently I don't miss these much for the purpose of my scripts.
When/if I rewrite everything, which language should I use? The main point of my scripts is being able to read parameter files easily. I've considered Python/Ruby, but it seems a bit of an overkill (would it be straightforward to read parameters?). I've thought about Perl, if I remember correctly it is easy to read parameter files with it.
So, suggestions? Please, let me know why you think your suggestion is feasible!
Thanks in advance
_________________
i7-720QM | nVidia GT 230M | 4 GB DDR3
"Nolite arbitrari quia venerim mittere pacem in terram non veni pacem mittere sed gladium" (Yeshua Ha Mashiach)
Last edited by Holysword on Sat Apr 28, 2012 10:50 am; edited 2 times in total |
|
| Back to top |
|
 |
Dr.Willy
Apprentice
Joined: 15 Jul 2007
Posts: 288
Location: NRW, Germany
|
| Posted: Fri Apr 27, 2012 9:30 am Post subject: Re: Scripting Language - Advices? |
|
|
| Holysword wrote: | | The main point of my scripts is being able to read parameter files easily. I've considered Python/Ruby, but it seems a bit of an overkill (would it be straightforward to read parameters?). |
You mean something like http://docs.python.org/library/configparser.html |
|
| Back to top |
|
|
Holysword
l33t
Joined: 19 Nov 2006
Posts: 683
Location: Greece
|
| Posted: Fri Apr 27, 2012 11:32 am Post subject: Re: Scripting Language - Advices? |
|
|
| Dr.Willy wrote: | | Holysword wrote: | | The main point of my scripts is being able to read parameter files easily. I've considered Python/Ruby, but it seems a bit of an overkill (would it be straightforward to read parameters?). |
You mean something like http://docs.python.org/library/configparser.html |
Yeps, exactly like that! However, would Python match the other criteria?
_________________
i7-720QM | nVidia GT 230M | 4 GB DDR3
"Nolite arbitrari quia venerim mittere pacem in terram non veni pacem mittere sed gladium" (Yeshua Ha Mashiach) |
|
| Back to top |
|
|
John R. Graham
Administrator
Joined: 08 Mar 2005
Posts: 6449
Location: Somewhere over Atlanta, Georgia
|
| Posted: Fri Apr 27, 2012 12:02 pm Post subject: |
|
|
I really didn't see any criteria except "parsing parameter files", which is text parsing. The most ubiquitous tools in that role (in both order of increasing complexity and power) are- AWK. It's hard to beat the power you get with AWK at its complexity level. I use AWK more than any other text processing tool.
- Perl. It's impossible to beat the power and expressiveness of Perl for text parsing. However, although the learning curve is initially shallow, exploiting the power causes the learning curve to steepen dramatically.
Python is more rigorously structured and more natively object oriented than either of them. I think you'll like how your solutions look in Python but you're likely to get there faster in AWK or (once you're fluent) Perl.
- John
_________________
This space intentionally left blank. |
|
| Back to top |
|
|
i92guboj
Moderator
Joined: 30 Nov 2004
Posts: 9464
Location: Córdoba (Spain)
|
| Posted: Fri Apr 27, 2012 12:22 pm Post subject: |
|
|
Both perl and python would be the number one candidates when shell scripting is not enough. There are many more language that some people would suggest you, like php, ruby, etc. I do not.
| Quote: |
Things that annoys me in bash:
Lack of mathematical stuffs (cannot use if [ 3.2 < 8.9 ], have to use bc for doing that)
|
Concretely, floating point maths is something that shells do not play well with. ksh is slightly better in this regard if my memory serves correctly. But I am not sure that it's capabilities are, you'll have to check that yourself.
| Quote: |
Cannot "return" a value from a function, even less an array of values! (have to echo it in a weird way)
|
Well, you can "return" in the typical sense an exit value (that'd be just an integer, and that's about it, nothing else).
However, in bash, all the vars are global by default, so you don't have to worry much about that. In shell scripting, this is often an advantage. If your project is big it can be a real problem, but if it's really that big that the scope of variables or the memory they use starts becoming a problem then you obviously chose the wrong language.
You might find this interesting:
http://www.linuxjournal.com/content/return-values-bash-functions
| Quote: |
My parameter file (or any variables file) can be stored in another bash file and a simple "source $filename" loads everything - no need to parse parameters
|
Opening files is a matter of a couple lines, in any language. What to do with the contents is another story. Bash can source files that are valid shell scripts. Other languages might be able to do similar things via their own inclusion mechanism, as long as the read file is a valid file in that language. Obviously, you can't expect python to be able to just "source" a bash shell file without any intermediary...
| Quote: |
Things I love in bash:
Accept function names with weird characters (αδσφγ for instance). And I like it.
|
About non-standard characters in the language reserved keywords, I have no idea. You'll probably hit some limitations on most languages, but I never needed to worry about that. Of course most modern language (these included) will support localization and literal strings in about any language you can think of.
If you'll be seeking from help in an international forum like this, however, this is the best way to ensure that you won't receive any help, unless you translate everything before posting your code (which might in turn introduce a couple more errors in the code). This is something that most language do not care about because it would limit the readability and maintainability of the code.
| Quote: |
Oh yeah, parameter files are human-readable and can be modified by hand if needed
Using external commands is just plain straightforward
Few things are simpler than bash
Wildcards, regular expressions, piping
${MYSTRING#$A} and its relatives |
These (but for regexp stuff) are all tasks that you always do in a shell. The shell is made for this tasks, so it's quite good at them.
String mangling is more powerful in perl (probably so in python as well). The good thing about bash is that it can work very well with sed and awk, and there are few tools that exceeds the power of these two when it comes to matching, parsing and editing regular expressions.
All in all, you have to really put in the balance whether you are willing to sacrifice easy coding for the versatility that a general purpose language (even if it's a scripting language) can give you. Or, look for another shell language. There are many.
_________________
Gentoo Handbook | My website
Last edited by i92guboj on Fri Apr 27, 2012 12:27 pm; edited 2 times in total |
|
| Back to top |
|
|
Holysword
l33t
Joined: 19 Nov 2006
Posts: 683
Location: Greece
|
| Posted: Fri Apr 27, 2012 12:23 pm Post subject: |
|
|
| John R. Graham wrote: | | I really didn't see any criteria except "parsing parameter files", which is text parsing. |
You're right, I didn't express myself correctly. What I meant was: what about the other advantages/disadvantage? Dr.Willy explained how to parse parameter files in python, but didn't mention how to deal with regular expressions and etc.
| John R. Graham wrote: | The most ubiquitous tools in that role (in both order of increasing complexity and power) are- AWK. It's hard to beat the power you get with AWK at its complexity level. I use AWK more than any other text processing tool.
- Perl. It's impossible to beat the power and expressiveness of Perl for text parsing. However, although the learning curve is initially shallow, exploiting the power causes the learning curve to steepen dramatically.
Python is more rigorously structured and more natively object oriented than either of them. I think you'll like how your solutions look in Python but you're likely to get there faster in AWK or (once you're fluent) Perl.
- John |
I have been reading a lot of stuffs, mainly comparing Perl with Python, and Python didn't convince me so far - all its extra features seem useless for this particular application of mine. Maybe I have this intrinsic problem with free-format. I've heard one thousand times "you will get used to it" but I'm still dubious.
_________________
i7-720QM | nVidia GT 230M | 4 GB DDR3
"Nolite arbitrari quia venerim mittere pacem in terram non veni pacem mittere sed gladium" (Yeshua Ha Mashiach) |
|
| Back to top |
|
|
Holysword
l33t
Joined: 19 Nov 2006
Posts: 683
Location: Greece
|
| Posted: Fri Apr 27, 2012 12:33 pm Post subject: |
|
|
That's what I meant with "have to echo it in a weird way". That's pretty tricky though!
| i92guboj wrote: | | All in all, you have to really put in the balance whether you are willing to sacrifice easy coding for the versatility that a general purpose language (even if it's a scripting language) can give you. |
Well, one possibility that I have not mentioned so far is to keep bash! Error handling would be tough though.
I am, however, leaning slowly and slowly towards Perl.
_________________
i7-720QM | nVidia GT 230M | 4 GB DDR3
"Nolite arbitrari quia venerim mittere pacem in terram non veni pacem mittere sed gladium" (Yeshua Ha Mashiach) |
|
| Back to top |
|
|
John R. Graham
Administrator
Joined: 08 Mar 2005
Posts: 6449
Location: Somewhere over Atlanta, Georgia
|
| Posted: Fri Apr 27, 2012 12:36 pm Post subject: |
|
|
| Holysword wrote: | | ... Dr.Willy explained how to parse parameter files in python, but didn't mention how to deal with regular expressions and etc. ... |
That would be through the re module. Here, let me Google that for you. 
You can't go wrong learning Perl. Working through the complexities of Perl regular expressions will be a mind bending—er, expanding—exercise (if you don't know Perl's regular expressions, you don't know Perl) and Perl will be a useful tool in your capability toolbox.
- John
_________________
This space intentionally left blank. |
|
| Back to top |
|
|
Ormaaj
Guru
Joined: 28 Jan 2008
Posts: 312
|
| Posted: Fri Apr 27, 2012 12:49 pm Post subject: |
|
|
Sounds like you haven't even decided whether you really want a shell... If unsure about this, the answer is probably no.
| Quote: | | Cannot "return" a value from a function, even less an array of values! (have to echo it in a weird way) |
This is true of everything that resembles a bourne-like shell. There a huge number of hacks in Bash to work around it. None are perfect, many are undocumented.
| Quote: | | Lack of mathematical stuffs (cannot use if [ 3.2 < 8.9 ], have to use bc for doing that) |
Depends on the shell.
| Quote: | | Error handling is quite challenging, but possible |
Zsh has try/catch. I don't recommend zsh for scripting. The standard error handling is fine for most things.
| Quote: | | Accept function names with weird characters (αδσφγ for instance). And I like it. |
This is non-standard and highly non-portable. Bash should only accept valid names even according to its own documentation, instead it accepts anything not containing a metacharacter or other reserved word. Don't use those.
| Quote: | My parameter file (or any variables file) can be stored in another bash file and a simple "source $filename" loads everything - no need to parse parameters
Oh yeah, parameter files are human-readable and can be modified by hand if needed
Using external commands is just plain straightforward
Wildcards, piping
${MYSTRING#$A} and its relatives |
Any shell can do all of those, and any scripting language has some analogue of them.
| Quote: | | regular expressions |
Bash and ksh have them. (and every real language).
| Quote: | | Of course, there are many other issues in bash (lack of classes, debugger, etc) |
Bash has the best debugging features of any shell by far. You can use bashdb if you really need it.
If you DO for some reason actually need a shell for large scripting jobs which require datastructures, use AT&T ksh93. It's lightyears ahead of Bash in terms of scripting power and solves most of the above problems: multiple ways of "returning" arbitrary datastructures safely (namerefs, print/read -C, lexical scope), math (floats, full math.h functions, user-defined math functions), and some simple OO / user-defined types (classes), namespaces, constructors, structs, enums, multidimensional arrays, etc, with very few big syntax changes vs Bash. It also outperforms Bash (and everything else) in pretty much every way, by a huge margin.
But before considering any of that, think about why you're not just using Python/Ruby/Perl (whichever you're most familiar with.)
| Quote: | | Few things are simpler than bash |
LOL! |
|
| Back to top |
|
|
John R. Graham
Administrator
Joined: 08 Mar 2005
Posts: 6449
Location: Somewhere over Atlanta, Georgia
|
| Posted: Fri Apr 27, 2012 1:13 pm Post subject: |
|
|
I reacted to that, too.  | Quote: | Nobody really knows what the Bourne shell's grammar is. Even examination of the source code is little help.
— Tom Duff |
- John
_________________
This space intentionally left blank. |
|
| Back to top |
|
|
i92guboj
Moderator
Joined: 30 Nov 2004
Posts: 9464
Location: Córdoba (Spain)
|
| Posted: Fri Apr 27, 2012 2:11 pm Post subject: |
|
|
Well, it depends 
Once you get the hang of it, it's quite simple when you need to hack something together that will work with little effort. It can do a lot with a few lines of code.
But simple tools become complicated when you try to build a medium-sized building (or a skyscraper) using them. In that case, you need the real machinery, and not just a hammer and a swiss knife.
_________________
Gentoo Handbook | My website |
|
| Back to top |
|
|
mv
Advocate
Joined: 20 Apr 2005
Posts: 3159
|
| Posted: Fri Apr 27, 2012 3:39 pm Post subject: Re: Scripting Language - Advices? |
|
|
I think reasonable language choices are currently: zsh, perl, python
The order is in increasing "high-levelness", i.e. typical shell-tasks like calling external commands or piping are easiest written in zsh, slightly longer in perl, and more longer in python.
| Holysword wrote: | - Lack of mathematical stuffs (cannot use if [ 3.2 < 8.9 ], have to use bc for doing that)
- Cannot "return" a value from a function, even less an array of values! (have to echo it in a weird way)
- Error handling is quite challenging, but possible
|
Except for the "return" in zsh, the above three languages have no problems with these points. However, the languages are command-oriented (in contrast to functional-oriented), and in such language (C or C++ are other such examples) you would typically just do not "return" a complex value: You would normally pass a reference to a variable in which you want to get the return value. The latter is not a problem with zsh either (and is also not hard in bash).
| Quote: |
- Accept function names with weird characters (αδσφγ for instance). And I like it.
|
I don't know how this is with the above languages, but I would not suggest to use such strange things, as it makes the code hard to read for others, not to speak about the coding question and corresponding problems if you distribute your scripts.
| Quote: | - My parameter file (or any variables file) can be stored in another bash file and a simple "source $filename" loads everything - no need to parse parameters
- Oh yeah, parameter files are human-readable and can be modified by hand if needed
|
Of course, an analogue of "source" is available in every language. However, I do not think that parsing parameter files in such a way is a good idea: A simple typo when changing this file can have unexpected side effects, not to speak about a malevolent user changing this file.
A very simple version of parsing can be written in all three of the above languages, probably in perl it is easiest. If you want very complex configuration files, you might even think about using perl6 (rakudo) since it has built-in grammar support. However, also in perl there are several parser modules available like Parse-Yapp
| Quote: | - Using external commands is just plain straightforward
- Few things are simpler than bash
- Wildcards, regular expressions, piping
- ${MYSTRING#$A} and its relatives
|
As already mentioned, the simplest handling of external commands and piping is done in zsh - this is the main purpose of a shell language. With zsh you will also avoid most of the traps of the classical bourne shell (unexpected expansions or unexpected wildcard replacement). perl and python do not have such problems from the very beginning.
Perl's (and even more perl6's) handling of regular expressions is unbeatable; things like ${MYSTRING#$A} are trivially handled with perl's regular expressions. However, also zsh has several more powerful extensions than bash in this respect. |
|
| Back to top |
|
|
Holysword
l33t
Joined: 19 Nov 2006
Posts: 683
Location: Greece
|
| Posted: Fri Apr 27, 2012 6:41 pm Post subject: |
|
|
I am longing for an oportunity to use lmgtfy for a long, long time...
| John R. Graham wrote: | | You can't go wrong learning Perl. Working through the complexities of Perl regular expressions will be a mind bending—er, expanding—exercise (if you don't know Perl's regular expressions, you don't know Perl) and Perl will be a useful tool in your capability toolbox. |
I will survive. I think that everything is pointing towards Perl.
| Ormaaj wrote: | | But before considering any of that, think about why you're not just using Python/Ruby/Perl (whichever you're most familiar with.) |
Because bash is easy, and because I don't know Python/Ruby/Perl YET. I am just deciding which one to learn.
Btw, I'm happy no one suggested Ruby. That's definetively interesting.
| Ormaaj and John R. Graham wrote: | | LOL! |
Is bash supposed to be hard? O.o"
As @i92guboj, I truly think it depends on what you're doing! I am mostly reading parameters and calling other programs (and loops, yeah, loops). Anything other than a shell language would overcomplicate a simple "if file is there, run command x"?
| mv wrote: | | Perl's (and even more perl6's) handling of regular expressions is unbeatable; things like ${MYSTRING#$A} are trivially handled with perl's regular expressions. However, also zsh has several more powerful extensions than bash in this respect. |
Now that you mentioned, are the major versions of Perl backward compatible or do I have to run a parser to update the code in case I decide to upgrade from 5 to 6?
_________________
i7-720QM | nVidia GT 230M | 4 GB DDR3
"Nolite arbitrari quia venerim mittere pacem in terram non veni pacem mittere sed gladium" (Yeshua Ha Mashiach) |
|
| Back to top |
|
|
Dr.Willy
Apprentice
Joined: 15 Jul 2007
Posts: 288
Location: NRW, Germany
|
| Posted: Fri Apr 27, 2012 6:44 pm Post subject: |
|
|
| Holysword wrote: | | Btw, I'm happy no one suggested Ruby. That's definetively interesting. |
…because Ruby is like Python. Except slower and uglier. 8D |
|
| Back to top |
|
|
Holysword
l33t
Joined: 19 Nov 2006
Posts: 683
Location: Greece
|
| Posted: Fri Apr 27, 2012 6:47 pm Post subject: |
|
|
Now that I've realised that I forgot to mention one thing about the "source" thing:
| mv wrote: | | Of course, an analogue of "source" is available in every language. |
Yeps, but is it always allowed to use an analogous of "source $MY_DIR/parameter_file_1" ? I use variables to store paths very often; sometimes I have a parameter file for each day of the week (seriously) and before sourcing, I have to determine which one. Some languages allow the "include" only at the beginning which would suck for me, or not allow variables names in the include statement at all. Well, I don't know many script languages though.
_________________
i7-720QM | nVidia GT 230M | 4 GB DDR3
"Nolite arbitrari quia venerim mittere pacem in terram non veni pacem mittere sed gladium" (Yeshua Ha Mashiach) |
|
| Back to top |
|
|
John R. Graham
Administrator
Joined: 08 Mar 2005
Posts: 6449
Location: Somewhere over Atlanta, Georgia
|
| Posted: Fri Apr 27, 2012 7:06 pm Post subject: |
|
|
| Holysword wrote: | | Is bash supposed to be hard? O.o" |
No, just abstruse. There are many, many unobvious corner cases in the syntax that will sometimes surprise you.
| Holysword wrote: | | Now that you mentioned, are the major versions of Perl backward compatible or do I have to run a parser to update the code in case I decide to upgrade from 5 to 6? |
The goal of Perl 6 is not to sacrifice a better language for backwards compatibility, so, no, backwards compatibility is not a strict goal. Perl 6 will definitely look Perl-ish, though. More to the point, Perl 6 is not really ready for prime time and is moving in that direction more slowly than Larry Wall originally predicted. It's in Portage, if you want to play (dev-lang/rakudo).
- John
_________________
This space intentionally left blank. |
|
| Back to top |
|
|
Holysword
l33t
Joined: 19 Nov 2006
Posts: 683
Location: Greece
|
| Posted: Fri Apr 27, 2012 7:20 pm Post subject: |
|
|
| John R. Graham wrote: | | Perl 6 is not really ready for prime time and is moving in that direction more slowly than Larry Wall originally predicted |
Does that mean "buggy" or "few libraries around"? (or both?)
_________________
i7-720QM | nVidia GT 230M | 4 GB DDR3
"Nolite arbitrari quia venerim mittere pacem in terram non veni pacem mittere sed gladium" (Yeshua Ha Mashiach) |
|
| Back to top |
|
|
John R. Graham
Administrator
Joined: 08 Mar 2005
Posts: 6449
Location: Somewhere over Atlanta, Georgia
|
| Posted: Fri Apr 27, 2012 7:35 pm Post subject: |
|
|
It means both of those and then some. See the Rakudo release notes for details.
- John
_________________
This space intentionally left blank. |
|
| Back to top |
|
|
Holysword
l33t
Joined: 19 Nov 2006
Posts: 683
Location: Greece
|
| Posted: Sat Apr 28, 2012 9:41 am Post subject: |
|
|
| John R. Graham wrote: | | It means both of those and then some. See the Rakudo release notes for details. |
That sounds like a challenge, and I like that (that's how I ended up in Gentoo; the first and only Linux distribution I've ever had).
However, I couldn't find decent tutorials. This one started nice, but all of the sudden... GERMAN!
This other one started relatively nice, and then the guy decided to only write codes and show the output without mention a word about it.
I will keep digging. I think its easier to learn by doing in any case. Perl sounds fun.
EDIT#1: I had declared Perl as the winner a couple of hours ago. That was before failing to find some of the information I need:
*Equivalent of "source $MY_DIR/$MY_BLABLALBA" in Perl6?
*Module for parsing parameters? (if it exists already. http://modules.perl6.org/ doesn't show any)
*Eyecandy: how to print in the terminal in colors? - [Yes: use Term::ANSIColor; thanks to IRC guys]
_________________
i7-720QM | nVidia GT 230M | 4 GB DDR3
"Nolite arbitrari quia venerim mittere pacem in terram non veni pacem mittere sed gladium" (Yeshua Ha Mashiach) |
|
| Back to top |
|
|
mv
Advocate
Joined: 20 Apr 2005
Posts: 3159
|
| Posted: Sat Apr 28, 2012 11:21 am Post subject: |
|
|
I have mainly only experience with perl5, but I liked the way grammars are possible in perl6, and I had thought that except for a few corner cases, the syntax is backward compatible. Moreover, the feature matrix suggests that rakudo is practically complete. However, I have never really worked with perl6 except for a few experiments.
To find the analogue of "source" in perl5, execute | Code: | perldoc -f do
perldoc -f require |
(depending on how you want to handle the path search; to avoid the problem of "too early" parsing you mentioned before you might want to execute "require" later, e.g. with "eval").
I would have expected that it is the same for perl6, but I don't know.
A good modules for parsing in perl5 (which provides also support for a reasonable powerful grammer) is "dev-perl/Parse-RecDescent". Of course, you would not need this in perl6. |
|
| Back to top |
|
|
Ant P.
Veteran
Joined: 18 Apr 2009
Posts: 1923
Location: UK
|
|
| Back to top |
|
|
John R. Graham
Administrator
Joined: 08 Mar 2005
Posts: 6449
Location: Somewhere over Atlanta, Georgia
|
| Posted: Sat Apr 28, 2012 10:40 pm Post subject: |
|
|
Well, no. He's talking about parsing parameter / config files, not command line parameters.
- John
_________________
This space intentionally left blank. |
|
| Back to top |
|
|
Ant P.
Veteran
Joined: 18 Apr 2009
Posts: 1923
Location: UK
|
| Posted: Sun Apr 29, 2012 12:47 am Post subject: |
|
|
| My bad, I thought he meant those since the modules list has YAML, JSON and INI format parsers... |
|
| Back to top |
|
|
Holysword
l33t
Joined: 19 Nov 2006
Posts: 683
Location: Greece
|
| Posted: Sun Apr 29, 2012 1:53 pm Post subject: |
|
|
| Ant P. wrote: | | My bad, I thought he meant those since the modules list has YAML, JSON and INI format parsers... |
Oh you're right, there are parameters file parser modules. Great =D
_________________
i7-720QM | nVidia GT 230M | 4 GB DDR3
"Nolite arbitrari quia venerim mittere pacem in terram non veni pacem mittere sed gladium" (Yeshua Ha Mashiach) |
|
| Back to top |
|
|
John R. Graham
Administrator
Joined: 08 Mar 2005
Posts: 6449
Location: Somewhere over Atlanta, Georgia
|
| Posted: Sun Apr 29, 2012 2:08 pm Post subject: |
|
|
I'll just make one more plug for Perl 5 and then be quiet. If you're interest is mostly academic, then, by all means, pursue your passion. However, if there's any chance that your work will need to be widely deployed, then programming it in Perl 6 will make your life harder. Virtually every distribution on the planet has a late model Perl 5 installed by default. Requiring Perl 6 today is almost like requiring Erlang or Haskell: you're just not going to find it waiting for you when you get there.
- John
_________________
This space intentionally left blank. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
