mirror of
https://github.com/flokoe/bash-hackers-wiki.git
synced 2024-11-01 06:53:05 +01:00
format(docs): replace escaped special characters
This commit is contained in:
parent
4166a76a00
commit
99161c5fa3
@ -138,7 +138,7 @@ RHS.
|
||||
sum total a b c
|
||||
printf 'Final value of "total" is: %d\n' "$total"
|
||||
|
||||
\<div hide\> function sum {
|
||||
<div hide> function sum {
|
||||
|
||||
typeset -n _result=$1
|
||||
shift
|
||||
@ -153,7 +153,7 @@ RHS.
|
||||
}
|
||||
|
||||
a=(1 2 3); b=(6 5 4); c=(2 4 6) sum total a b c printf \'Final value of
|
||||
\"total\" is: %d\\n\' \"\$total\" \</div\>
|
||||
\"total\" is: %d\\n\' \"\$total\" </div>
|
||||
|
||||
`typeset -n` is currently implemented in ksh93, mksh, and Bash 4.3. Bash
|
||||
and mksh's implementations are quite similar, but much different from
|
||||
|
@ -109,7 +109,7 @@ controlled carefully by the caller is a good way to use it.
|
||||
~~ksh93~~ and zsh don't do this properly
|
||||
([fixed](http://article.gmane.org/gmane.comp.programming.tools.ast.devel/686)
|
||||
in ksh 93v- 2012-10-24 alpha). Earlier versions of zsh work (with
|
||||
`setopt POSIX_BUILTINS` \-- looks like a regression). This works
|
||||
`setopt POSIX_BUILTINS` -- looks like a regression). This works
|
||||
correctly in Bash POSIX mode, Dash, and mksh.
|
||||
|
||||
```{=html}
|
||||
@ -161,14 +161,14 @@ identical to those of [let](../../commands/builtin/let.md).
|
||||
## See also
|
||||
|
||||
- [BashFAQ 48 - eval and security
|
||||
issues](http://mywiki.wooledge.org/BashFAQ/048) \-- **IMPORTANT**
|
||||
issues](http://mywiki.wooledge.org/BashFAQ/048) -- **IMPORTANT**
|
||||
- [Another eval
|
||||
article](http://fvue.nl/wiki/Bash:_Why_use_eval_with_variable_expansion%3F)
|
||||
- [Indirection via
|
||||
eval](http://mywiki.wooledge.org/BashFAQ/006#Assigning_indirect.2BAC8-reference_variables)
|
||||
- [More indirection via
|
||||
eval](http://fvue.nl/wiki/Bash:_Passing_variables_by_reference)
|
||||
- [Martin Väth's \"push\"](https://github.com/vaeth/push) \--
|
||||
- [Martin Väth's \"push\"](https://github.com/vaeth/push) --
|
||||
`printf %q` work-alike for POSIX.
|
||||
- [The \"magic alias\"
|
||||
hack](http://www.chiark.greenend.org.uk/~sgtatham/aliases.html)
|
||||
|
@ -41,12 +41,12 @@ command](../../syntax/ccmd/arithmetic_eval.md):
|
||||
$ echo "$a - $b - $?"
|
||||
4 - 2 - 0
|
||||
|
||||
\<WRAP info\> Remember that inside arithmetic evaluation contexts, all
|
||||
<WRAP info> Remember that inside arithmetic evaluation contexts, all
|
||||
other expansions are processed as usual (from left-to-right), and the
|
||||
resulting text is evaluated as an arithmetic expression. Arithmetic
|
||||
already has a way to control precedence using parentheses, so it's very
|
||||
rare to need to nest arithmetic expansions within one another. It's
|
||||
used above only to illustrate how this precedence works. \</WRAP\>
|
||||
used above only to illustrate how this precedence works. </WRAP>
|
||||
|
||||
Unlike `((`, being a simple command `let` has its own environment. In
|
||||
Bash, built-ins that can set variables process any arithmetic under
|
||||
|
@ -121,7 +121,7 @@ illustrates the callback behavior:
|
||||
|
||||
Since redirects are syntactically allowed anywhere in a command, we put
|
||||
it before the printf to stay out of the way of additional arguments.
|
||||
Rather than opening \"outfile\<n\>\" for appending on each call by
|
||||
Rather than opening \"outfile<n>\" for appending on each call by
|
||||
calculating the filename, open an FD for each first and calculate which
|
||||
FD to send output to by measuring the size of x mod 2. The zero-width
|
||||
format specification is used to absorb the index number argument.
|
||||
|
@ -1,16 +1,16 @@
|
||||
# The printf command
|
||||
|
||||
\<div center round todo box 70%\> FIXME Stranger, this is a very big
|
||||
<div center round todo box 70%> FIXME Stranger, this is a very big
|
||||
topic that needs experience - please fill in missing information, extend
|
||||
the descriptions, and correct the details if you can! \</div\> \<div
|
||||
center round tip 70%\> [**Attention:**]{.underline} This is about the
|
||||
the descriptions, and correct the details if you can! </div> <div
|
||||
center round tip 70%> [**Attention:**]{.underline} This is about the
|
||||
Bash-builtin command `printf` - however, the description should be
|
||||
nearly identical for an external command that follows POSIX(r).
|
||||
|
||||
[GNU Awk](http://www.gnu.org/software/gawk/manual/gawk.html#Printf)
|
||||
expects a comma after the format string and between each of the
|
||||
arguments of a **printf** command. For examples, see: [code
|
||||
snippet](../../printf?&.md#using_printf_inside_of_awk). \</div\>
|
||||
snippet](../../printf?&.md#using_printf_inside_of_awk). </div>
|
||||
|
||||
Unlike other documentations, I don't want to redirect you to the manual
|
||||
page for the `printf()` C function family. However, if you\'re more
|
||||
@ -57,7 +57,7 @@ argument!).
|
||||
The `-v` Option can't assign directly to array indexes in Bash versions
|
||||
older than Bash 4.1.
|
||||
|
||||
\<note warning\> In versions newer than 4.1, one must be careful when
|
||||
<note warning> In versions newer than 4.1, one must be careful when
|
||||
performing expansions into the first non-option argument of printf as
|
||||
this opens up the possibility of an easy code injection vulnerability.
|
||||
|
||||
@ -66,11 +66,11 @@ this opens up the possibility of an easy code injection vulnerability.
|
||||
declare -a x='([0]="hi")'
|
||||
|
||||
\...where the echo can of course be replaced with any arbitrary command.
|
||||
If you must, either specify a hard-coded format string or use \-- to
|
||||
If you must, either specify a hard-coded format string or use -- to
|
||||
signal the end of options. The exact same issue also applies to
|
||||
[read](../../commands/builtin/read.md), and a similar one to
|
||||
[mapfile](../../commands/builtin/mapfile.md), though performing expansions into
|
||||
their arguments is less common. \</note\>
|
||||
their arguments is less common. </note>
|
||||
|
||||
### Arguments
|
||||
|
||||
@ -97,7 +97,7 @@ Take care to avoid [word splitting](../../syntax/expansion/wordsplit.md), as
|
||||
accidentally passing the wrong number of arguments can produce wildly
|
||||
different and unexpected results. See [this article](../../syntax/words.md).
|
||||
|
||||
\<note warning\> [**Again, attention:**]{.underline} When a numerical
|
||||
<note warning> [**Again, attention:**]{.underline} When a numerical
|
||||
format expects a number, the internal `printf`-command will use the
|
||||
common Bash arithmetic rules regarding the base. A command like the
|
||||
following example **will** throw an error, since `08` is not a valid
|
||||
@ -105,7 +105,7 @@ octal number (`00` to `07`!):
|
||||
|
||||
printf '%d\n' 08
|
||||
|
||||
\</note\>
|
||||
</note>
|
||||
|
||||
### Format strings
|
||||
|
||||
@ -216,8 +216,8 @@ argument corresponding to a `%b` format.
|
||||
`\v` Prints a vertical tabulator
|
||||
`\"` Prints a `'`
|
||||
`\?` Prints a `?`
|
||||
`\<NNN>` Interprets `<NNN>` as **octal** number and prints the corresponding character from the character set
|
||||
`\0<NNN>` same as `\<NNN>`
|
||||
`<NNN>` Interprets `<NNN>` as **octal** number and prints the corresponding character from the character set
|
||||
`\0<NNN>` same as `<NNN>`
|
||||
`\x<NNN>` Interprets `<NNN>` as **hexadecimal** number and prints the corresponding character from the character set (**3 digits**)
|
||||
`\u<NNNN>` same as `\x<NNN>`, but **4 digits**
|
||||
`\U<NNNNNNNN>` same as `\x<NNN>`, but **8 digits**
|
||||
@ -412,7 +412,7 @@ fmt++;
|
||||
system's `/usr/bin/printf` or equivalent. The mksh maintainer
|
||||
recommends using `print`. The development version (post- R40f) adds
|
||||
a new parameter expansion in the form of `${name@Q}` which fills the
|
||||
role of `printf %q` \-- expanding in a shell-escaped format.
|
||||
role of `printf %q` -- expanding in a shell-escaped format.
|
||||
|
||||
```{=html}
|
||||
<!-- -->
|
||||
|
@ -20,7 +20,7 @@ If `<NAME...>` is given, the line is word-split using
|
||||
`<NAME>`. The remaining words are all assigned to the last `<NAME>` if
|
||||
more words than variable names are present.
|
||||
|
||||
\<WRAP center round info 90%\> If no `<NAME>` is given, the whole line
|
||||
<WRAP center round info 90%> If no `<NAME>` is given, the whole line
|
||||
read (without performing word-splitting!) is assigned to the shell
|
||||
variable [REPLY](../../syntax/shellvars.md#REPLY). Then, `REPLY` really contains
|
||||
the line as it was read, without stripping pre- and postfix spaces and
|
||||
@ -30,7 +30,7 @@ other things!
|
||||
printf '"%s"\n' "$REPLY"
|
||||
done <<<" a line with prefix and postfix space "
|
||||
|
||||
\</WRAP\>
|
||||
</WRAP>
|
||||
|
||||
If a timeout is given, or if the shell variable
|
||||
[TMOUT](../../syntax/shellvars.md#TMOUT) is set, it is counted from initially
|
||||
@ -61,7 +61,7 @@ Of course it's valid to set individual array elements without using
|
||||
|
||||
read MYARRAY[5]
|
||||
|
||||
\<WRAP center round important 90%\>
|
||||
<WRAP center round important 90%>
|
||||
|
||||
Reading into array elements using the syntax above **may cause [pathname
|
||||
expansion](../../syntax/expansion/globs.md) to occur**.
|
||||
@ -81,7 +81,7 @@ array name and index:
|
||||
|
||||
read 'x[1]'
|
||||
|
||||
\</WRAP\>
|
||||
</WRAP>
|
||||
|
||||
### Return status
|
||||
|
||||
@ -90,7 +90,7 @@ array name and index:
|
||||
0 no error
|
||||
0 error when assigning to a read-only variable [^1]
|
||||
2 invalid option
|
||||
\>128 timeout (see `-t`)
|
||||
>128 timeout (see `-t`)
|
||||
!=0 invalid filedescriptor supplied to `-u`
|
||||
!=0 end-of-file reached
|
||||
|
||||
|
@ -41,7 +41,7 @@ set flags (true for most commands on UNIX(r)).
|
||||
`-v` `verbose` Print shell input lines as they are read - useful for debugging.
|
||||
`-x` `xtrace` Print commands just before execution - with all expansions and substitutions done, and words marked - useful for debugging.
|
||||
`-B` `braceexpand` The shell performs [brace expansion](../../syntax/expansion/brace.md) This is on by default.
|
||||
`-C` \<BOOKMARK:tag_noclobber\>`noclobber` Don't overwrite files on redirection operations. You can override that by specifying the `>|` redirection operator when needed. See [redirection](../../syntax/redirection.md)
|
||||
`-C` <BOOKMARK:tag_noclobber>`noclobber` Don't overwrite files on redirection operations. You can override that by specifying the `>|` redirection operator when needed. See [redirection](../../syntax/redirection.md)
|
||||
`-E` `errtrace` `ERR`-traps are inherited by by shell functions, command substitutions, and commands executed in a subshell environment.
|
||||
`-H` `histexpand` Enable `!`-style history expansion. Defaults to `on` for interactive shells.
|
||||
`-P` `physical` Don't follow symlinks when changing directories - use the physical filesystem structure.
|
||||
|
@ -63,26 +63,26 @@ There are no options.
|
||||
dash: 1: shift: can't shift that many
|
||||
` In most shells, you can work around this problem using the
|
||||
[command](../../commands/builtin/command.md) builtin to suppress fatal
|
||||
errors caused by *special builtins*. \<code\> \$ dash -c \'f() { if
|
||||
command shift 2\>/dev/null; then echo \"\$1\"; else echo \"no
|
||||
errors caused by *special builtins*. <code> \$ dash -c \'f() { if
|
||||
command shift 2>/dev/null; then echo \"\$1\"; else echo \"no
|
||||
args\"; fi; }; f\'
|
||||
|
||||
no args \</code\> While, POSIX requires this behavior, it isn't very
|
||||
no args </code> While, POSIX requires this behavior, it isn't very
|
||||
obvious and some shells don't do it correctly. To work around this, you
|
||||
can use something like:
|
||||
|
||||
\<code\> \$ mksh -c \'f() { if ! \${1+false} && shift; then echo
|
||||
\"\$1\"; else echo \"no args\"; fi; }; f\' no args \</code\> ~~The mksh
|
||||
<code> \$ mksh -c \'f() { if ! \${1+false} && shift; then echo
|
||||
\"\$1\"; else echo \"no args\"; fi; }; f\' no args </code> ~~The mksh
|
||||
maintainer refuses to change either the `shift` or `command` builtins.~~
|
||||
[Fixed](https://github.com/MirBSD/mksh/commit/996e05548ab82f7ef2dea61f109cc7b6d13837fa).
|
||||
(Thanks!)
|
||||
|
||||
- Perhaps almost as bad as the above, busybox sh's `shift` always
|
||||
returns success, even when attempting to shift beyond the final
|
||||
argument. \<code\> \$ bb -c \'f() { if shift; then echo \"\$1\";
|
||||
argument. <code> \$ bb -c \'f() { if shift; then echo \"\$1\";
|
||||
else echo \"no args\"; fi; }; f\'
|
||||
|
||||
(no output) \</code\> The above mksh workaround will work in this case
|
||||
(no output) </code> The above mksh workaround will work in this case
|
||||
too.
|
||||
|
||||
## See also
|
||||
|
@ -87,60 +87,60 @@ Since Bash 4.1, all tests related to permissions respect ACLs, if the underlying
|
||||
|
||||
| Operator syntax | Description |
|
||||
| ------------------------- | ----------------------------------------------------------------------------------------------- |
|
||||
| **-a** <FILE\> | True if <FILE\> exists. :warning: (not recommended, may collide with `-a` for `AND`, see below) |
|
||||
| **-e** <FILE\> | True if <FILE\> exists. |
|
||||
| **-f** <FILE\> | True, if <FILE\> exists and is a **regular** file. |
|
||||
| **-d** <FILE\> | True, if <FILE\> exists and is a **directory**. |
|
||||
| **-c** <FILE\> | True, if <FILE\> exists and is a **character special** file. |
|
||||
| **-b** <FILE\> | True, if <FILE\> exists and is a **block special** file. |
|
||||
| **-p** <FILE\> | True, if <FILE\> exists and is a **named pipe** (FIFO). |
|
||||
| **-S** <FILE\> | True, if <FILE\> exists and is a **socket** file. |
|
||||
| **-L** <FILE\> | True, if <FILE\> exists and is a **symbolic link**. |
|
||||
| **-h** <FILE\> | True, if <FILE\> exists and is a **symbolic link**. |
|
||||
| **-g** <FILE\> | True, if <FILE\> exists and has **sgid bit** set. |
|
||||
| **-u** <FILE\> | True, if <FILE\> exists and has **suid bit** set. |
|
||||
| **-r** <FILE\> | True, if <FILE\> exists and is **readable**. |
|
||||
| **-w** <FILE\> | True, if <FILE\> exists and is **writable**. |
|
||||
| **-x** <FILE\> | True, if <FILE\> exists and is **executable**. |
|
||||
| **-s** <FILE\> | True, if <FILE\> exists and has size bigger than 0 (**not empty**). |
|
||||
| **-t** <fd\> | True, if file descriptor <fd\> is open and refers to a terminal. |
|
||||
| <FILE1\> **-nt** <FILE2\> | True, if <FILE1\> is **newer than** <FILE2\> (mtime). :warning: |
|
||||
| <FILE1\> **-ot** <FILE2\> | True, if <FILE1\> is **older than** <FILE2\> (mtime). :warning: |
|
||||
| <FILE1\> **-ef** <FILE2\> | True, if <FILE1\> and <FILE2\> refer to the **same device and inode numbers**. :warning: |
|
||||
| **-a** <FILE> | True if <FILE> exists. :warning: (not recommended, may collide with `-a` for `AND`, see below) |
|
||||
| **-e** <FILE> | True if <FILE> exists. |
|
||||
| **-f** <FILE> | True, if <FILE> exists and is a **regular** file. |
|
||||
| **-d** <FILE> | True, if <FILE> exists and is a **directory**. |
|
||||
| **-c** <FILE> | True, if <FILE> exists and is a **character special** file. |
|
||||
| **-b** <FILE> | True, if <FILE> exists and is a **block special** file. |
|
||||
| **-p** <FILE> | True, if <FILE> exists and is a **named pipe** (FIFO). |
|
||||
| **-S** <FILE> | True, if <FILE> exists and is a **socket** file. |
|
||||
| **-L** <FILE> | True, if <FILE> exists and is a **symbolic link**. |
|
||||
| **-h** <FILE> | True, if <FILE> exists and is a **symbolic link**. |
|
||||
| **-g** <FILE> | True, if <FILE> exists and has **sgid bit** set. |
|
||||
| **-u** <FILE> | True, if <FILE> exists and has **suid bit** set. |
|
||||
| **-r** <FILE> | True, if <FILE> exists and is **readable**. |
|
||||
| **-w** <FILE> | True, if <FILE> exists and is **writable**. |
|
||||
| **-x** <FILE> | True, if <FILE> exists and is **executable**. |
|
||||
| **-s** <FILE> | True, if <FILE> exists and has size bigger than 0 (**not empty**). |
|
||||
| **-t** <fd> | True, if file descriptor <fd> is open and refers to a terminal. |
|
||||
| <FILE1> **-nt** <FILE2> | True, if <FILE1> is **newer than** <FILE2> (mtime). :warning: |
|
||||
| <FILE1> **-ot** <FILE2> | True, if <FILE1> is **older than** <FILE2> (mtime). :warning: |
|
||||
| <FILE1> **-ef** <FILE2> | True, if <FILE1> and <FILE2> refer to the **same device and inode numbers**. :warning: |
|
||||
|
||||
## String tests
|
||||
|
||||
| Operator syntax | Description |
|
||||
| ---------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| **-z** <STRING\> | True, if <STRING\> is **empty**. |
|
||||
| **-n** <STRING\> | True, if <STRING\> is **not empty** (this is the default operation). |
|
||||
| <STRING1\> **=** <STRING2\> | True, if the strings are **equal**. |
|
||||
| <STRING1\> **!=** <STRING2\> | True, if the strings are **not equal**. |
|
||||
| <STRING1\> **<** <STRING2\> | True if <STRING1\> sorts **before** <STRING2\> lexicographically (pure ASCII, not current locale!). Remember to escape! Use `\<` |
|
||||
| <STRING1\> **\>** <STRING2\> | True if <STRING1\> sorts **after** <STRING2\> lexicographically (pure ASCII, not current locale!). Remember to escape! Use `\>` |
|
||||
| **-z** <STRING> | True, if <STRING> is **empty**. |
|
||||
| **-n** <STRING> | True, if <STRING> is **not empty** (this is the default operation). |
|
||||
| <STRING1> **=** <STRING2> | True, if the strings are **equal**. |
|
||||
| <STRING1> **!=** <STRING2> | True, if the strings are **not equal**. |
|
||||
| <STRING1> **<** <STRING2> | True if <STRING1> sorts **before** <STRING2> lexicographically (pure ASCII, not current locale!). Remember to escape! Use `<` |
|
||||
| <STRING1> **>** <STRING2> | True if <STRING1> sorts **after** <STRING2> lexicographically (pure ASCII, not current locale!). Remember to escape! Use `>` |
|
||||
|
||||
## Arithmetic tests
|
||||
|
||||
| Operator syntax | Description |
|
||||
| ------------------------------- | ------------------------------------------------------------------- |
|
||||
| <INTEGER1\> **-eq** <INTEGER2\> | True, if the integers are **equal**. |
|
||||
| <INTEGER1\> **-ne** <INTEGER2\> | True, if the integers are **NOT equal**. |
|
||||
| <INTEGER1\> **-le** <INTEGER2\> | True, if the first integer is **less than or equal** second one. |
|
||||
| <INTEGER1\> **-ge** <INTEGER2\> | True, if the first integer is **greater than or equal** second one. |
|
||||
| <INTEGER1\> **-lt** <INTEGER2\> | True, if the first integer is **less than** second one. |
|
||||
| <INTEGER1\> **-gt** <INTEGER2\> | True, if the first integer is **greater than** second one. |
|
||||
| <INTEGER1> **-eq** <INTEGER2> | True, if the integers are **equal**. |
|
||||
| <INTEGER1> **-ne** <INTEGER2> | True, if the integers are **NOT equal**. |
|
||||
| <INTEGER1> **-le** <INTEGER2> | True, if the first integer is **less than or equal** second one. |
|
||||
| <INTEGER1> **-ge** <INTEGER2> | True, if the first integer is **greater than or equal** second one. |
|
||||
| <INTEGER1> **-lt** <INTEGER2> | True, if the first integer is **less than** second one. |
|
||||
| <INTEGER1> **-gt** <INTEGER2> | True, if the first integer is **greater than** second one. |
|
||||
|
||||
## Misc syntax
|
||||
|
||||
| Operator syntax | Description |
|
||||
| ------------------------ | ------------------------------------------------------------------------------------------------------------------------ |
|
||||
| <TEST1\> **-a** <TEST2\> | True, if <TEST1\> **and** <TEST2\> are true (AND). Note that `-a` also may be used as a file test (see above) |
|
||||
| <TEST1\> **-o** <TEST2\> | True, if either \<TEST1\> **or** <TEST2\> is true (OR). |
|
||||
| **!** <TEST\> | True, if <TEST\> is **false** (NOT). |
|
||||
| **(** <TEST\> **)** | Group a test (for precedence). **Attention:** In normal shell-usage, the `(` and `)` must be escaped; use `\(` and `\)`! |
|
||||
| **-o** <OPTION_NAME\> | True, if the [shell option](../internals/shell_options.md) <OPTION_NAME\> is set. |
|
||||
| **-v** <VARIABLENAME\> | True if the variable <VARIABLENAME\> has been set. Use `var[n]` for array elements. |
|
||||
| **-R** <VARIABLENAME\> | True if the variable <VARIABLENAME\> has been set and is a nameref variable (since 4.3-alpha) |
|
||||
| <TEST1> **-a** <TEST2> | True, if <TEST1> **and** <TEST2> are true (AND). Note that `-a` also may be used as a file test (see above) |
|
||||
| <TEST1> **-o** <TEST2> | True, if either <TEST1> **or** <TEST2> is true (OR). |
|
||||
| **!** <TEST> | True, if <TEST> is **false** (NOT). |
|
||||
| **(** <TEST> **)** | Group a test (for precedence). **Attention:** In normal shell-usage, the `(` and `)` must be escaped; use `(` and `)`! |
|
||||
| **-o** <OPTION_NAME> | True, if the [shell option](../internals/shell_options.md) <OPTION_NAME> is set. |
|
||||
| **-v** <VARIABLENAME> | True if the variable <VARIABLENAME> has been set. Use `var[n]` for array elements. |
|
||||
| **-R** <VARIABLENAME> | True if the variable <VARIABLENAME> has been set and is a nameref variable (since 4.3-alpha) |
|
||||
|
||||
## Number of Arguments Rules
|
||||
|
||||
@ -290,7 +290,7 @@ true
|
||||
For the test command, the precedence parenthesis are, as well, `( )`, but you need to escape or quote them, so that the shell doesn't try to interpret them:
|
||||
|
||||
```bash
|
||||
$ if [ \( "true" -o -e /does/not/exist \) -a -e /does/not/exist ]; then echo true; else echo false; fi
|
||||
$ if [ ( "true" -o -e /does/not/exist ) -a -e /does/not/exist ]; then echo true; else echo false; fi
|
||||
false
|
||||
|
||||
# equivalent, but less readable IMHO:
|
||||
@ -527,7 +527,7 @@ done
|
||||
- Internal: [conditional expression](../syntax/ccmd/conditional_expression.md) (aka "the new test command")
|
||||
- Internal: [the if-clause](../syntax/ccmd/if_clause.md)
|
||||
|
||||
[^1]: <rant\>Of course, one can wonder what is the use of including the
|
||||
[^1]: <rant>Of course, one can wonder what is the use of including the
|
||||
parenthesis in the specification without defining the behaviour with
|
||||
more than 4 arguments or how usefull are the examples with 7 or 9
|
||||
arguments attached to the specification.</rant\>
|
||||
arguments attached to the specification.</rant>
|
||||
|
@ -68,7 +68,7 @@ negation (`! pipeline`).
|
||||
|
||||
`` eval echo \$? <&0`false` `` 1 1 1 1 0 0 0 0 1
|
||||
|
||||
`while :; do ! break; done; echo $?` 1 1 1 1 0 0 1 1 \-
|
||||
`while :; do ! break; done; echo $?` 1 1 1 1 0 0 1 1 -
|
||||
|
||||
[discussion](https://lists.gnu.org/archive/html/bug-bash/2010-09/msg00009.html)`false; : | echo $?` 1 1 1 0 1 1 1 1 0
|
||||
|
||||
@ -90,9 +90,9 @@ transparency of the return builtin.
|
||||
|
||||
`f() { return $?; }; false; f; echo $?` 1 1 1 1 1 1 1 1 1
|
||||
|
||||
`f() { ! return; }; f; echo $?` 0 0 1 0 0 0 1 1 \-
|
||||
`f() { ! return; }; f; echo $?` 0 0 1 0 0 0 1 1 -
|
||||
|
||||
`f() { ! return; }; false; f; echo $?` 1 1 0 0 1 1 0 0 \-
|
||||
`f() { ! return; }; false; f; echo $?` 1 1 0 0 1 1 0 0 -
|
||||
|
||||
`` f() { return; }; x=`false` f; echo $? `` 1 1 1 1 0 0 0 0 0
|
||||
|
||||
|
@ -73,7 +73,7 @@ happen again.
|
||||
$ mkdir "$j" && cd "$j" && ... && cd ..
|
||||
```
|
||||
|
||||
That's almost right, but there's one problem \-- what happens if `$j`
|
||||
That's almost right, but there's one problem -- what happens if `$j`
|
||||
contains a slash? Then `cd ..` will not return to the original
|
||||
directory. That's wrong! `cd -` causes cd to return to the previous
|
||||
working directory, so it's a much better choice:
|
||||
|
@ -341,8 +341,8 @@ read into memory.
|
||||
# equivalent
|
||||
ed -s file <<< 'g/foo/'
|
||||
|
||||
The name `grep` is derived from the notaion `g/RE/p` (global =\> regular
|
||||
expression =\> print). ref
|
||||
The name `grep` is derived from the notaion `g/RE/p` (global => regular
|
||||
expression => print). ref
|
||||
<http://www.catb.org/~esr/jargon/html/G/grep.html>
|
||||
|
||||
### wc -l
|
||||
|
@ -90,7 +90,7 @@ which means [end of options](../dict/terms/end_of_options.md).
|
||||
------------------------------------ ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
[OPTIND](../syntax/shellvars.md#OPTIND) Holds the index to the next argument to be processed. This is how `getopts` \"remembers\" its own status between invocations. Also useful to shift the positional parameters after processing with `getopts`. `OPTIND` is initially set to 1, and **needs to be re-set to 1 if you want to parse anything again with getopts**
|
||||
[OPTARG](../syntax/shellvars.md#OPTARG) This variable is set to any argument for an option found by `getopts`. It also contains the option flag of an unknown option.
|
||||
[OPTERR](../syntax/shellvars.md#OPTERR) (Values 0 or 1) Indicates if Bash should display error messages generated by the `getopts` builtin. The value is initialized to **1** on every shell startup - so be sure to always set it to **0** if you don't want to see annoying messages! **`OPTERR` is not specified by POSIX for the `getopts` builtin utility \-\-- only for the C `getopt()` function in `unistd.h` (`opterr`).** `OPTERR` is bash-specific and not supported by shells such as ksh93, mksh, zsh, or dash.
|
||||
[OPTERR](../syntax/shellvars.md#OPTERR) (Values 0 or 1) Indicates if Bash should display error messages generated by the `getopts` builtin. The value is initialized to **1** on every shell startup - so be sure to always set it to **0** if you don't want to see annoying messages! **`OPTERR` is not specified by POSIX for the `getopts` builtin utility --- only for the C `getopt()` function in `unistd.h` (`opterr`).** `OPTERR` is bash-specific and not supported by shells such as ksh93, mksh, zsh, or dash.
|
||||
|
||||
`getopts` also uses these variables for error reporting (they\'re set to
|
||||
value-combinations which arent possible in normal operation).
|
||||
@ -111,7 +111,7 @@ where:
|
||||
#### The option-string
|
||||
|
||||
The option-string tells `getopts` which options to expect and which of
|
||||
them must have an argument. The syntax is very simple \-\-- every option
|
||||
them must have an argument. The syntax is very simple --- every option
|
||||
character is simply named as is, this example-string would tell
|
||||
`getopts` to look for `-f`, `-A` and `-x`:
|
||||
|
||||
@ -219,7 +219,7 @@ options (letters preceded by a dash), so it wasn't triggered.
|
||||
$ ./go_test.sh /etc/passwd
|
||||
$
|
||||
|
||||
Again \-\-- nothing happened. The **very same** case: `getopts` didn't
|
||||
Again --- nothing happened. The **very same** case: `getopts` didn't
|
||||
see any valid or invalid options (letters preceded by a dash), so it
|
||||
wasn't triggered.
|
||||
|
||||
|
@ -53,8 +53,8 @@ they are succesfully locked, and can operate without colliding. Setting
|
||||
the timestamp is similar: One step to check the timespamp, a second step
|
||||
to set the timestamp.
|
||||
|
||||
\<WRAP center round tip 60%\> [**Conclusion:**]{.underline} We need an
|
||||
operation that does the check and the locking in one step. \</WRAP\>
|
||||
<WRAP center round tip 60%> [**Conclusion:**]{.underline} We need an
|
||||
operation that does the check and the locking in one step. </WRAP>
|
||||
|
||||
A simple way to get that is to create a **lock directory** - with the
|
||||
mkdir command. It will:
|
||||
@ -84,7 +84,7 @@ atomic. Maybe a while loop checking continously for the existence of the
|
||||
lock in the background and sending a signal such as USR1, if the
|
||||
directory is not found, can be done. The signal would need to be
|
||||
trapped. I am sure there there is a better solution than this
|
||||
suggestion* \-\-- *[sn18](sunny_delhi18@yahoo.com) 2009/12/19 08:24*
|
||||
suggestion* --- *[sn18](sunny_delhi18@yahoo.com) 2009/12/19 08:24*
|
||||
|
||||
**Note:** While perusing the Internet, I found some people asking if the
|
||||
`mkdir` method works \"on all filesystems\". Well, let's say it should.
|
||||
|
@ -44,7 +44,7 @@ connected to `/dev/pts/5`.
|
||||
|
||||
# Simple Redirections
|
||||
|
||||
## Output Redirection \"n\> file\"
|
||||
## Output Redirection \"n> file\"
|
||||
|
||||
`>` is probably the simplest redirection.
|
||||
|
||||
@ -97,7 +97,7 @@ pointing to `file`. The command will then start with:
|
||||
What will the command do with this descriptor? It depends. Often
|
||||
nothing. We will see later why we might want other file descriptors.
|
||||
|
||||
## Input Redirection \"n\< file\"
|
||||
## Input Redirection \"n< file\"
|
||||
|
||||
When you run a commandusing `command < file`, it changes the file
|
||||
descriptor `0` so that it looks like:
|
||||
@ -148,7 +148,7 @@ descriptors.
|
||||
|
||||
# More On File Descriptors
|
||||
|
||||
## Duplicating File Descriptor 2\>&1
|
||||
## Duplicating File Descriptor 2>&1
|
||||
|
||||
We have seen how to open (or redirect) file descriptors. Let us see how
|
||||
to duplicate them, starting with the classic `2>&1`. What does this
|
||||
@ -213,9 +213,9 @@ Similarly for output file descriptors, writing a line to file descriptor
|
||||
`s` will append a line to a file as will writing a line to file
|
||||
descriptor `t`.
|
||||
|
||||
\<note tip\>The syntax is somewhat confusing in that you would think
|
||||
<note tip>The syntax is somewhat confusing in that you would think
|
||||
that the arrow would point in the direction of the copy, but it's
|
||||
reversed. So it's `target>&source` effectively.\</note\>
|
||||
reversed. So it's `target>&source` effectively.</note>
|
||||
|
||||
So, as a simple example (albeit slightly contrived), is the following:
|
||||
|
||||
@ -225,7 +225,7 @@ So, as a simple example (albeit slightly contrived), is the following:
|
||||
exec 1>&3 # Copy 3 back into 1
|
||||
echo Done # Output to original stdout
|
||||
|
||||
## Order Of Redirection, i.e., \"\> file 2\>&1\" vs. \"2\>&1 \>file\"
|
||||
## Order Of Redirection, i.e., \"> file 2>&1\" vs. \"2>&1 >file\"
|
||||
|
||||
While it doesn't matter where the redirections appears on the command
|
||||
line, their order does matter. They are set up from left to right.
|
||||
@ -313,7 +313,7 @@ Then it sees our duplication `2>&1`:
|
||||
|
||||
And voila, both `1` and `2` are redirected to file.
|
||||
|
||||
## Why sed 's/foo/bar/\' file \>file Doesn't Work
|
||||
## Why sed 's/foo/bar/\' file >file Doesn't Work
|
||||
|
||||
This is a common error, we want to modify a file using something that
|
||||
reads from a file and writes the result to `stdout`. To do this, we
|
||||
@ -322,7 +322,7 @@ as we have seen, the redirections are setup before the command is
|
||||
actually executed.
|
||||
|
||||
So **BEFORE** sed starts, standard output has already been redirected,
|
||||
with the additional side effect that, because we used \>, \"file\" gets
|
||||
with the additional side effect that, because we used >, \"file\" gets
|
||||
truncated. When `sed` starts to read the file, it contains nothing.
|
||||
|
||||
## exec
|
||||
@ -438,11 +438,11 @@ it. It's probably better to do something like:
|
||||
#we don't need 3 any more
|
||||
|
||||
I\'ve seen some people using this as a way to discard, say stderr, using
|
||||
something like: command 2\>&-. Though it might work, I\'m not sure if
|
||||
something like: command 2>&-. Though it might work, I\'m not sure if
|
||||
you can expect all applications to behave correctly with a closed
|
||||
stderr.
|
||||
|
||||
When in doubt, I use 2\>/dev/null.
|
||||
When in doubt, I use 2>/dev/null.
|
||||
|
||||
# An Example
|
||||
|
||||
@ -628,7 +628,7 @@ The shell is pretty loose about what it considers a valid redirect.
|
||||
While opinions probably differ, this author has some (strong)
|
||||
recommendations:
|
||||
|
||||
- **Always** keep redirections \"tightly grouped\" \-- that is, **do
|
||||
- **Always** keep redirections \"tightly grouped\" -- that is, **do
|
||||
not** include whitespace anywhere within the redirection syntax
|
||||
except within quotes if required on the RHS (e.g. a filename that
|
||||
contains a space). Since shells fundamentally use whitespace to
|
||||
|
@ -23,7 +23,7 @@ We have a simple **stat.sh** script:
|
||||
echo "PYTHON LINES: $LINES"
|
||||
|
||||
This script evaluate the number of python files and the number of python
|
||||
code lines in the files. We can use it like **./stat.sh \<dir\>**
|
||||
code lines in the files. We can use it like **./stat.sh <dir>**
|
||||
|
||||
### Create testsuit
|
||||
|
||||
|
@ -28,7 +28,7 @@ Usually Bash and/or Linux (GNU Toolset) specific.
|
||||
$ sed statement <<< cat
|
||||
cement
|
||||
|
||||
$ \(-
|
||||
$ (-
|
||||
bash: (-: command not found
|
||||
|
||||
$ echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc
|
||||
|
@ -104,11 +104,11 @@ read any startup files in POSIX(r) mode.
|
||||
|
||||
Mode `/etc/profile` `~/.bash_profile` `~/.bash_login` `~/.profile` `~/.bashrc` `${ENV}`
|
||||
----------------------- ---------------- ------------------- ----------------- -------------- ------------- ----------
|
||||
Login shell X X X X \- \-
|
||||
Interactive shell \- \- \- \- X \-
|
||||
SH compatible login X \- \- X \- \-
|
||||
SH compatible \- \- \- \- \- X
|
||||
POSIX(r) compatiblity \- \- \- \- \- X
|
||||
Login shell X X X X - -
|
||||
Interactive shell - - - - X -
|
||||
SH compatible login X - - X - -
|
||||
SH compatible - - - - - X
|
||||
POSIX(r) compatiblity - - - - - X
|
||||
|
||||
## Bash run modes
|
||||
|
||||
|
@ -39,7 +39,7 @@ For this topic, see also
|
||||
`gnu_errfmt` 3.0-alpha
|
||||
`force_fignore` 3.0-alpha
|
||||
`failglob` 3.0-alpha
|
||||
`extquote` 3.0-alpha unsure \-- verify!
|
||||
`extquote` 3.0-alpha unsure -- verify!
|
||||
`extdebug` 3.0-alpha
|
||||
`pipefail` (for `set -o`) 3.0
|
||||
`functrace` (for `set -o`) 3.0
|
||||
@ -108,7 +108,7 @@ For this topic, see also
|
||||
`[[...]]`: new 2.02-alpha1 KSH93
|
||||
`[[...]]`: regex support (`=~`) 3.0-alpha
|
||||
`[[...]]`: quotable right-hand-side of `=~` forces string matching 3.2-alpha for consistency with pattern matching
|
||||
`[[...]]`: `<` and `>` operators respect locale 4.1-alpha for consistency, since 4.1-beta: ensure you have set compatiblity to \>4.0 (default)
|
||||
`[[...]]`: `<` and `>` operators respect locale 4.1-alpha for consistency, since 4.1-beta: ensure you have set compatiblity to >4.0 (default)
|
||||
`test`/`[`/`[[`: `-v` 4.2-alpha check if a variable is set
|
||||
`test`/`[`/`[[`: `-v` 4.2-alpha support array syntax to check for elements
|
||||
`test`/`[`/`[[`: `-N` accepts nanoseconds 5.1-alpha
|
||||
|
@ -61,12 +61,12 @@ a comment. The shebang is for the operating system, not for the shell.
|
||||
Programs that don't ignore such lines, may not work as shebang driven
|
||||
interpreters.
|
||||
|
||||
\<WRAP center round important 60%\> [**Attention:**]{.underline}When the
|
||||
<WRAP center round important 60%> [**Attention:**]{.underline}When the
|
||||
specified interpreter is unavailable or not executable (permissions),
|
||||
you usually get a \"`bad interpreter`\" error message., If you get
|
||||
nothing and it fails, check the shebang. Older Bash versions will
|
||||
respond with a \"`no such file or directory`\" error for a nonexistant
|
||||
interpreter specified by the shebang. \</WRAP\>
|
||||
interpreter specified by the shebang. </WRAP>
|
||||
|
||||
**Additional note:** When you specify `#!/bin/sh` as shebang and that's
|
||||
a link to a Bash, then Bash will run in POSIX(r) mode! See:
|
||||
|
@ -347,9 +347,9 @@ Why? Because when printed literally, the `^M` makes the cursor go back
|
||||
to the beginning of the line. The whole error message is *printed*, but
|
||||
you *see* only part of it!
|
||||
|
||||
\<note warning\> It's easy to imagine the `^M` is bad in other places
|
||||
<note warning> It's easy to imagine the `^M` is bad in other places
|
||||
too. If you get weird and illogical messages from your script, rule out
|
||||
the possibility that`^M` is involved. Find and eliminate it! \</note\>
|
||||
the possibility that`^M` is involved. Find and eliminate it! </note>
|
||||
|
||||
### How can I find and eliminate them?
|
||||
|
||||
|
@ -18,9 +18,9 @@ of POSIX, and some may be incompatible with POSIX.
|
||||
|
||||
Syntax Replacement Description
|
||||
---------------------------------- --------------------------------------------------------- --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
`&>FILE` and `>&FILE` `>FILE 2>&1` This redirection syntax is short for `>FILE 2>&1` and originates in the C Shell. The latter form is especially uncommon and should never be used, and the explicit form using separate redirections is preferred over both. These shortcuts contribute to confusion about the copy descriptor because the syntax is unclear. They also introduce parsing ambiguity, and conflict with POSIX. Shells without this feature treat `cmd1 &>file cmd2` as: \"background `cmd1` and then execute `cmd2` with its stdout redirected to `file`\", which is the correct interpretation of this expression. See: [redirection](../syntax/redirection.md) \`\$ { bash; dash \</dev/fd/0; } \<\<\<\'echo foo\>/dev/null&\>/dev/fd/2 echo bar\' foo echo bar bar\`
|
||||
`&>FILE` and `>&FILE` `>FILE 2>&1` This redirection syntax is short for `>FILE 2>&1` and originates in the C Shell. The latter form is especially uncommon and should never be used, and the explicit form using separate redirections is preferred over both. These shortcuts contribute to confusion about the copy descriptor because the syntax is unclear. They also introduce parsing ambiguity, and conflict with POSIX. Shells without this feature treat `cmd1 &>file cmd2` as: \"background `cmd1` and then execute `cmd2` with its stdout redirected to `file`\", which is the correct interpretation of this expression. See: [redirection](../syntax/redirection.md) \`\$ { bash; dash </dev/fd/0; } <<<\'echo foo>/dev/null&>/dev/fd/2 echo bar\' foo echo bar bar\`
|
||||
`$[EXPRESSION]` `$((EXPRESSION))` This undocumented syntax is completely replaced by the POSIX-conforming arithmetic expansion `$((EXPRESSION))`. It is unimplemented almost everywhere except Bash and Zsh. See [arithmetic expansion](../syntax/expansion/arith.md). [Some discussion](http://lists.gnu.org/archive/html/bug-bash/2012-04/msg00034.html).
|
||||
`COMMAND\ |&\ COMMAND` `COMMAND 2>&1 | COMMAND` This is an alternate pipeline operator derived from Zsh. Officially, it is not considered deprecated by Bash, but I highly discourage it. It conflicts with the list operator used for [coprocess](../syntax/keywords/coproc.md) creation in most Korn shells. It also has confusing behavior. The stdout is redirected first like an ordinary pipe, while the stderr is actually redirected last \-- after other redirects preceding the pipe operator. Overall, it's pointless syntax bloat. Use an explicit redirect instead.
|
||||
`COMMAND\ |&\ COMMAND` `COMMAND 2>&1 | COMMAND` This is an alternate pipeline operator derived from Zsh. Officially, it is not considered deprecated by Bash, but I highly discourage it. It conflicts with the list operator used for [coprocess](../syntax/keywords/coproc.md) creation in most Korn shells. It also has confusing behavior. The stdout is redirected first like an ordinary pipe, while the stderr is actually redirected last -- after other redirects preceding the pipe operator. Overall, it's pointless syntax bloat. Use an explicit redirect instead.
|
||||
`function\ NAME()\ COMPOUND-CMD` `NAME()\ COMPOUND-CMD` or `function\ NAME\ {\ CMDS;\ }` This is an amalgamation between the Korn and POSIX style function definitions - using both the `function` keyword and parentheses. It has no useful purpose and no historical basis or reason to exist. It is not specified by POSIX. It is accepted by Bash, mksh, zsh, and perhaps some other Korn shells, where it is treated as identical to the POSIX-style function. It is not accepted by AT&T ksh. It should never be used. See the next table for the `function` keyword. Bash doesn't have this feature documented as expressly deprecated.
|
||||
`for x; { ...;}` `do`, `done`, `in`, `esac`, etc. This undocumented syntax replaces the `do` and `done` reserved words with braces. Many Korn shells support various permutations on this syntax for certain compound commands like `for`, `case`, and `while`. Which ones and certain details like whether a newline or semicolon are required vary. Only `for` works in Bash. Needless to say, don't use it.
|
||||
|
||||
@ -75,6 +75,6 @@ surprised if you run across someone telling you not to use these.
|
||||
- [bashchanges](../scripting/bashchanges.md)
|
||||
- [Greg's BashFAQ 061: List of essential features added (with the
|
||||
Bash version tag)](BashFAQ>061)
|
||||
- [Bash \<-\> POSIX Portability guide with a focus on
|
||||
- [Bash <-> POSIX Portability guide with a focus on
|
||||
Dash](http://mywiki.wooledge.org/Bashism)
|
||||
- <http://mywiki.wooledge.org/BashPitfalls>
|
||||
|
@ -97,7 +97,7 @@ While useful in another situation, this way is lacks flexibility. The
|
||||
maximum number of arguments is a fixedvalue - which is a bad idea if you
|
||||
write a script that takes many filenames as arguments.
|
||||
|
||||
=\> forget that one
|
||||
=> forget that one
|
||||
|
||||
### Loops
|
||||
|
||||
|
@ -372,7 +372,7 @@ operation status of your script.
|
||||
|
||||
You know: **\"One of the main causes of the fall of the Roman Empire was
|
||||
that, lacking zero, they had no way to indicate successful termination
|
||||
of their C programs.\"** *\-- Robert Firth*
|
||||
of their C programs.\"** *-- Robert Firth*
|
||||
|
||||
## Misc
|
||||
|
||||
|
@ -295,7 +295,7 @@ switch to, to get the other 8 colors.
|
||||
|
||||
This is a slightly modified version of Charles Cooke's colorful
|
||||
Mandelbrot plot scripts ([original w/
|
||||
screenshot](http://earth.gkhs.net/ccooke/shell.html)) \-- ungolfed,
|
||||
screenshot](http://earth.gkhs.net/ccooke/shell.html)) -- ungolfed,
|
||||
optimized a bit, and without hard-coded terminal escapes. The `colorBox`
|
||||
function is [memoized](http://en.wikipedia.org/wiki/Memoization) to
|
||||
collect `tput` output only when required and output a new escape only
|
||||
|
@ -1,6 +1,6 @@
|
||||
# Add Color to your scripts
|
||||
|
||||
\-\-\-- dataentry snipplet \-\-\-- snipplet_tags : terminal, color
|
||||
---- dataentry snipplet ---- snipplet_tags : terminal, color
|
||||
LastUpdate_dt : 2013-03-23 Contributors : Frank Lazzarini, Dan Douglas
|
||||
type : snipplet
|
||||
|
||||
|
@ -1,6 +1,6 @@
|
||||
# Using `awk` to deal with CSV that uses quoted/unquoted delimiters
|
||||
|
||||
\-\-\-- dataentry snipplet \-\-\-- snipplet_tags : awk, csv
|
||||
---- dataentry snipplet ---- snipplet_tags : awk, csv
|
||||
LastUpdate_dt : 2010-07-31 Contributors : SiegX (IRC) type : snipplet
|
||||
|
||||
------------------------------------------------------------------------
|
||||
|
@ -1,6 +1,6 @@
|
||||
# Show size of a file
|
||||
|
||||
\-\-\-- dataentry snipplet \-\-\-- snipplet_tags: files, file size
|
||||
---- dataentry snipplet ---- snipplet_tags: files, file size
|
||||
LastUpdate_dt: 2010-07-31 Contributors: Frank Lazzarini type: snipplet
|
||||
|
||||
------------------------------------------------------------------------
|
||||
|
@ -1,6 +1,6 @@
|
||||
# Kill a background job without a message
|
||||
|
||||
\-\-\-- dataentry snipplet \-\-\-- snipplet_tags: kill, process
|
||||
---- dataentry snipplet ---- snipplet_tags: kill, process
|
||||
management, jobs LastUpdate_dt: 2010-07-31 Contributors: Jan Schampera
|
||||
type: snipplet
|
||||
|
||||
|
@ -1,6 +1,6 @@
|
||||
# Get largest file
|
||||
|
||||
\-\-\-- dataentry snipplet \-\-\-- snipplet_tags: directory, recursive,
|
||||
---- dataentry snipplet ---- snipplet_tags: directory, recursive,
|
||||
find, crawl LastUpdate_dt: 2013-03-23 Contributors: Dan Douglas type:
|
||||
snipplet
|
||||
|
||||
|
@ -1,6 +1,6 @@
|
||||
# Pausing a script (like MSDOS pause command)
|
||||
|
||||
\-\-\-- dataentry snipplet \-\-\-- snipplet_tags: terminal, pause, input
|
||||
---- dataentry snipplet ---- snipplet_tags: terminal, pause, input
|
||||
LastUpdate_dt: 2010-07-31 Contributors: Jan Schampera type: snipplet
|
||||
|
||||
------------------------------------------------------------------------
|
||||
|
@ -1,6 +1,6 @@
|
||||
# Print argument list for testing
|
||||
|
||||
\-\-\-- dataentry snipplet \-\-\-- snipplet_tags: debug, arguments
|
||||
---- dataentry snipplet ---- snipplet_tags: debug, arguments
|
||||
LastUpdate_dt: 2013-03-23 Contributors: Snappy (IRC), Dan Douglas type:
|
||||
snipplet
|
||||
|
||||
|
@ -1,6 +1,6 @@
|
||||
# Print a horizontal line
|
||||
|
||||
\-\-\-- dataentry snipplet \-\-\-- snipplet_tags: terminal, line
|
||||
---- dataentry snipplet ---- snipplet_tags: terminal, line
|
||||
LastUpdate_dt: 2010-07-31 Contributors: Jan Schampera, prince_jammys,
|
||||
ccsalvesen, others type: snipplet
|
||||
|
||||
|
@ -1,6 +1,6 @@
|
||||
# Print a random string or select random elements
|
||||
|
||||
\-\-\-- dataentry snipplet \-\-\-- snipplet_tags: terminal, line
|
||||
---- dataentry snipplet ---- snipplet_tags: terminal, line
|
||||
LastUpdate_dt: 2013-04-30 Contributors: Dan Douglas (ormaaj) type:
|
||||
snipplet
|
||||
|
||||
@ -31,7 +31,7 @@ basically the same principle as the `rndstr` function above.
|
||||
~ $ ( set -- foo bar baz bork; printf '%s ' "${!_[_=RANDOM%$#+1,0]"{0..10}"}"; echo )
|
||||
bork bar baz baz foo baz baz baz baz baz bork
|
||||
|
||||
\<div hide\> This has some interesting option parsing concepts, but is
|
||||
<div hide> This has some interesting option parsing concepts, but is
|
||||
overly complex. This is a good example of working too hard to avoid an
|
||||
eval for no benefit and some performance penalty. :/
|
||||
|
||||
@ -63,7 +63,7 @@ rndstr()
|
||||
fi
|
||||
```
|
||||
|
||||
\</div\>
|
||||
</div>
|
||||
|
||||
The remaining examples don't use quite the same tricks, which will
|
||||
hopefully be explained elsewhere eventually. See
|
||||
@ -83,7 +83,7 @@ printf '%.1s' "${a[RANDOM%${#a[@]}]}"{0..9} $'\n'
|
||||
The extra detail that makes this work is to notice that in Bash, [brace
|
||||
expansion](../syntax/expansion/brace.md) is usually the very first type of
|
||||
expansion to be processed, always before parameter expansion. Bash is
|
||||
unique in this respect \-- all other shells with a brace expansion
|
||||
unique in this respect -- all other shells with a brace expansion
|
||||
feature perform it almost last, just before pathname expansion. First
|
||||
the sequence expansion generates ten parameters, then the parameters are
|
||||
expanded left-to-right causing the [arithmetic](../syntax/arith_expr.md) for
|
||||
|
@ -1,6 +1,6 @@
|
||||
# Save and restore terminal/screen content
|
||||
|
||||
\-\-\-- dataentry snipplet \-\-\-- snipplet_tags: terminal, restore
|
||||
---- dataentry snipplet ---- snipplet_tags: terminal, restore
|
||||
screen LastUpdate_dt: 2010-07-31 Contributors: Greg Wooledge type:
|
||||
snipplet
|
||||
|
||||
|
@ -1,6 +1,6 @@
|
||||
# Fetching SSH hostkeys without interaction
|
||||
|
||||
\-\-\-- dataentry snipplet \-\-\-- snipplet_tags: ssh, ssh-keys
|
||||
---- dataentry snipplet ---- snipplet_tags: ssh, ssh-keys
|
||||
LastUpdate_dt: 2010-07-31 Contributors: Jan Schampera
|
||||
|
||||
------------------------------------------------------------------------
|
||||
|
@ -1,6 +1,6 @@
|
||||
# Run some bash commands with SSH remotely using local variables
|
||||
|
||||
\-\-\-- dataentry snipplet \-\-\-- snipplet_tags: ssh, variables
|
||||
---- dataentry snipplet ---- snipplet_tags: ssh, variables
|
||||
LastUpdate_dt: 2010-07-31 Contributors: cweiss type: snipplet
|
||||
|
||||
------------------------------------------------------------------------
|
||||
|
@ -1,6 +1,6 @@
|
||||
# Generate code with own arguments properly quoted
|
||||
|
||||
\-\-\-- dataentry snipplet \-\-\-- snipplet_tags: arguments, quoting,
|
||||
---- dataentry snipplet ---- snipplet_tags: arguments, quoting,
|
||||
escaping, wrapper LastUpdate_dt: 2010-07-31 Contributors: Jan Schampera
|
||||
type: snipplet
|
||||
|
||||
|
@ -1,6 +1,6 @@
|
||||
# X-Clipboard on Commandline
|
||||
|
||||
\-\-\-- dataentry snipplet \-\-\-- snipplet_tags: clipboard, x11, xclip,
|
||||
---- dataentry snipplet ---- snipplet_tags: clipboard, x11, xclip,
|
||||
readline LastUpdate_dt: 2010-07-31 Contributors: Josh Triplett type:
|
||||
snipplet
|
||||
|
||||
@ -31,4 +31,4 @@ The behaviour is a bit tricky to explain:
|
||||
Of course you can use any other command, you\'re not limited to `xclip`
|
||||
here.
|
||||
|
||||
Note: C-@ as well as M-SPC both works and set the mark for me \-- pgas
|
||||
Note: C-@ as well as M-SPC both works and set the mark for me -- pgas
|
||||
|
@ -64,7 +64,7 @@ When no base is specified, the base 10 (decimal) is assumed, except when
|
||||
the prefixes as mentioned above (octals, hexadecimals) are present. The
|
||||
specified base can range from 2 to 64. To represent digits in a
|
||||
specified base greater than 10, characters other than 0 to 9 are needed
|
||||
(in this order, low =\> high):
|
||||
(in this order, low => high):
|
||||
|
||||
- `0 ... 9`
|
||||
- `a ... z`
|
||||
@ -223,7 +223,7 @@ That means, the following `if`-clause will execute the `else`-thread:
|
||||
`-` unary minus
|
||||
|
||||
`<EXPR> ? <EXPR> : <EXPR>` conditional (ternary) operator\
|
||||
\<condition\> ? \<result-if-true\> : \<result-if-false\>
|
||||
<condition> ? <result-if-true> : <result-if-false>
|
||||
|
||||
`<EXPR> , <EXPR>` expression list
|
||||
|
||||
@ -232,7 +232,7 @@ That means, the following `if`-clause will execute the `else`-thread:
|
||||
|
||||
## Precedence
|
||||
|
||||
The operator precedence is as follows (highest -\> lowest):
|
||||
The operator precedence is as follows (highest -> lowest):
|
||||
|
||||
- Postfix (`id++`, `id--`)
|
||||
- Prefix (`++id`, `--id`)
|
||||
@ -292,7 +292,7 @@ else
|
||||
fi
|
||||
```
|
||||
|
||||
\<WRAP center round important\> Beware that `set -e` can change the
|
||||
<WRAP center round important> Beware that `set -e` can change the
|
||||
runtime behavior of scripts. For example,
|
||||
|
||||
This non-equivalence of code behavior deserves some attention. Consider
|
||||
@ -332,7 +332,7 @@ echo $?
|
||||
(\"SUCCESS\")
|
||||
|
||||
This change in code behavior was discovered once the script was run
|
||||
under set -e. \</WRAP\>
|
||||
under set -e. </WRAP>
|
||||
|
||||
## Arithmetic expressions in Bash
|
||||
|
||||
|
@ -131,9 +131,9 @@ As of now, arrays can't be exported.
|
||||
|
||||
### Getting values
|
||||
|
||||
\<note\> For completeness and details on several parameter expansion
|
||||
<note> For completeness and details on several parameter expansion
|
||||
variants, see the [article about parameter expansion](../syntax/pe.md) and
|
||||
check the notes about arrays. \</note\>
|
||||
check the notes about arrays. </note>
|
||||
|
||||
Syntax Description
|
||||
----------------------------------------------------------------------- -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
@ -185,7 +185,7 @@ It is best to [explicitly specify
|
||||
-v](../commands/builtin/unset.md#portability_considerations) when unsetting
|
||||
variables with unset.
|
||||
|
||||
\<note warning\> Specifying unquoted array elements as arguments to any
|
||||
<note warning> Specifying unquoted array elements as arguments to any
|
||||
command, such as with the syntax above **may cause [pathname
|
||||
expansion](../syntax/expansion/globs.md) to occur** due to the presence of
|
||||
glob characters.
|
||||
@ -205,7 +205,7 @@ To avoid this, **always quote** the array name and index:
|
||||
unset -v 'x[1]'
|
||||
|
||||
This applies generally to all commands which take variable names as
|
||||
arguments. Single quotes preferred. \</note\>
|
||||
arguments. Single quotes preferred. </note>
|
||||
|
||||
## Usage
|
||||
|
||||
@ -369,13 +369,13 @@ strings would have been inserted into the integer array without
|
||||
evaluating the arithmetic. A special-case of this is shown in the next
|
||||
section.
|
||||
|
||||
\<note\> Bash declaration commands are really keywords in disguise. They
|
||||
<note> Bash declaration commands are really keywords in disguise. They
|
||||
magically parse arguments to determine whether they are in the form of a
|
||||
valid assignment. If so, they are evaluated as assignments. If not, they
|
||||
are undergo normal argument expansion before being passed to the builtin
|
||||
which evaluates the resulting string as an assignment (somewhat like
|
||||
`eval`, but there are differences.) `'Todo:`\' Discuss this in detail.
|
||||
\</note\>
|
||||
</note>
|
||||
|
||||
### Indirection
|
||||
|
||||
@ -688,5 +688,5 @@ to generate these results.
|
||||
- [BashSheet - Arrays](http://mywiki.wooledge.org/BashSheet#Arrays) -
|
||||
Bashsheet quick-reference on Greycat's wiki.
|
||||
|
||||
\<div hide\> vim: set fenc=utf-8 ff=unix ts=4 sts=4 sw=4 ft=dokuwiki et
|
||||
wrap lbr: \</div\>
|
||||
<div hide> vim: set fenc=utf-8 ff=unix ts=4 sts=4 sw=4 ft=dokuwiki et
|
||||
wrap lbr: </div>
|
||||
|
@ -38,11 +38,11 @@ can catch it and act on it. Exit code range is from 0 to 255, where 0
|
||||
means success, and the rest mean either something failed, or there is an
|
||||
issue to report back to the calling program.
|
||||
|
||||
\<wrap center round info 90%\> The simple command construct is the
|
||||
<wrap center round info 90%> The simple command construct is the
|
||||
**base** for all higher constructs. Everything you execute, from
|
||||
pipelines to functions, finally ends up in (many) simple commands.
|
||||
That's why Bash only has one method to [expand and execute a simple
|
||||
command](../syntax/grammar/parser_exec.md). \</wrap\>
|
||||
command](../syntax/grammar/parser_exec.md). </wrap>
|
||||
|
||||
## Pipelines
|
||||
|
||||
@ -115,7 +115,7 @@ A list is a sequence of one or more [pipelines](../basicgrammar.md#pipelines)
|
||||
separated by one of the operators `;`, `&`, `&&`, or `││`, and
|
||||
optionally terminated by one of `;`, `&`, or `<newline>`.
|
||||
|
||||
=\> It's a group of **pipelines** separated or terminated by **tokens**
|
||||
=> It's a group of **pipelines** separated or terminated by **tokens**
|
||||
that all have **different meanings** for Bash.
|
||||
|
||||
Your whole Bash script technically is one big single list!
|
||||
@ -151,17 +151,17 @@ overview):
|
||||
|
||||
Compound command syntax Description
|
||||
------------------------------------------------------------ ---------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
`( <LIST> )` Execute `<LIST>` in an extra subshell =\> [article](../syntax/ccmd/grouping_subshell.md)
|
||||
`{ <LIST> ; }` Execute `<LIST>` as separate group (but not in a subshell) =\> [article](../syntax/ccmd/grouping_plain.md)
|
||||
`(( <EXPRESSION> ))` Evaluate the arithmetic expression `<EXPRESSION>` =\> [article](../syntax/ccmd/arithmetic_eval.md)
|
||||
`[[ <EXPRESSION> ]]` Evaluate the conditional expression `<EXPRESSION>` (aka \"the new test command\") =\> [article](../syntax/ccmd/conditional_expression.md)
|
||||
`for <NAME> in <WORDS> ; do <LIST> ; done` Executes `<LIST>` while setting the variable `<NAME>` to one of `<WORDS>` on every iteration (classic for-loop) =\> [article](../syntax/ccmd/classic_for.md)
|
||||
`for (( <EXPR1> ; <EXPR2> ; <EXPR3> )) ; do <LIST> ; done` C-style for-loop (driven by arithmetic expressions) =\> [article](../syntax/ccmd/c_for.md)
|
||||
`select <NAME> in <WORDS> ; do <LIST> ; done` Provides simple menus =\> [article](../syntax/ccmd/user_select.md)
|
||||
`case <WORD> in <PATTERN>) <LIST> ;; ... esac` Decisions based on pattern matching - executing `<LIST>` on match =\> [article](../syntax/ccmd/case.md)
|
||||
`if <LIST> ; then <LIST> ; else <LIST> ; fi` The if clause: makes decisions based on exit codes =\> [article](../syntax/ccmd/if_clause.md)
|
||||
`while <LIST1> ; do <LIST2> ; done` Execute `<LIST2>` while `<LIST1>` returns TRUE (exit code) =\> [article](../syntax/ccmd/while_loop.md)
|
||||
`until <LIST1> ; do <LIST2> ; done` Execute `<LIST2>` until `<LIST1>` returns TRUE (exit code) =\> [article](../syntax/ccmd/until_loop.md)
|
||||
`( <LIST> )` Execute `<LIST>` in an extra subshell => [article](../syntax/ccmd/grouping_subshell.md)
|
||||
`{ <LIST> ; }` Execute `<LIST>` as separate group (but not in a subshell) => [article](../syntax/ccmd/grouping_plain.md)
|
||||
`(( <EXPRESSION> ))` Evaluate the arithmetic expression `<EXPRESSION>` => [article](../syntax/ccmd/arithmetic_eval.md)
|
||||
`[[ <EXPRESSION> ]]` Evaluate the conditional expression `<EXPRESSION>` (aka \"the new test command\") => [article](../syntax/ccmd/conditional_expression.md)
|
||||
`for <NAME> in <WORDS> ; do <LIST> ; done` Executes `<LIST>` while setting the variable `<NAME>` to one of `<WORDS>` on every iteration (classic for-loop) => [article](../syntax/ccmd/classic_for.md)
|
||||
`for (( <EXPR1> ; <EXPR2> ; <EXPR3> )) ; do <LIST> ; done` C-style for-loop (driven by arithmetic expressions) => [article](../syntax/ccmd/c_for.md)
|
||||
`select <NAME> in <WORDS> ; do <LIST> ; done` Provides simple menus => [article](../syntax/ccmd/user_select.md)
|
||||
`case <WORD> in <PATTERN>) <LIST> ;; ... esac` Decisions based on pattern matching - executing `<LIST>` on match => [article](../syntax/ccmd/case.md)
|
||||
`if <LIST> ; then <LIST> ; else <LIST> ; fi` The if clause: makes decisions based on exit codes => [article](../syntax/ccmd/if_clause.md)
|
||||
`while <LIST1> ; do <LIST2> ; done` Execute `<LIST2>` while `<LIST1>` returns TRUE (exit code) => [article](../syntax/ccmd/while_loop.md)
|
||||
`until <LIST1> ; do <LIST2> ; done` Execute `<LIST2>` until `<LIST1>` returns TRUE (exit code) => [article](../syntax/ccmd/until_loop.md)
|
||||
|
||||
## Shell Function Definitions
|
||||
|
||||
|
@ -96,15 +96,15 @@ The return status is that of the last command executed from `<LIST>`, or
|
||||
|
||||
## Alternatives and best practice
|
||||
|
||||
\<div center round todo 60%\>TODO: Show some alternate usages involving
|
||||
functions and local variables for initialization.\</div\>
|
||||
<div center round todo 60%>TODO: Show some alternate usages involving
|
||||
functions and local variables for initialization.</div>
|
||||
|
||||
## Examples
|
||||
|
||||
### Simple counter
|
||||
|
||||
A simple counter, the loop iterates 101 times (\"0\" to \"100\" are 101
|
||||
numbers -\> 101 runs!), and everytime the variable `x` is set to the
|
||||
numbers -> 101 runs!), and everytime the variable `x` is set to the
|
||||
current value.
|
||||
|
||||
- It **initializes** `x = 0`
|
||||
@ -132,7 +132,7 @@ will count from 0 to 100, but with a **step of 10**.
|
||||
|
||||
This example loops through the bit-values of a Byte, beginning from 128,
|
||||
ending at 1. If that bit is set in the `testbyte`, it prints \"`1`\",
|
||||
else \"`0`\" =\> it prints the binary representation of the `testbyte`
|
||||
else \"`0`\" => it prints the binary representation of the `testbyte`
|
||||
value (8 bits).
|
||||
|
||||
#!/usr/bin/env bash
|
||||
@ -161,7 +161,7 @@ value (8 bits).
|
||||
|
||||
# vim: set fenc=utf-8 ff=unix ft=sh :
|
||||
|
||||
\<div hide\>
|
||||
<div hide>
|
||||
|
||||
testbyte=123
|
||||
for (( n = 128 ; n >= 1 ; n /= 2 )); do
|
||||
@ -173,7 +173,7 @@ value (8 bits).
|
||||
done
|
||||
echo
|
||||
|
||||
\</div\>
|
||||
</div>
|
||||
|
||||
Why that one begins at 128 (highest value, on the left) and not 1
|
||||
(lowest value, on the right)? It's easier to print from left to
|
||||
@ -196,7 +196,7 @@ variables.
|
||||
printf '%*s\n' "$((n+1))" "$n"
|
||||
done
|
||||
|
||||
\<code\> \~ \$ bash \<(xclip -o) 1
|
||||
<code> \~ \$ bash <(xclip -o) 1
|
||||
|
||||
2
|
||||
3
|
||||
@ -216,7 +216,7 @@ variables.
|
||||
3
|
||||
2
|
||||
|
||||
1 \</code\>
|
||||
1 </code>
|
||||
|
||||
## Portability considerations
|
||||
|
||||
|
@ -52,7 +52,7 @@ When the operators `<` and `>` are used (string collation order), the
|
||||
test happens using the current locale when the `compat` level is greater
|
||||
than \"40\".
|
||||
|
||||
Operator precedence (highest =\> lowest):
|
||||
Operator precedence (highest => lowest):
|
||||
|
||||
- `( <EXPRESSION> )`
|
||||
- `! <EXPRESSION>`
|
||||
@ -151,7 +151,7 @@ Example:
|
||||
|
||||
### Behaviour differences compared to the builtin test command
|
||||
|
||||
As of Bash 4.1 alpha, the test primaries \'\<\' and \'\>\' (compare
|
||||
As of Bash 4.1 alpha, the test primaries \'<\' and \'>\' (compare
|
||||
strings lexicographically) use the current locale settings, while the
|
||||
same primitives for the builtin test command don't. This leads to the
|
||||
following situation where they behave differently:
|
||||
@ -159,8 +159,8 @@ following situation where they behave differently:
|
||||
$ ./cond.sh
|
||||
[[ ' 4' < '1' ]] --> exit 1
|
||||
[[ 'step+' < 'step-' ]] --> exit 1
|
||||
[ ' 4' \< '1' ] --> exit 0
|
||||
[ 'step+' \< 'step-' ] --> exit 0
|
||||
[ ' 4' < '1' ] --> exit 0
|
||||
[ 'step+' < 'step-' ] --> exit 0
|
||||
|
||||
It won't be aligned. The conditional expression continues to respect
|
||||
the locate, as introduced with 4.1-alpha, the builtin `test`/`[` command
|
||||
|
@ -64,8 +64,8 @@ the only compound command that's valid there:
|
||||
without extra separator (also in some other shells), **example**:
|
||||
`{ while sleep 1; do echo ZzZzzZ; done }` is valid. But this is not
|
||||
documented, infact the documentation explicitly says that a
|
||||
semicolon or a newline must separate the enclosed list. \-- thanks
|
||||
semicolon or a newline must separate the enclosed list. -- thanks
|
||||
`geirha` at Freenode
|
||||
|
||||
[^2]: The main reason is the fact that in shell grammar, the curly
|
||||
braces are not control operators but reserved words \-- TheBonsai
|
||||
braces are not control operators but reserved words -- TheBonsai
|
||||
|
@ -209,7 +209,7 @@ Can be written as
|
||||
|
||||
\...which is a kind of a hack, but hey, it works.
|
||||
|
||||
\<div round info\>
|
||||
<div round info>
|
||||
|
||||
#### More fun
|
||||
|
||||
@ -234,7 +234,7 @@ In this case, the output is:
|
||||
|
||||
eval printf "$arg"{,,}{,,}{,,}{,,}{,,}{,,}{,,,,,}{,,,,,}{,,,,,}{,,,,,}{,,,,,}{,,,,,}
|
||||
|
||||
\</div\>
|
||||
</div>
|
||||
|
||||
## New in Bash 4.0
|
||||
|
||||
|
@ -30,7 +30,7 @@ from a file).
|
||||
|
||||
### Scope
|
||||
|
||||
\<note important\> Note: According to multiple comments and sources, the
|
||||
<note important> Note: According to multiple comments and sources, the
|
||||
scope of process substitution file descriptors is **not** stable,
|
||||
guaranteed, or specified by bash. Newer versions of bash (5.0+) seem to
|
||||
have shorter scope, and substitutions scope seems to be shorter than
|
||||
@ -39,7 +39,7 @@ function scope. See
|
||||
and
|
||||
[stackoverflow](https://stackoverflow.com/questions/46660020/bash-what-is-the-scope-of-the-process-substitution);
|
||||
the latter discussion contains a script that can test the scoping
|
||||
behavior case-by-case \</note\>
|
||||
behavior case-by-case </note>
|
||||
|
||||
If a process substitution is expanded as an argument to a function,
|
||||
expanded to an environment variable during calling of a function, or
|
||||
@ -74,7 +74,7 @@ diff <(ls "$first_directory") <(ls "$second_directory")
|
||||
```
|
||||
|
||||
This will compare the contents of each directory. In this command, each
|
||||
*process* is *substituted* for a *file*, and diff doesn't see \<(bla),
|
||||
*process* is *substituted* for a *file*, and diff doesn't see <(bla),
|
||||
it sees two files, so the effective command is something like
|
||||
|
||||
``` bash
|
||||
@ -85,10 +85,10 @@ where those files are written to and destroyed automatically.
|
||||
|
||||
### Avoiding subshells
|
||||
|
||||
\<WRAP center round info 60%\> See Also:
|
||||
[BashFAQ/024](http://mywiki.wooledge.org/BashFAQ/024) \-- *I set
|
||||
<WRAP center round info 60%> See Also:
|
||||
[BashFAQ/024](http://mywiki.wooledge.org/BashFAQ/024) -- *I set
|
||||
variables in a loop that's in a pipeline. Why do they disappear after
|
||||
the loop terminates? Or, why can't I pipe data to read?* \</WRAP\>
|
||||
the loop terminates? Or, why can't I pipe data to read?* </WRAP>
|
||||
|
||||
One of the most common uses for process substitutions is to avoid the
|
||||
final subshell that results from executing a pipeline. The following is
|
||||
|
@ -33,13 +33,13 @@ Tilde expansion is also performed everytime a variable is assigned:
|
||||
- after **every** `:` (colon) in the assigned value:
|
||||
`TARGET=file:~moonman/share`
|
||||
|
||||
\<note info\> As of now (Bash 4.3-alpha) the following constructs
|
||||
<note info> As of now (Bash 4.3-alpha) the following constructs
|
||||
**also** works, though it's not a variable assignment:
|
||||
|
||||
echo foo=~
|
||||
echo foo=:~
|
||||
|
||||
I don't know yet, if this is a bug or intended. \</note\>
|
||||
I don't know yet, if this is a bug or intended. </note>
|
||||
|
||||
This way you can correctly use the tilde expansion in your
|
||||
[PATH](../../syntax/shellvars.md#PATH):
|
||||
|
@ -18,9 +18,9 @@ are **not double-quoted**!
|
||||
The `IFS` variable holds the characters that Bash sees as word
|
||||
boundaries in this step. The default contains the characters
|
||||
|
||||
- \<space\>
|
||||
- \<tab\>
|
||||
- \<newline\>
|
||||
- <space>
|
||||
- <tab>
|
||||
- <newline>
|
||||
|
||||
These characters are also assumed when IFS is **unset**. When `IFS` is
|
||||
**empty** (nullstring), no word splitting is performed at all.
|
||||
@ -34,7 +34,7 @@ the expansion result is split at these positions into multiple words.
|
||||
This doesn't happen when the expansion results were **double-quoted**.
|
||||
|
||||
When a null-string (e.g., something that before expanded to
|
||||
\>\>nothing\<\<) is found, it is removed, unless it is quoted (`''` or
|
||||
>>nothing<<) is found, it is removed, unless it is quoted (`''` or
|
||||
`""`).
|
||||
|
||||
[**Again note:**]{.underline} Without any expansion beforehand, Bash
|
||||
|
@ -10,12 +10,12 @@ evaluate and execute is the simple command.
|
||||
|
||||
## Simple command expansion
|
||||
|
||||
\<div center round info 60%\>
|
||||
<div center round info 60%>
|
||||
|
||||
- <http://lists.gnu.org/archive/html/bug-bash/2013-01/msg00040.html>
|
||||
- <http://lists.research.att.com/pipermail/ast-developers/2013q2/002456.html>
|
||||
|
||||
\</div\>
|
||||
</div>
|
||||
|
||||
This step happens after the initial command line splitting.
|
||||
|
||||
@ -69,8 +69,8 @@ Otherwise, if a command name results:
|
||||
entire script to terminate*
|
||||
|
||||
The behavior regarding the variable assignment errors can be tested:
|
||||
\<div center round info
|
||||
60%\><http://lists.gnu.org/archive/html/bug-bash/2013-01/msg00054.html>\</div\>
|
||||
<div center round info
|
||||
60%><http://lists.gnu.org/archive/html/bug-bash/2013-01/msg00054.html></div>
|
||||
|
||||
**[This one exits the script completely]{.underline}**
|
||||
|
||||
|
@ -227,7 +227,7 @@ which all do approximately the same thing. ksh93 and mksh have virtually
|
||||
identical syntax and semantics for coprocs. A *list* operator: `|&` is
|
||||
added to the language which runs the preceding *pipeline* as a coprocess
|
||||
(This is another reason not to use the special `|&` pipe operator in
|
||||
Bash \-- its syntax is conflicting). The `-p` option to the `read` and
|
||||
Bash -- its syntax is conflicting). The `-p` option to the `read` and
|
||||
`print` builtins can then be used to read and write to the pipe of the
|
||||
coprocess (whose FD isn't yet known). Special redirects are added to
|
||||
move the last spawned coprocess to a different FD: `<&p` and `>&p`, at
|
||||
@ -261,7 +261,7 @@ The ability to use multiple coprocesses in Bash is considered
|
||||
\"experimental\". Bash will throw an error if you attempt to start more
|
||||
than one. This may be overridden at compile-time with the
|
||||
`MULTIPLE_COPROCS` option. However, at this time there are still issues
|
||||
\-- see the above mailing list discussion.
|
||||
-- see the above mailing list discussion.
|
||||
|
||||
## See also
|
||||
|
||||
|
@ -55,23 +55,23 @@ Some simple examples using normal pattern matching:
|
||||
- Pattern `"Hello world"` matches
|
||||
- `Hello world`
|
||||
- Pattern `[Hh]"ello world"` matches
|
||||
- =\> `Hello world`
|
||||
- =\> `hello world`
|
||||
- => `Hello world`
|
||||
- => `hello world`
|
||||
- Pattern `Hello*` matches (for example)
|
||||
- =\> `Hello world`
|
||||
- =\> `Helloworld`
|
||||
- =\> `HelloWoRlD`
|
||||
- =\> `Hello`
|
||||
- => `Hello world`
|
||||
- => `Helloworld`
|
||||
- => `HelloWoRlD`
|
||||
- => `Hello`
|
||||
- Pattern `Hello world[[:punct:]]` matches (for example)
|
||||
- =\> `Hello world!`
|
||||
- =\> `Hello world.`
|
||||
- =\> `Hello world+`
|
||||
- =\> `Hello world?`
|
||||
- => `Hello world!`
|
||||
- => `Hello world.`
|
||||
- => `Hello world+`
|
||||
- => `Hello world?`
|
||||
- Pattern
|
||||
`[[.backslash.]]Hello[[.vertical-line.]]world[[.exclamation-mark.]]`
|
||||
matches (using [collation
|
||||
symbols](https://pubs.opengroup.org/onlinepubs/009696899/basedefs/xbd_chap07.html#tag_07_03_02_04))
|
||||
- =\> `\Hello|world!`
|
||||
- => `\Hello|world!`
|
||||
|
||||
## Extended pattern language
|
||||
|
||||
|
@ -208,14 +208,14 @@ The `^` operator modifies the first character to uppercase, the `,`
|
||||
operator to lowercase. When using the double-form (`^^` and `,,`), all
|
||||
characters are converted.
|
||||
|
||||
\<wrap center round info 60%\>
|
||||
<wrap center round info 60%>
|
||||
|
||||
The (**currently undocumented**) operators `~` and `~~` reverse the case
|
||||
of the given text (in `PARAMETER`).`~` reverses the case of first letter
|
||||
of words in the variable while `~~` reverses case for all. Thanks to
|
||||
`Bushmills` and `geirha` on the Freenode IRC channel for this finding.
|
||||
|
||||
\</wrap\>
|
||||
</wrap>
|
||||
|
||||
[**Example: Rename all `*.txt` filenames to lowercase**]{.underline}
|
||||
|
||||
@ -245,13 +245,13 @@ examples:
|
||||
Assume: `array=(This is some Text)`
|
||||
|
||||
- `echo "${array[@],}"`
|
||||
- =\> `this is some text`
|
||||
- => `this is some text`
|
||||
- `echo "${array[@],,}"`
|
||||
- =\> `this is some text`
|
||||
- => `this is some text`
|
||||
- `echo "${array[@]^}"`
|
||||
- =\> `This Is Some Text`
|
||||
- => `This Is Some Text`
|
||||
- `echo "${array[@]^^}"`
|
||||
- =\> `THIS IS SOME TEXT`
|
||||
- => `THIS IS SOME TEXT`
|
||||
|
||||
```{=html}
|
||||
<!-- -->
|
||||
@ -267,7 +267,7 @@ Assume: `array=(This is some Text)`
|
||||
|
||||
This expands to a list of all set **variable names** beginning with the
|
||||
string `PREFIX`. The elements of the list are separated by the first
|
||||
character in the `IFS`-variable (\<space\> by default).
|
||||
character in the `IFS`-variable (<space> by default).
|
||||
|
||||
This will show all defined variable names (not values!) beginning with
|
||||
\"BASH\":
|
||||
@ -336,16 +336,16 @@ filename**. Just look at the following list with examples:
|
||||
|
||||
- **Get name without extension**
|
||||
- `${FILENAME%.*}`
|
||||
- =\> `bash_hackers.txt`
|
||||
- => `bash_hackers.txt`
|
||||
- **Get extension**
|
||||
- `${FILENAME##*.}`
|
||||
- =\> `bash_hackers.txt`
|
||||
- => `bash_hackers.txt`
|
||||
- **Get directory name**
|
||||
- `${PATHNAME%/*}`
|
||||
- =\> `/home/bash/bash_hackers.txt`
|
||||
- => `/home/bash/bash_hackers.txt`
|
||||
- **Get filename**
|
||||
- `${PATHNAME##*/}`
|
||||
- =\> `/home/bash/bash_hackers.txt`
|
||||
- => `/home/bash/bash_hackers.txt`
|
||||
|
||||
These are the syntaxes for filenames with a single extension. Depending
|
||||
on your needs, you might need to adjust shortest/longest match.
|
||||
@ -362,7 +362,7 @@ expansion):
|
||||
Assume: `array=(This is a text)`
|
||||
|
||||
- `echo "${array[@]%is}"`
|
||||
- =\> `Th a text`
|
||||
- => `Th a text`
|
||||
- (it was: `This is a text`)
|
||||
|
||||
All other variants of this expansion behave the same.
|
||||
@ -397,7 +397,7 @@ example string:
|
||||
|
||||
${MYSTRING//conservative/happy}
|
||||
|
||||
=\>
|
||||
=>
|
||||
`Be liberal in what you accept, and conservativehappy in what you send`
|
||||
|
||||
Since there is only one \"conservative\" in that example, it really
|
||||
@ -410,13 +410,13 @@ but let's substitute it with \"by\".
|
||||
|
||||
${MYSTRING/in/by}
|
||||
|
||||
=\> `Be liberal inby what you accept, and conservative in what you send`
|
||||
=> `Be liberal inby what you accept, and conservative in what you send`
|
||||
|
||||
[**Second form: Substitute all occurrences**]{.underline}
|
||||
|
||||
${MYSTRING//in/by}
|
||||
|
||||
=\>
|
||||
=>
|
||||
`Be liberal inby what you accept, and conservative inby what you send`
|
||||
|
||||
[**Anchoring**]{.underline} Additionally you can \"anchor\" an
|
||||
@ -447,9 +447,9 @@ A simple example, changing the (lowercase) letter `t` to `d`:
|
||||
Assume: `array=(This is a text)`
|
||||
|
||||
- `echo "${array[@]/t/d}"`
|
||||
- =\> `This is a dext`
|
||||
- => `This is a dext`
|
||||
- `echo "${array[@]//t/d}"`
|
||||
- =\> `This is a dexd`
|
||||
- => `This is a dexd`
|
||||
|
||||
## String length
|
||||
|
||||
@ -462,7 +462,7 @@ expanded. Again, a quote from a big man, to have a test text:
|
||||
|
||||
Using echo `${#MYSTRING}`\...
|
||||
|
||||
=\> `64`
|
||||
=> `64`
|
||||
|
||||
The length is reported in characters, not in bytes. Depending on your
|
||||
environment this may not always be the same (multibyte-characters, like
|
||||
@ -484,9 +484,9 @@ Example:
|
||||
Assume: `array=(This is a text)`
|
||||
|
||||
- `echo ${#array[1]}`
|
||||
- =\> 2 (the word \"is\" has a length of 2)
|
||||
- => 2 (the word \"is\" has a length of 2)
|
||||
- `echo ${#array[@]}`
|
||||
- =\> 4 (the array contains 4 elements)
|
||||
- => 4 (the array contains 4 elements)
|
||||
|
||||
[**Attention:**]{.underline} The number of used elements does not need
|
||||
to conform to the highest index. Sparse arrays are possible in Bash,
|
||||
@ -520,7 +520,7 @@ that the offset 0 is the first character:
|
||||
|
||||
echo ${MYSTRING:35}
|
||||
|
||||
=\>
|
||||
=>
|
||||
`<del>Be liberal in what you accept, and </del>conservative in what you send`
|
||||
|
||||
### Using Offset and Length
|
||||
@ -529,7 +529,7 @@ In the second form we also give a length value:
|
||||
|
||||
echo ${MYSTRING:35:12}
|
||||
|
||||
=\>
|
||||
=>
|
||||
`<del>Be liberal in what you accept, and </del>conservative<del> in what you send</del>`
|
||||
|
||||
### Negative Offset Value
|
||||
@ -554,7 +554,7 @@ then:
|
||||
|
||||
echo "${MYSTRING:11:-17}"
|
||||
|
||||
=\>
|
||||
=>
|
||||
`<del>Be liberal </del>in what you accept, and conservative<del> in what you send</del>`
|
||||
|
||||
This works since Bash 4.2-alpha, see also
|
||||
@ -575,9 +575,9 @@ Example:
|
||||
Assume: `array=(This is a text)`
|
||||
|
||||
- `echo ${array[0]:2:2}`
|
||||
- =\> `is` (the \"is\" in \"This\", array element 0)
|
||||
- => `is` (the \"is\" in \"This\", array element 0)
|
||||
- `echo ${array[@]:1:2}`
|
||||
- =\> `is a` (from element 1 inclusive, 2 elements are expanded,
|
||||
- => `is a` (from element 1 inclusive, 2 elements are expanded,
|
||||
i.e. element 1 and 2)
|
||||
|
||||
## Use a default value
|
||||
|
@ -48,7 +48,7 @@ backslash:
|
||||
- The backslash changes the quotes into literals - otherwise Bash
|
||||
would interpret them
|
||||
|
||||
The sequence `\<newline>` (an unquoted backslash, followed by a
|
||||
The sequence `<newline>` (an unquoted backslash, followed by a
|
||||
`<newline>` character) is interpreted as **line continuation**. It is
|
||||
removed from the input stream and thus effectively ignored. Use it to
|
||||
beautify your code:
|
||||
|
@ -1,6 +1,6 @@
|
||||
# Redirection
|
||||
|
||||
\<wrap left todo\>Fix me: To be continued\</wrap\>\
|
||||
<wrap left todo>Fix me: To be continued</wrap>\
|
||||
Redirection makes it possible to control where the output of a command
|
||||
goes to, and where the input of a command comes from. It's a mighty
|
||||
tool that, together with pipelines, makes the shell powerful. The
|
||||
@ -16,9 +16,9 @@ file descriptors 0, 1 and 2, all connected to your terminal:
|
||||
`stdout` 1 standard output stream (e.g. monitor)
|
||||
`stderr` 2 standard error output stream (usually also on monitor)
|
||||
|
||||
\<wrap center info\>The terms \"monitor\" and \"keyboard\" refer to the
|
||||
<wrap center info>The terms \"monitor\" and \"keyboard\" refer to the
|
||||
same device, the **terminal** here. Check your preferred UNIX(r)-FAQ for
|
||||
details, I\'m too lazy to explain what a terminal is ;-) \</wrap\>
|
||||
details, I\'m too lazy to explain what a terminal is ;-) </wrap>
|
||||
|
||||
Both, `stdout` and `stderr` are output file descriptors. Their
|
||||
difference is the **convention** that a program outputs payload on
|
||||
@ -45,9 +45,9 @@ these examples are equivalent:
|
||||
cat >new.txt foo.txt bar.txt
|
||||
>new.txt cat foo.txt bar.txt
|
||||
|
||||
\<wrap center important\>Every redirection operator takes one or two
|
||||
<wrap center important>Every redirection operator takes one or two
|
||||
words as operands. If you have to use operands (e.g. filenames to
|
||||
redirect to) that contain spaces you **must** quote them!\</wrap\>
|
||||
redirect to) that contain spaces you **must** quote them!</wrap>
|
||||
|
||||
## Valid redirection targets and sources
|
||||
|
||||
@ -106,9 +106,9 @@ specified target. It's **equivalent** to
|
||||
Since Bash4, there's `&>>TARGET`, which is equivalent to
|
||||
`>> TARGET 2>&1`.
|
||||
|
||||
\<wrap center important\>This syntax is deprecated and should not be
|
||||
<wrap center important>This syntax is deprecated and should not be
|
||||
used. See the page about [obsolete and deprecated
|
||||
syntax](../scripting/obsolete.md).\</wrap\>
|
||||
syntax](../scripting/obsolete.md).</wrap>
|
||||
|
||||
## Appending redirected output and error output
|
||||
|
||||
@ -134,7 +134,7 @@ omitted, filedescriptor 0 (`stdin`) is assumed.
|
||||
|
||||
## Here documents
|
||||
|
||||
\<BOOKMARK:tag_heredoc\>
|
||||
<BOOKMARK:tag_heredoc>
|
||||
|
||||
<<TAG
|
||||
...
|
||||
@ -178,11 +178,11 @@ here-documents.
|
||||
The tag you use **must** be the only word in the line, to be recognized
|
||||
as end-of-here-document marker.
|
||||
|
||||
\<wrap center info\>It seems that here-documents (tested on versions
|
||||
<wrap center info>It seems that here-documents (tested on versions
|
||||
`1.14.7`, `2.05b` and `3.1.17`) are correctly terminated when there is
|
||||
an EOF before the end-of-here-document tag. The reason is unknown, but
|
||||
it seems to be done on purpose. Bash 4 introduced a warning message when
|
||||
end-of-file is seen before the tag is reached.\</wrap\>
|
||||
end-of-file is seen before the tag is reached.</wrap>
|
||||
|
||||
## Here strings
|
||||
|
||||
|
@ -1273,7 +1273,7 @@ Prompt](https://www.gnu.org/software/bash/manual/bash.html#Controlling-the-Promp
|
||||
Variable: `PS2` Since: unknown
|
||||
-------------- ----------------- ------------ -----------------
|
||||
Type: normal variable Read-only: no
|
||||
Set by Bash: if unset Default: \"\'\'\> \'\'\"
|
||||
Set by Bash: if unset Default: \"\'\'> \'\'\"
|
||||
|
||||
The value of this parameter is expanded as with PS1 and used as the
|
||||
secondary prompt string.
|
||||
|
Loading…
Reference in New Issue
Block a user