Loading ...
Sorry, an error occurred while loading the content.

Re: [hackers-il] Summary of a Bash Lecture

Expand Messages
  • Shlomi Fish
    ... I m not planning to cover readline too much in the lecture, because: 1. It has lots of options, most of which I never use. 2. Most users are familiar with
    Message 1 of 59 , Nov 1, 2000
    • 0 Attachment
      On Tue, 31 Oct 2000, Omer Mussaev wrote:

      > Shlomi Fish wrote:
      >
      > > I'm considering giving a lecture about Bash to the Haifa Linux Club. I
      > > started to write a summary of it and you can find it at the following URL:
      > >
      > > http://vipe.technion.ac.il/~shlomif/lecture/Bash/
      > >
      > > If you wish, read it and send your comments, either personally to me or to
      > > the list.
      >
      > Why not do it collectively?
      >
      >
      > Original summary:
      >
      > > Summary of sh/Bash Lecture:
      > > ------------------------
      > >
      > > - Executing simple commands: command name followed by parameters
      > > Examples:
      > > ls
      > > ls -l
      > > cp test.pl old_test.pl
      > >
      > > - Filename Matching mechanisms:
      > > *
      > > []
      > > ?
      > > Examples:
      > > ls -l *.c
      > > cp *.c ./bak_dir
      >
      >
      > simple readline quickies:
      >
      > arrows - history
      > ^-r find command in history by name
      >
      > readline is NOT shell
      >

      I'm not planning to cover readline too much in the lecture, because:
      1. It has lots of options, most of which I never use.
      2. Most users are familiar with its basic options (tab, up and down
      arrows, etc.)
      3. I want my lecture to be as sh (ash) complaint as possible and the use
      of readline is unique to bash and zsh.

      > >
      > > - Pipeline: explain a little about standard input/standard output,
      > > then show
      > > the following redirection mechanisms:
      > > |
      > > >
      > > <
      > > Examples:
      > > ls -l | less
      > > cat *.c *h | wc -l
      > > ls -l | grep ^d | wc -l
      >
      > What about :
      >
      > ls ./no_such_file 2>/dev/null
      > FDT
      > ls -l /proc/$$/fd/ to show file descriptors
      >

      I plan to cover 2> 2>&1, etc. later on.

      > >
      > > - The ";" - executing more than one statements in the same batch. A
      > > synchronous executions.
      > > Examples:
      > > cd ./test_dir ; tar -czvf ../test_dir.tar.gz *
      > >
      >
      > && - conditional execution
      >
      >
      > The following section is better be given after variables (IMHO)
      >
      > >
      > > - The "(" .. ")" - grouping statements inside a _subshell_ (separate
      > > process).
      > > Examples:
      > > (cd ./bin ; ls d* ) > files_in_bin_that_start_with_a_d.txt
      >
      > {} - same process
      >

      Interesting, I did not know that, as I use ( .. ) most of the time.

      > put {} and give it a name - function.
      >
      > Differences: exported variables vs non-exported variables.
      >
      > A=1
      > B=2
      > export A
      > {
      > echo A is ${A:-"unset"}
      > echo B is ${B:-"unset"}
      > }
      > (
      > echo A is ${A:-"unset"}
      > echo B is ${B:-"unset"}
      > )
      >
      > Control structures:
      >
      > do ; done - a block
      >
      > if ; then ; fi
      > while
      > for atom in lat
      >

      I'm not finished with the lecture summary. I am going to cover loops,
      conditionals, etc. but later on.

      >
      > >
      > > - Using the backslash (with no whitespace afterwards) to split
      > > commands across
      > > several lines. Eases readability:
      > > Examples:
      > > cp *.c *.h README Makefile TODO \
      > > USAGE INSTALL \
      > > ./bak
      > >
      > > - Introducing comments with "#". They start with a # and extend to the
      > > end of
      > > the line.
      > >
      > > Variables:
      > > ----------
      > >
      > > - Simple assignment: "=". (note that there cannot be any whitespace before
      > > and after the "=" symbol.)
      > > Examples:
      > > A=hello
      > > B=yellow ; turn=500
      > >
      > > - Retrieving the value of a variable using $ or ${} . (not $() !)
      > > Examples:
      > > - A=hello
      > > echo $A
      > > - VARIABLE=5
      > > B=${VARIABLE}
      > > VARIABLE=800
      > > echo $B
      > > - A=Y
      > > Y=80
      > > echo ${$A}
      > >
      > > - A little about extrapolation: A dollar can appear anywhere. If the shell
      > > encounters a $ which is not followed by curly brackets ("{" .. "}")
      > > it will
      > > try to extroplate its name from as many characters as it find, even if
      > > a variable by that name does not exist. Thus, when in doubt, use the
      > > "${NAME}" form.
      > >
      > > Examples:
      > > - A=hello
      > > echo $Aworld
      > > # does not print helloworld
      > >
      > >
      > > - The "${parameter:-defaultvalue}" form enables you to give the
      > > expression a
      > > default value in case the variable is not assigned.
      > > Examples:
      > > -
      > > #!/bin/bash
      > >
      > > ;
      > > ; Possibly set A
      > > B=${A:-not_set}
      > > ; Check if B is equal to not_set and accordingly do something.
      > >
      > > - To unset a variable use the "unset" command:
      > > Examples:
      > > -
      > > #!/bin/bash
      > > A=5
      > > B=80
      > > RESULT=400
      > > echo $A \* $B = $RESULT
      > > unset A B RESULT
      > >
      > > - To display a list of the declared variables and their values, use
      > > the "set"
      > > command without any options. (set is of little use in scripts except for
      > > debugging purposes).
      > >
      > > Examples:
      > > -
      > > A=32482 ; B=932840 ; C=1932840 ; D=890 ; E=hello ; F=world
      > > unset A E
      > > set | grep '^[A-F]='
      > >
      > > - The "read VARNAME" command reads a line from the standard output and
      > > puts
      > > it inside the variable "VARNAME".
      > > - Note: Do not use "read $VARNAME"!
      >
      > Actualy, read $VARNAME is legal...
      >

      I know, maybe I should show them this code:
      A=B
      B=A
      read $A
      echo A
      echo B

      to demonstrate what it does.

      > >
      > >
      > > Examples:
      > >
      >
      > `` and $() program substitution.
      > Why it is better to use $()
      > Example:
      > $( cd $( echo "/usr" ) && pwd ) instead of
      > `cd \`echo "/usr"\' && pwd`
      >

      Like I said I am going to cover it just later on. And I know $() is
      usually better than ``.

      Regards,

      Shlomi Fish


      ----------------------------------------------------------------------
      Shlomi Fish shlomif@...
      Home Page: http://t2.technion.ac.il/~shlomif/
      Home E-mail: shlomif@...

      The prefix "God Said" has the extraordinary logical property of
      converting any statement that follows it into a true one.
    • Nadav Har'El
      ... The obvious answer is that all languages can be optimized the same: if the optimizer is smart enough, and given a program in C that can somehow be run
      Message 59 of 59 , Nov 15, 2000
      • 0 Attachment
        On Wed, Nov 15, 2000, Chen Shapira wrote about "RE: [hackers-il] Summary of a Bash Lecture":
        > BTW. Is there any knowledge about a theoretical limit of how well a language
        > can be optimised "by design"?
        >
        > Meaning: a program written in c can be optimised for speed until it takes x
        > seconds to run and no farther, while the same program in pascal can be
        > optimised until it takes y seconds to run and no farther, where x!=y?

        The "obvious" answer is that all languages can be optimized the same: if the
        optimizer is smart enough, and given a program in C that can somehow be run
        faster if written in Fortran, then the super-smart optimizer can convert the
        program to Fortran as its first step.

        But in real life, this is not so simple. Consider the following zsh script:

        let i=0
        CMD="let i++"

        if [[ `date` = "never" ]]
        then
        CMD="let i+=2"
        fi

        for j in a b c
        do
        eval $CMD
        done
        print $i


        This can be optimized (if the optimizer is smart enough) to
        if [[ `date` = "never" ]]
        then
        print 6
        else
        print 3
        fi

        But if you realise that date can never return "never" (sounds like a James
        Bond movie...), then it can be further optimized to
        print 3

        This looks like a contrived example, and it is, but it shows a point: a
        smart enough optimizer can take code in Zsh, Perl, C++, or whatever, and
        optimize it into the best possible assembly-language code (i.e., that no
        other code that does the same thing runs faster). But how do you define
        "doing the same thing"? Instead of running the "date" program, the shell
        compiler/optimizer could call ctime() directly. But what if the installed
        date program has some strange side-effects (e.g., changing the access time
        of the file "/bin/date"!) that the program relies on? Maybe the whole point
        of the above program was to be a "touch -a /bin/date" clone, and the "let i=.."
        stuff, not the `date` stuff, needs to be optimized out?

        The problem is that different languages let you do pretty high-level things
        that each has dozens of implications and/or side-effects, so keeping all these
        side-effects may mean we can't do any optimization at all...

        As another example, consider a Tcl/Tk program (I hope you know what I'm
        talking about). In Tcl/Tk, the callbacks of widgets are written in the
        interpreted language Tcl; Because of this fact you (the programmer) can
        change widget bindings on the fly, and other crazy stuff like that. And
        all this interpreting is slow. It is obvious that it is possible to write
        a different program in (say) C/Xlib, that does exactly the same thing, but
        quicker, but making this transformation (also known as "optimization" - the
        distinction between a "compiler" and "optimizer" in this context is a little
        fuzzy) is nearly impossible in practice... Also, does this C/Xlib really does
        the *same* thing? The Tcl/Tk program might be able to read widget bindings
        from a user's script file, and the C/Xlib will not... So it's not exactly the
        same thing - who decides if this optimization is a good enough approximation?




        --
        Nadav Har'El | Wednesday, Nov 15 2000, 17 Heshvan 5761
        nyh@... |-----------------------------------------
        Phone: +972-53-245868, ICQ 13349191 |Willpower: The ability to eat only one
        http://nadav.harel.org.il |salted peanut.
      Your message has been successfully submitted and would be delivered to recipients shortly.