Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
syntax:basicgrammar [2015/08/10 03:29] bill_thomson |
syntax:basicgrammar [2019/04/01 21:45] (current) ddebhw Fix a little typo. |
||
|---|---|---|---|
| Line 17: | Line 17: | ||
| Sounds harder than it actually is. It is what you do daily. You enter simple commands with parameters, and the shell executes them. | Sounds harder than it actually is. It is what you do daily. You enter simple commands with parameters, and the shell executes them. | ||
| - | Every complex Bash operationcan be split into simple commands: | + | Every complex Bash operation can be split into simple commands: |
| <code> | <code> | ||
| ls | ls | ||
| Line 80: | Line 80: | ||
| ^Operator^Description^ | ^Operator^Description^ | ||
| - | |''<PIPELINE1> **<newline>** <PIPELINE2>''|Newlines completely separate pipelines. The next pipeline is executed without any checks. You enter a command and press ''<RETURN>''!)| | + | |''<PIPELINE1> **<newline>** <PIPELINE2>''|Newlines completely separate pipelines. The next pipeline is executed without any checks. (You enter a command and press ''<RETURN>''!)| |
| |''<PIPELINE1> **;** <PIPELINE2>''|The semicolon does what ''<newline>'' does: It separates the pipelines| | |''<PIPELINE1> **;** <PIPELINE2>''|The semicolon does what ''<newline>'' does: It separates the pipelines| | ||
| |''<PIPELINE> **&** <PIPELINE>''|The pipeline in front of the ''&'' is executed **asynchronously** ("in the background"). If a pipeline follows this, it is executed immediately after the async pipeline starts| | |''<PIPELINE> **&** <PIPELINE>''|The pipeline in front of the ''&'' is executed **asynchronously** ("in the background"). If a pipeline follows this, it is executed immediately after the async pipeline starts| | ||
| Line 152: | Line 152: | ||
| </code> | </code> | ||
| - | The space between ''NAME'' and ''()'' is optional, usually you just see it without. | + | The space between ''NAME'' and ''()'' is optional, usually you see it without the space. |
| - | I suggest to use the first form. It's specified in POSIX and all Bourne-like shells seem to support it. | + | I suggest using the first form. It's specified in POSIX and all Bourne-like shells seem to support it. |
| - | __**Note:**__ Before version ''2.05-alpha1'', Bash only recognized the definition using curly braces (''name() { ... }''), also, other shells allow the definition using **any** command (not only compound command set). | + | __**Note:**__ Before version ''2.05-alpha1'', Bash only recognized the definition using curly braces (''name() { ... }''), other shells allow the definition using **any** command (not just the compound command set). |
| - | To execute a function like a regular shell script you would put it together like this: | + | To execute a function like a regular shell script you put it together like this: |
| <code> | <code> | ||
| Line 166: | Line 166: | ||
| mycmd() | mycmd() | ||
| { | { | ||
| - | # this $1 is the one of the function! | + | # this $1 belongs to the function! |
| find / -iname "$1" | find / -iname "$1" | ||
| } | } | ||
| - | # this $1 is the one of the script itself! | + | # this $1 belongs the script itself! |
| mycmd "$1" # Execute command immediately after defining function | mycmd "$1" # Execute command immediately after defining function | ||
| Line 178: | Line 178: | ||
| **Just informational(1):** | **Just informational(1):** | ||
| - | Internally, for forking, Bash stores the function definitions in environment variables. Variables with the content "//() ....//". | + | Internally, for forking, Bash stores function definitions in environment variables. Variables with the content "//() ....//". |
| - | Something like the following works without "officially" declaring a function: | + | Something similar to the following works without "officially" declaring a function: |
| <code> | <code> | ||
| $ export testfn="() { echo test; }" | $ export testfn="() { echo test; }" | ||
| Line 190: | Line 190: | ||
| **Just informational(2):** | **Just informational(2):** | ||
| - | It is possible to set function names containing slashes: | + | It is possible to create function names containing slashes: |
| <code> | <code> | ||
| Line 198: | Line 198: | ||
| </code> | </code> | ||
| - | The elements of this name aren't subject to path search, of course. | + | The elements of this name aren't subject to a path search. |
| - | The weird names a function can have should not be used. Quote from the maintainer: | + | Weird function names should not be used. Quote from the maintainer: |
| * // | * // | ||
| It was a mistake to allow such characters in function names (`unset' doesn't | It was a mistake to allow such characters in function names (`unset' doesn't | ||
| Line 209: | Line 209: | ||
| ===== Grammar summary ===== | ===== Grammar summary ===== | ||
| - | Not much of correct definitions, just some short **slogans**: | ||
| * a [[basicgrammar#simple_commands | simple command]] is just a command and its arguments | * a [[basicgrammar#simple_commands | simple command]] is just a command and its arguments | ||
| * a [[basicgrammar#pipelines | pipeline]] is one or more [[basicgrammar#simple_commands | simple command]] probably connected in a pipe | * a [[basicgrammar#pipelines | pipeline]] is one or more [[basicgrammar#simple_commands | simple command]] probably connected in a pipe | ||
| * a [[basicgrammar#lists | list]] is one or more [[basicgrammar#pipelines | pipelines]] connected by special operators | * a [[basicgrammar#lists | list]] is one or more [[basicgrammar#pipelines | pipelines]] connected by special operators | ||
| * a [[basicgrammar#compound_commands | compound command]] is a [[basicgrammar#lists | list]] or a special command that forms a new meta-command | * a [[basicgrammar#compound_commands | compound command]] is a [[basicgrammar#lists | list]] or a special command that forms a new meta-command | ||
| - | * a [[basicgrammar#shell_function_definitions | function definition]] makes a [[basicgrammar#compound_commands | compound command]] available under a new name, and in some kind of separate environment | + | * a [[basicgrammar#shell_function_definitions | function definition]] makes a [[basicgrammar#compound_commands | compound command]] available under a new name, and a separate environment |
| Line 222: | Line 221: | ||
| ---- | ---- | ||
| - | __A (very ;-)) simple command__ | + | __A (very) simple command__ |
| <code> | <code> | ||
| echo "Hello world..." | echo "Hello world..." | ||
| Line 238: | Line 237: | ||
| fi | fi | ||
| </code> | </code> | ||
| - | * the [[basicgrammar#compound_commands | compound command]] for the ''if''-clause | + | * the [[basicgrammar#compound_commands | compound command]] for the ''if'' clause |
| * the [[basicgrammar#lists | list]] that ''if'' **checks** actually contains the [[basicgrammar#simple_commands | simple command]] ''[ -d /data/mp3 ]'' | * the [[basicgrammar#lists | list]] that ''if'' **checks** actually contains the [[basicgrammar#simple_commands | simple command]] ''[ -d /data/mp3 ]'' | ||
| * the [[basicgrammar#lists | list]] that ''if'' **executes** contains a simple command (''cp mymusic.mp3 /data/mp3'') | * the [[basicgrammar#lists | list]] that ''if'' **executes** contains a simple command (''cp mymusic.mp3 /data/mp3'') | ||
| - | Let's reverse the exit code of the test command, only one thing changes: | + | Let's invert test command exit code, only one thing changes: |
| <code> | <code> | ||
| if ! [ -d /data/mp3 ]; then | if ! [ -d /data/mp3 ]; then | ||