Re: Syntax Question...

[Linda Walsh]

Greg Wooledge wrote:
[[[ yeah, am running a bit behind....]...


>  On Mon, Aug 15, 2011 at 12:45:58AM -0700, Linda Walsh wrote:
> > #!/bin/bash -exu
> > +[shopt -s expand_aliases extglob]
> >
> > alias sub=function
> > alias unless='if !'
>
>  Aliases don't even *work* in scripts.
----
   Hopefully you someone has updated you on  meaning of the line
immediately preceding those definitions, and that leaving out that
line would make your statement appear to be, or effectively, 'true'.
I.e. the text that was left out that  immediately preceded those
lines contains the explanation to why your statement is incorrect. 

The "shopt -s expand_aliases" feature has been in bash since I first
encountered it in ~1999.  I noticed it had all the features I needed
(had been used to ksh) & more, so I stuck w/it.   AFAIK, the ability to use
aliases in scripts has been around in bash for at least 12-13 years.

       You have to consider, if you found someone who wanted to give you
advice about programming in shell, but they knew nothing about, say,
'eval', how much weight would you give their opinion?  It certainly
doesn't mean the person may not have not have the material that they
*DO* know,  better memorized and have great expertise with the different
ways to do things in that subset.  But you would have to contextualize
what they say, and their opinions, as coming from their apparent
knowledge base.

   Similarly, if someone advised not to use eval in scripts -- just wasn't
a good idea ... you wouldn't expect them to be an expert in how to use it.

> > typeset -xr sub unless
> >
> > declare -a SAVE_ARGS=( "$@" )
> > typeset -xr snapdir='snapdir'
> >
> > # in shell: white is black and black is white:
> > export b_false=1
> > export b_true=0
> > export Debug=$b_false  Verbose=$b_true  Silent=$b_false
> > export Quiet=$b_false  Force=""  loglevel=7
>
>  Whatever your purpose is here, you're doing things in a very unclear
>  way.

You may be mollified to know that those particular exports are changed,
with many deleted:

   typeset -ix b_false=1
   typeset -ix b_true=0
   declare -lx Force=""
   typeset -ix loglevel=7

Most of them were in transition to be 'retired' and replaced (i.e.
got rid of Debug/Verbose/Quiet/Silent and replaced them with just
a 'loglevel' design as used in syslog.

>  Also, don't export variables without a reason.  Internal variables like
>  "b_false" do not need to appear in the environment of child processes.
---

       They do if the child processes use them.  It may be the case that
they won't need to be exported in the final code, since all of the
sub-shell functions that were called as separate shell scripts have
pretty much been rolled into library code that is sourced, instead, but
initially, I had different scripts to do various 'parts' of the job I
wanted to do, so I exported commonly used variables to allow reuse in
externally called sub-functions.   It is true that, usually, something
like true/false would be something included as a 'basic' many scripts
(if used symbolically, at all), but I was leaning more toward a
conservative support framework, that would make few assumptions about
what the subscripts might need, so even thought about putting an export
-f on every function definition.  I think it's on 1 and probably doesn't
need to be there -- but those are the lines I was thinking of...

       Many design quirks come from code being written in one context 
(like
inline), vs.  assuming it is a function that can change the parent's
env, vs. designing functions like independent sub-scripts that can't, or
vice versa...


> > read progdir prog path export_blob <<<$(env_init "$progdir" "$prog" 
"$this")
>  If you are going to use <<< then you *must* quote the word which follows
>  it:
>
>  read a <<< "$b"

Only if you want everything in "b" to end up in "a", otherwise, you just 
need
to make sure they are 'grouped', but in your example, using a single var 
in the
read -- never need quotes:

>  b="one two three"
>  read a <<<$b
>  echo $a
one two three

If you DO have more than one var (like I do), then putting adding the
quotes does:

>  word="one two three"; read a b c <<< "$word" ; echo "a=$a, b=$b, c=$c"
a=one, b=two, c=three
# (exactly what I would want it to do -- interesting!) 
# but if you don't use quotes, you get:
>  word="one two three"; read a b c <<< $word; echo "a=$a, b=$b, c=$c"
a=one, b=two, c=three

Weird, but I should have known better.   The key phrase is under the
redirection section:


   The  word  following the redirection operator in the following descrip-
   tions, unless otherwise noted, is subjected to brace  expansion,  tilde
   expansion, parameter expansion, command substitution, arithmetic expan‐
   sion, quote removal, pathname expansion, and  word  splitting.   If  it
   expands to more than one word, bash reports an error.

It seems to leave off variable expansion.


>  However, if your input source is a command rather than a variable
>  expansion, then you should probably be using < <() instead:
>
>  read progdir prog path export_blob < <(env_init "$progdir" "$prog" 
"$this")
---
   Why?  Seems like a different way to do it, but why do you prefer it?



> > if [[ $#<1 ]]; then
> >     errx 50 "Need mount_path of fs to create snap_rdiff from"
> > fi
>
>  I'd strongly suggest using ((...)) for arithmetic comparisons.
---
   I often do, but when I write tons of code and go back and forth from
perl and bash, where < in perl = numeric, and eq/lt/...etc are string
compares... I don't always remember until I look at things in cleanup.


>  As far as the original part of this thread is concerned: if you want a
>  reference to an array, use ksh93.  Bash doesn't have them.  In bash you
>  must use eval, with all its headaches, as shown in other messages of
>  this thread.
----
   If I was going to use another language, I'd use perl -- I wouldn't
try to shoe horn something this complex into another shell.