Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.unix.shell > #26914

Re: Variable var names

From Janis Papanagnou <janis_papanagnou+ng@hotmail.com>
Newsgroups comp.unix.shell
Subject Re: Variable var names
Date 2026-06-12 17:54 +0200
Organization A noiseless patient Spider
Message-ID <110ha39$2097v$2@dont-email.me> (permalink)
References <n91qs8Fk65fU1@mid.individual.net> <110h9bv$2097u$1@dont-email.me>

Show all headers | View raw


On 2026-06-12 17:41, Janis Papanagnou wrote:
> On 2026-06-12 09:30, Frank Winkler wrote:
>> Hi there !
> 
> You've already got a couple useful hints and explanations. So just
> some additional hints...
> 
> Below, consider using arrays instead of manipulating variable names.
> (Thereby you avoid the 'eval' that you've already been suggested to
> avoid in the first place, if not really necessary.)
> 
>    x=( "" "  ok  " "  not ok  " )
>    echo ${x[1]}
>    echo ${x[2]}

And of course I forgot to mention (and also consider above) the most
basic rule; quote your variables. Above should of course have been

     echo "${x[1]}"
     echo "${x[2]}"

(and 'echo' also replaced by 'printf', of course).  :-)

> 
> Standard arrays are counted from 0 so the first array element has
> a dummy element above. (Modern shells also support associative
> arrays, in case you want more flexibility.)
> 
> If you want for (some reason) to use 'eval' note that you can, as
> suggested, use two layers of quotes (one escaped), or just use two
> different nested quotes ( " and ' ), but also note the effects of
> expansions inside the double-quotes; you can take that for your
> advantage (if you know the expansion rules).
> 
> The effect of IFS changes on _internal_ shell commands like 'eval'
> have been explained already, and that this is standard behavior.
> Note that you don't need to save/restore the IFS in standard code;
> you can also embed it in a subshell-environment with parenthesis
> to keep the IFS change local within the parenthesis, as in
> 
>    ( IFS="" eval echo ".\$x$n." )
> 
> In ksh you won't create a real subshell that way if there's only
> shell built-ins like 'eval' and 'echo' used, so it's efficient.
> 
> If you intend to use mainly "modern" shells like bash, ksh, zsh,
> you should consider using (instead of [ ... ]) [[ ... ]], or in
> case of arithmetic (as in your code below) the shell's arithmetic
> statement
> 
>    (( n == 1 )) && ..
> 
> For many values you may also use 'case',
> 
>    case $n in
>    (1) ... ;;
>    (2) ... ;;
>    (*) ... ;;  # default branch for errors
>    esac
> 
> And of course use 'printf' (instead of 'echo').
> 
> Janis
> 
>>
>> I'm playing with the following in an interactive bash as well as in a 
>> ksh script:
>>
>> $ n=1
>> $ x1="  ok  "
>> $ x2="  not ok  "
>> $ eval echo \$x$n
>> ok
>> $ eval echo "\$x$n"
>> ok
>> $ n=2
>> $ eval echo "\$x$n"
>> not ok
>> $
>>
>> So the variable var name seems to work but why are the blanks 
>> "deleted" here? I also tried some variants with "printf", but also 
>> with no success.
>>
>> Just out of curiosity, I tried this:
>>
>> $ IFS="" eval echo ".\$x$n."
>> .  not ok  .
>> $
>>
>> To my surprise, it works but why is IFS relevant here? And to my even 
>> bigger surprise, it looks like everything seems to behave as expected 
>> in the bash session but in the ksh script, IFS is not just changed for 
>> this single command but globally - so I had to save and restore it to 
>> prevent the whole script from exploding. This makes the interesting 
>> part much longer and more complicated, eating up the potential 
>> advantage and coolness superiority over just doing something like
>>
>>    [ $n -eq 1 ] && echo "$x1"
>>    [ $n -eq 2 ] && echo "$x2"
>>
>> Any hints from the experts?
>>
>> TIA
>>
>>      Frank
>>
> 

Back to comp.unix.shell | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Variable var names Frank Winkler <usenet@f.winkler-ka.de> - 2026-06-12 09:30 +0200
  Re: Variable var names gazelle@shell.xmission.com (Kenny McCormack) - 2026-06-12 09:02 +0000
    Re: Variable var names Frank Winkler <usenet@f.winkler-ka.de> - 2026-06-13 12:29 +0200
      Re: Variable var names gazelle@shell.xmission.com (Kenny McCormack) - 2026-06-13 11:14 +0000
      Re: Variable var names Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-13 13:15 +0200
  Re: Variable var names ram@zedat.fu-berlin.de (Stefan Ram) - 2026-06-12 11:26 +0000
    Re: Variable var names ram@zedat.fu-berlin.de (Stefan Ram) - 2026-06-12 11:38 +0000
      Re: Variable var names Frank Winkler <usenet@f.winkler-ka.de> - 2026-06-12 14:07 +0200
        Re: Variable var names ram@zedat.fu-berlin.de (Stefan Ram) - 2026-06-12 12:31 +0000
          Re: Variable var names Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-13 02:48 +0000
  Re: Variable var names Christian Weisgerber <naddy@mips.inka.de> - 2026-06-12 12:12 +0000
    Re: Variable var names Frank Winkler <usenet@f.winkler-ka.de> - 2026-06-12 15:19 +0200
    Re: Variable var names Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-13 02:51 +0000
  Re: Variable var names Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2026-06-12 13:42 +0100
  Re: Variable var names Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-12 17:41 +0200
    Re: Variable var names Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-12 17:54 +0200
    Re: Variable var names Frank Winkler <usenet@f.winkler-ka.de> - 2026-06-13 12:32 +0200
      Re: Variable var names Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-14 01:12 +0000
  Re: Variable var names Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-13 00:20 +0000
  Re: Variable var names Kaz Kylheku <046-301-5902@kylheku.com> - 2026-06-23 21:25 +0000
    Re: Variable var names Helmut Waitzmann <nn.throttle@erine.email> - 2026-06-24 10:45 +0200
    Re: Variable var names Christian Weisgerber <naddy@mips.inka.de> - 2026-06-24 11:41 +0000

csiph-web