In bash I have used a construct like the following to pick from a
number of cases at random. How would I do the same thing in ksh?

```bash

case $(($RANDOM%3)) in

0) echo "case 1" ;;

1) echo "case 2" ;;

2) echo "case 3" ;;

esac

```

thanks,

lkh

--
Laurens Kils-Hütten
https://sdf-eu.org/~lkh

On 06.08.2022 19:09, Laurens Kils-Hütten wrote:
> In bash I have used a construct like the following to pick from a
> number of cases at random. How would I do the same thing in ksh?

The case construct is standard and works in all POSIX shells
as it is. In ksh, therefore, you can write it the same way.
The only thing you probably cannot rely on in POSIX shells is
the RANDOM variable (which ksh of course supports).

For readability I prefer the [non-standard] $(( RANDOM % 3 ))
and I also write the tags (as the standard allows) in symmetric
parentheses like: (2) echo ... ;;

Janis

>
> ```bash
>
> case $(($RANDOM%3)) in
>
> 0) echo "case 1" ;;
>
> 1) echo "case 2" ;;
>
> 2) echo "case 3" ;;
>
> esac
>
> ```
>
> thanks,
>
> lkh
>

Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
> The only thing you probably cannot rely on in POSIX shells is
> the RANDOM variable (which ksh of course supports).

Yes, that was precisely the problem. Also, I learned that /bin/sh and
/bin/ksh are not the same on netbsd ;-)

In /bin/sh this works:

#/bin/sh

case $(( $$ %3)) in

0) echo "case 1" ;;

1) echo "case 2" ;;

2) echo "case 3" ;;

esac

--
Have this adventurer for your next game:
Rosalie is a farmer
STR 14 INT 10 WIS 9 DEX 9 CON 10 CHA 11
HP 5 90 gp

On 08.08.2022 08:30, Laurens Kils-Hütten wrote:
> Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
>> The only thing you probably cannot rely on in POSIX shells is
>> the RANDOM variable (which ksh of course supports).
>
> Yes, that was precisely the problem. Also, I learned that /bin/sh and
> /bin/ksh are not the same on netbsd ;-)

But ksh is a (extreme) superset of sh, so you shouldn't have issues
as long as you program in POSIX or if you define ksh (or bash, etc.)
in the first place, if you want to use some of the modern features.

On legacy systems /bin/sh might be old bourne shell, but typically
you have a POSIX shell defined as /bin/sh nowadays. Other shells
may lie behind the somewhat generic "sh"; shells like ksh or bash
can often be found, but also other shells that (basically) conform
to POSIX. It is quite safe to assume any POSIX shell behind /bin/sh.

>
> In /bin/sh this works:

I don't see why that shouldn't work in other POSIX shells as well;
try it with ksh, bash, zsh, etc.

Unless you want to write widely portable (POSIX) scripts use the one
that serves best or that is available in your system environments.
And the powerful modern shells (ksh, bash, zsh) support a common base
of extended features; feel free to use them if you are not restricted
by other rules or requirements.

Janis

>
> #/bin/sh
>
> case $(( $$ %3)) in
>
> 0) echo "case 1" ;;
>
> 1) echo "case 2" ;;
>
> 2) echo "case 3" ;;
>
> esac
>

Laurens Kils-Hütten wrote:

> In /bin/sh this works:
>
> #/bin/sh
>
> case $(( $$ %3)) in
>
> 0) echo "case 1" ;;
>
> 1) echo "case 2" ;;
>
> 2) echo "case 3" ;;
>
> esac

In your original post you said you wanted to choose "at random".
Using $(($$%3)) is very much not random:

$ for i in {1..10}; do sh -c 'echo $(($$%3))'; done
1 2
0 1
2 0
1 2
0 1

(on almost all systems -- I believe there are some that randomise
PID allocation).

--
Geoff Clare <netnews@gclare.org.uk>

In article <5vd7si-gep.ln1@ID-313840.user.individual.net>,
Geoff Clare <netnews@gclare.org.uk> wrote:
....
>In your original post you said you wanted to choose "at random".
>Using $(($$%3)) is very much not random:

Leaving aside the philosophical question of whether any number generated by
software is truly random (i.e., anything short of attaching a Geiger
counter to your PC), using $$ as a sort-of-random-number in a shell script
is a fairly common, although flawed, practice.

Modern shells (e.g., bash) have RANDOM as a way of getting actual (subject,
of course, to the caveats mentioned above) random number in a shell script.
I don't know what other shells have RANDOM.

Anyway, I found the original thread topic confusing, so I changed it.

--
I'm building a wall.

On 08.08.2022 12:34, Janis Papanagnou wrote:
> On 08.08.2022 08:30, Laurens Kils-Hütten wrote:
>> Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
>>> The only thing you probably cannot rely on in POSIX shells is
>>> the RANDOM variable (which ksh of course supports).
>>
>> [...]
>>
>> In /bin/sh this works:
>
> I don't see why that shouldn't work in other POSIX shells as well;
> try it with ksh, bash, zsh, etc.
>
> Unless you want to write widely portable (POSIX) scripts use the one
> that serves best or that is available in your system environments.
> And the powerful modern shells (ksh, bash, zsh) support a common base
> of extended features; feel free to use them if you are not restricted
> by other rules or requirements.
>
> Janis
>
>>
>> #/bin/sh
>>
>> case $(( $$ %3)) in

I spoke about availability of RANDOM in modern powerful shells
(like ksh, bash, zsh) as opposed to the POSIX standard. Others
pointed out already about the non-randomness of $$.

In case you cannot or don't want to use one of these shells,
which are the simplest access to some randomness, there's also
the Unix operating system that _may_ support random data; check
whether you have /dev/urandom available to get random data.

Janis

On 2022-08-08, Kenny McCormack <gazelle@shell.xmission.com> wrote:

> Modern shells (e.g., bash) have RANDOM as a way of getting actual (subject,
> of course, to the caveats mentioned above) random number in a shell script.
> I don't know what other shells have RANDOM.

Well, it's a ksh88 feature.

--
Christian "naddy" Weisgerber naddy@mips.inka.de

Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
> On 08.08.2022 12:34, Janis Papanagnou wrote:
>> On 08.08.2022 08:30, Laurens Kils-Hütten wrote:
>>> Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
>>>> The only thing you probably cannot rely on in POSIX shells is
>>>> the RANDOM variable (which ksh of course supports).
>>>
>>> [...]
>>>
>>> In /bin/sh this works:
>>
>> I don't see why that shouldn't work in other POSIX shells as well;
>> try it with ksh, bash, zsh, etc.

$$ seems to be the only construct supported by netbsd's /bin/sh, so that's
what I'll use. Pseudo-randomness is enough for my use case.

>> Unless you want to write widely portable (POSIX) scripts use the one
>> that serves best or that is available in your system environments.

Exactly, the point is portability (and also to learn about the different
shells).

Thanks!

lkh

Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <5vd7si-gep.ln1@ID-313840.user.individual.net>,
> Geoff Clare <netnews@gclare.org.uk> wrote:
> ...
>>In your original post you said you wanted to choose "at random".
>>Using $(($$%3)) is very much not random:
>
> Leaving aside the philosophical question of whether any number generated by
> software is truly random (i.e., anything short of attaching a Geiger
> counter to your PC), using $$ as a sort-of-random-number in a shell script
> is a fairly common, although flawed, practice.
>
> Modern shells (e.g., bash) have RANDOM as a way of getting actual (subject,
> of course, to the caveats mentioned above) random number in a shell script.
> I don't know what other shells have RANDOM.

I see, turns out that netbsd's /bin/sh doesn't support RANDOM, yet. So $$
seems to be the only portable option. Sort-of-randomness is enough for
my use case.

>
> Anyway, I found the original thread topic confusing, so I changed it.
it reflected my state of mind, I guess ;D

--
Have this adventurer for your next game:
Peter dreams of riding a dragon ?
STR 12 INT 8 WIS 10 DEX 6 CON 11 CHA 11
HP 3 110 gp

In article <tcrj30$1clb$1@gioia.aioe.org>,
Laurens Kils-Htten <lkh@sdf-eu.org> wrote:
>Kenny McCormack <gazelle@shell.xmission.com> wrote:
>> In article <5vd7si-gep.ln1@ID-313840.user.individual.net>,
>> Geoff Clare <netnews@gclare.org.uk> wrote:
>> ...
>>>In your original post you said you wanted to choose "at random".
>>>Using $(($$%3)) is very much not random:
>>
>> Leaving aside the philosophical question of whether any number generated by
>> software is truly random (i.e., anything short of attaching a Geiger
>> counter to your PC), using $$ as a sort-of-random-number in a shell script
>> is a fairly common, although flawed, practice.
>>
>> Modern shells (e.g., bash) have RANDOM as a way of getting actual (subject,
>> of course, to the caveats mentioned above) random number in a shell script.
>> I don't know what other shells have RANDOM.
>
>I see, turns out that netbsd's /bin/sh doesn't support RANDOM, yet.

Nor does "dash" on Debian systems.
Interestingly enough, busybox's sh does have RANDOM.

>So $$ seems to be the only portable option. Sort-of-randomness is enough
>for my use case.

I suppose if portabilty is the main concern, then using something like
/dev/urandom would be right out...

>> Anyway, I found the original thread topic confusing, so I changed it.
>
>it reflected my state of mind, I guess ;D

Quite so.

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/TedCruz

Op 06-08-22 om 19:13 schreef Janis Papanagnou:
> For readability I prefer the [non-standard] $(( RANDOM % 3 ))

FYI, referring to variables without a leading $ in arithmetic
expressions is perfectly standard:

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_04
| If the shell variable x contains a value that forms a valid integer
| constant, optionally including a leading <plus-sign> or <hyphen-
| minus>, then the arithmetic expansions "$((x))" and "$(($x))" shall
| return the same value.

--
|| modernish -- harness the shell
|| https://github.com/modernish/modernish
||
|| KornShell lives!
|| https://github.com/ksh93/ksh

On 09.08.2022 11:32, Martijn Dekker wrote:
> Op 06-08-22 om 19:13 schreef Janis Papanagnou:
>> For readability I prefer the [non-standard] $(( RANDOM % 3 ))
>
> FYI, referring to variables without a leading $ in arithmetic
> expressions is perfectly standard:
>
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_04
>
> | If the shell variable x contains a value that forms a valid integer
> | constant, optionally including a leading <plus-sign> or <hyphen-
> | minus>, then the arithmetic expansions "$((x))" and "$(($x))" shall
> | return the same value.

Oh, thanks! - Has that changed? (I seem to recall that last time I
looked at that issue it didn't support $-less variables in arithmetic
expressions.) - Anyway, good to know.

Janis

Laurens Kils-Hütten wrote:

> I see, turns out that netbsd's /bin/sh doesn't support RANDOM, yet. So $$
> seems to be the only portable option. Sort-of-randomness is enough for
> my use case.

If you don't need a pure shell solution, you can do better by using
the rand() function in awk. If you seed it with $$, it will produce a
much more random looking sequence than $$ alone.

Something like:

case $(awk "BEGIN { srand($$); print int(3*rand()); }" /dev/null) in
....
esac

--
Geoff Clare <netnews@gclare.org.uk>

Janis Papanagnou wrote:

> On 09.08.2022 11:32, Martijn Dekker wrote:
>>
>> FYI, referring to variables without a leading $ in arithmetic
>> expressions is perfectly standard:
>>
>> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_04
>>
>> | If the shell variable x contains a value that forms a valid integer
>> | constant, optionally including a leading <plus-sign> or <hyphen-
>> | minus>, then the arithmetic expansions "$((x))" and "$(($x))" shall
>> | return the same value.
>
> Oh, thanks! - Has that changed? (I seem to recall that last time I
> looked at that issue it didn't support $-less variables in arithmetic
> expressions.) - Anyway, good to know.

It was a common misconception in the early days, and the standard was
changed to clarify it at some point. However, _assigning_ to variables
was always clearly required to be supported, and the value of an
assignment operation is the new value of the assigned variable, so
it made no sense to interpret the standard as requiring:

echo $((x=42))

to output 42, but not requiring:

x=42; echo $((x))

to output 42.

--
Geoff Clare <netnews@gclare.org.uk>

Janis Papanagnou <janis_papanagnou@hotmail.com>:
>On 09.08.2022 11:32, Martijn Dekker wrote:
>> Op 06-08-22 om 19:13 schreef Janis Papanagnou:
>>> For readability I prefer the [non-standard] $(( RANDOM % 3 ))
>>
>> FYI, referring to variables without a leading $ in arithmetic
>> expressions is perfectly standard:
>>
>> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_04
>>
>> | If the shell variable x contains a value that forms a valid integer
>> | constant, optionally including a leading <plus-sign> or <hyphen-
>> | minus>, then the arithmetic expansions "$((x))" and "$(($x))" shall
>> | return the same value.
>
>Oh, thanks! - Has that changed? (I seem to recall that last time I
>looked at that issue it didn't support $-less variables in arithmetic
>expressions.) - Anyway, good to know.

There might be a difference, though, if the value of the variable is
not a literal integer, but a string resembling an integer
expression.  Try, using different shells, the following commands:

v='6*7'
printf '%s\n' "$((v))"
printf '%s\n' "$((${v}))"

On 09.08.2022 19:09, Helmut Waitzmann wrote:
> Janis Papanagnou <janis_papanagnou@hotmail.com>:
>> On 09.08.2022 11:32, Martijn Dekker wrote:
>>> Op 06-08-22 om 19:13 schreef Janis Papanagnou:
>>>> For readability I prefer the [non-standard] $(( RANDOM % 3 ))
>>>
>>> FYI, referring to variables without a leading $ in arithmetic
>>> expressions is perfectly standard:
>>>
>>> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_04
>>>
>>>
>>> | If the shell variable x contains a value that forms a valid integer
>>> | constant, optionally including a leading <plus-sign> or <hyphen-
>>> | minus>, then the arithmetic expansions "$((x))" and "$(($x))" shall
>>> | return the same value.
>>
>> Oh, thanks! - Has that changed? (I seem to recall that last time I
>> looked at that issue it didn't support $-less variables in arithmetic
>> expressions.) - Anyway, good to know.
>
> There might be a difference, though, if the value of the variable is not
> a literal integer, but a string resembling an integer expression. Try,
> using different shells, the following commands:
>
> v='6*7'
> printf '%s\n' "$((v))"
> printf '%s\n' "$((${v}))"

I anyway wouldn't have expected that formulas in string variables
would have been handled (like ksh/bash/zsh do) in the first place.

A probably more interesting case (where these three shells differ)
is
printf '%s\n' $(("${v}"))

Janis

Janis Papanagnou <janis_papanagnou@hotmail.com>:
>On 09.08.2022 19:09, Helmut Waitzmann wrote:
>> v='6*7'
>> printf '%s\n' "$((v))"
>> printf '%s\n' "$((${v}))"
>
>I anyway wouldn't have expected that formulas in string variables
>would have been handled (like ksh/bash/zsh do) in the first place.
>
>A probably more interesting case (where these three shells differ)
>is
> printf '%s\n' $(("${v}"))

POSIX
(<https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_04>)
says:

$((expression))

The expression shall be treated as if it were in
double-quotes, except that a double-quote inside the
expression is not treated specially. The shell shall
expand all tokens in the expression for parameter
expansion, command substitution, and quote removal.

Does "a double-quote inside the expression is not treated specially"
say that double-quotes are treated literally, i.e. excluded from
quote removal, thus left as (a syntactic invalid) part of the
arithmetic expression?

On 10.08.2022 16:46, Helmut Waitzmann wrote:
> Janis Papanagnou <janis_papanagnou@hotmail.com>:
>> On 09.08.2022 19:09, Helmut Waitzmann wrote:
>>> v='6*7'
>>> printf '%s\n' "$((v))"
>>> printf '%s\n' "$((${v}))"
>>
>> I anyway wouldn't have expected that formulas in string variables
>> would have been handled (like ksh/bash/zsh do) in the first place.
>>
>> A probably more interesting case (where these three shells differ) is
>> printf '%s\n' $(("${v}"))
>
> POSIX
> (<https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_04>)
> says:
>
> $((expression))
>
> The expression shall be treated as if it were in
> double-quotes, except that a double-quote inside the
> expression is not treated specially. The shell shall
> expand all tokens in the expression for parameter
> expansion, command substitution, and quote removal.
>
> Does "a double-quote inside the expression is not treated specially" say
> that double-quotes are treated literally, i.e. excluded from quote
> removal, thus left as (a syntactic invalid) part of the arithmetic
> expression?

My interpretation would be that it's effectively just ignored because
the expression is anyway treated like being double-quoted. It would,
IMO, also make no sense to assume differently. Throw an error for a
quoted $-expression?!

But shells behave differently, so maybe it's not that clear...

$ ksh -c 'v="6*7" ; printf "%s\n" "$((v))" ; printf "%s\n" $(("${v}"))'
42
42

$ zsh -c 'v="6*7" ; printf "%s\n" "$((v))" ; printf "%s\n" $(("${v}"))'
42
zsh:1: bad math expression: illegal character: "

$ bash -c 'v="6*7" ; printf "%s\n" "$((v))" ; printf "%s\n" $(("${v}"))'
42
bash: "6*7": syntax error: operand expected (error token is ""6*7"")

At least bash and zsh seem to interpret it the way you suspected. (And
as so often, I'm happy to use ksh here which serves my interpretation.)

And dash complains completely...

$ dash -c 'v="6*7" ; printf "%s\n" "$((v))" ; printf "%s\n" $(("${v}"))'
dash: 1: Illegal number: 6*7

Janis