Shell Programming and Scripting

Very good idea. Since the following works not only with integers but also with arbitrary sets of characters we don't even need a recursion:

Code:

perm ()
{
myset="$1"
n="$2"
buf=""
i=1

while (( i <= n )) ; do
     buf="${buf}${myset}"
     (( i++ ))
done

for x in $buf ; do echo $x ; done

return 0
}

# example calls:
perm "{1,2}" 3

perm "{a,b}" 2

bakunin

/PS: on second thoughts: this is not the permutations but the combinations of the given set, no?

Can this be any simpler?
Single statement, longhand, OSX 10.14.1, default bash shell...

Code:

Last login: Wed Jan  9 23:14:09 on ttys000
AMIGA:amiga~> echo $'\n'{a..e}$' '{a..e}$' '{a..e}

a a a 
a a b 
a a c 
a a d 
a a e 
a b a 
a b b 
a b c 
. . . 
e d d 
e d e 
e e a 
e e b 
e e c 
e e d 
e e e
AMIGA:amiga~> _

Hi wisecracker and cjnwl,
Note that if you change:

Code:

echo $'\n'{a..e}$' '{a..e}$' '{a..e}

to:

Code:

printf '%s\n' {a..e}' '{a..e}' '{a..e}

you get rid of the (probably undesired) initial empty line in the output. And to create the desired array of combinations using either a recent bash or ksh93, one could then use:

Code:

OIFS="$IFS"
IFS=$'\n'
array=( $(printf '%s\n' {a..e}' '{a..e}' '{a..e}) )  
IFS="${OIFS}"

And, to verify that it worked, one could then run:

Code:

echo "${#array[@]} '${array[0]}' ... '${array[124]}'"

producing the output:

Code:

125 'a a a' ... 'e e e'

which shows that it is likely that the array named array contains the desired 125 elements.

It's really very short!

Code:

eval echo "$'\n'{$var1..$var2}$' '{$var1..$var2}"

What I'm writing now is important for programs with a lot more code, but I think it has benefits in small (awk) programs in this forum too.

Descriptive code

For me - and probably for others like the partly beginner level thread starters more alike - non-descriptive variable names makes it harder to read the code. I see this here in this forum a lot. I assume brevity of code is some kind of goal involved here.

Writing Code that is easily understandable with little effort is far more important to me. And of course readabilty / maintainibility on one side and efficient, clean and short code on the other side are both important and for both must be found a suitable balance. In real life, other people read my code to, or I myself after a long time again and I'd like to avoid that experience I had in the past: "Oh crap! What did I smoke when I wrote that code?"

As an awk example(Scrutinizers variant above is written much better than the first one): split(a,b,c) vs split(text,result,pattern)

This helps me even if I do not know the syntax of split, so I do not have to check the documentation for split() right away.

So I would like it to have code, I can easily understand. I like a solution more, which I may find in this forum even years after it was posted and I quickly can understand it.

Global Variables

(actually i decided to use introduces a new global variable in my fix) I think it's good design, to avoid global variables whenever possible(See http://wiki.c2.com/?GlobalVariablesAreBad). For this forum, a solution that does this without globals avoids copy-and-paste problems: "Huu, I take this function, and put it into my code, and I like it, if it just works." and bamm! Variable collision and it crashes or just does not work. Maybe this(not-working-code with side-effects) is a nice to have too in terms of: Make sure you really understand your code, before trying to run it! Do not just copy it! ...but for I appreciate the other way.

Thanks Guys, that's exactly what I was looking for

--- Post updated at 12:27 PM ---

Note that the various shell scripts don't reply to the question, which was first of all for awk (as this is part of a much larger script that I've been given to modify), but more importantly, hard-coded the number of elements.

First of all, i am glad your problem was solved. There are still some points you might want to consider:

ahem - no! You said (#1):
Just because you tried we do not have to try the same - after all, you didn't (at that time) have success with what you tried. We often have questions like how can i do X with tool Y where Y is something we positively know to be not suited at all for achieving X. (You wouldn't believe how often i have been asked something analogous to "please explain how i can solder this to that using a refrigerator and the collected works of Shakespeare".) Now, i admit this is not the case with your question but if you need the solution to be in awk, then please say so.

Like this, which is a valid reason to stick with awk. But since you didn't tell us you can hardly blame us for not knowing this, no?

Two things: first, yes, in some cases, but these were merely meant as demonstrations for using a certain method - in this case a certain little-known form of parameter expansion - and it was obvious how to adapt that for an set and any number of elements in the combination set. Addition is like 1 + 1 = 2 doesn't insinuate that i think "2 + 2" to work any different and of course i could say: addition is a commutative and associative operation on either sets of scalar elements or vector spaces .... Somehow, i noticed, though, that many people prefer the first over the second.

Second: in case of my function (#15) this isn't even true, because you can use any set and any number of elements from the set to build combinations. For instance this invocation:

Code:

perm ()
{
myset="$1"
n="$2"
buf=""
i=1

while (( i <= n )) ; do
     buf="${buf}${myset}"
     (( i++ ))
done

for x in $buf ; do echo $x ; done

return 0
}

perm "{1,a,2,b}" 5

will give you 1024 lines from "1111" to "bbbb". You could even call the function (i tried only in ksh93 but suppose it to work in bash too) with arbitrary strings like this:

Code:

# perm "{"ab","XY"}" 3
ababab
ababXY
abXYab
abXYXY
XYabab
XYabXY
XYXYab
XYXYXY

You definitely have a point there. As i am about to post a larger software project for the community within the next days i suggest we should have a discussion about coding standards in general. Perhaps we could all profit somewhat from such a discussion and by seeing what others do and why.

bakunin