While @cjfp's answer with multiple case statements would be my preferred approach to actually doing fallthrough, I usually avoid the issue entirely.
The benefits of this are not obvious for trivial examples, but when each case becomes complex, fallthrough becomes a nightmare to follow.
The solution is to simplify the case statement with functions.
Approach #1
#!/bin/bash
quick() {
echo "QUICK"
}
brown() {
echo "BROWN"
}
fox() {
echo "FOX"
}
jumped() {
echo "JUMPED"
}
qbf() {
case "$1" in
1)
quick
;;
2)
quick; brown
;;
3)
quick; brown; fox
;;
4)
quick; brown; fox; jumped
;;
esac
}
qbf "$1"
Of course, for large numbers of cases, this can get out of hand. But it need not grow linearly.
Let's add "over the lazy dog". I'll omit the echo-functions; you get the idea.
Approach #2
# Continuing from above
lazydog() {
case "$1" in
5)
qbf "$1"; over
;;
6)
qbf "$1"; over; the
;;
7)
qgf "$1"; over; the; lazy
;;
8)
qbf "$1"; over; the; lazy; dog
;;
esac
}
But this gets out of hand, too. But really long case statements are already problematic. We'd like to avoid adding any redundancy at all.
So here's how we can do that! (Reverting to the original example for brevity).
Approach #3
#!/bin/sh
foxy() {
case "$1" in
1)
echo "QUICK"
;;
2)
foxy 1; echo "BROWN"
;;
3)
foxy 2; echo "FOX
;;
4)
foxy 3; echo "JUMPED"
;;
esac
}
foxy "$1"
What goes on here is that fallthrough is replaced with invoking the prior case recursively before the current one.
I normally use approach #1 for simple cases. (I probably use @cjfp's approach at times without even thinking about it in very simple cases).
If I get to the level I'd want approach #2, I'd just skip ahead to the more general approach #3. #2 is introduced as a stepping-stone to recursion.
But really, if I get to #3, I'm considering writing it in something other than bash. But sometimes bash is a constraint, thanks to its incredible ubiquity.
But I try to avoid fallthrough even in languages that support it.
It's a lot more clear to think of each case separately, with the option to include the prior case. It's a lot more powerful, as well. You can have all later cases include case 1 without including cases 2...n-1.
Between breaking out the cases as functions that can be invoked independently, and recursive invocation, each case can be composed freely from a palette of independent functions and/or complete sub-cases.
switch only looks attractive for very simple situations, with a very linear structure.
Between the options I present here, along with @cjfp's approach with multiple case statements, or a state-machine approach such as in @Meki's answer, the lack of a case statement is not much of a burden.
The risks of accidental fallthrough outweigh the benefits; thus language designers tend to shy away from including switch, despite its familiarity due to certain widely-used languages. It's not been a part of any language I've had a part in designing. I can't take credit; it was widely recognized even before my time, and I'm retired now.
I hope that my answer, along with the others here, give you a different way of thinking about the problem. I'd avoid the ';&' feature. Even aside from compatibility problems you are giving up the semantic safety offered by vanilla 'case'.
