hyperreal/bash-hackers-wiki
1
0
Fork 0
mirror of https://github.com/flokoe/bash-hackers-wiki.git synced 2024-11-01 06:53:05 +01:00
Code Issues Actions Packages Projects Releases Wiki Activity

Fix Markdown formatting for classictest.md

Browse Source
This commit is contained in:
flokoe 2023-07-04 18:11:00 +02:00
parent 505673ba61
commit f79b5314b2
2 changed files with 367 additions and 397 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

387
docs/commands/classictest.md
View File

@ -6,51 +6,46 @@
## General syntax
This command allows you to do various tests and sets its exit code to 0
(*TRUE*) or 1 (*FALSE*) whenever such a test succeeds or not. Using this
exit code, it\'s possible to let Bash react on the result of such a
test, here by using the command in an if-statement:
This command allows you to do various tests and sets its exit code to 0 (`true`) or 1 (`false`) whenever such a test succeeds or not.
Using this exit code, it's possible to let Bash react on the result of such a test, here by using the command in an if-statement:
```bash
#!/bin/bash
# test if /etc/passwd exists
# test if /etc/passwd exists
if test -e /etc/passwd; then
echo "Alright man..." >&2
else
echo "Yuck! Where is it??" >&2
exit 1
fi
```
The syntax of the test command is relatively easy. Usually it\'s the
command name \"`test`\" followed by a test type (here \"`-e`\" for
\"file exists\") followed by test-type-specific values (here the
filename to check, \"`/etc/passwd`\").
The syntax of the test command is relatively easy.
Usually it's the command name `test` followed by a test type (here `-e` for "file exists") followed by test-type-specific values (here the filename to check, `/etc/passwd`).
There\'s a second standardized command that does exactly the same: the
command \"`[`\" - the difference just is that it\'s called \"`[`\" and
the last argument to the command must be a \"`]`\": It forms
\"`[ <EXPRESSION> ]`\"
There's a second standardized command that does exactly the same: the command `[` – the difference just is that it's called `[` and the last argument to the command must be a `]`: It forms `[ <EXPRESSION> ]`.
Let\'s rewrite the above example to use it:
Let's rewrite the above example to use it:
```bash
#!/bin/bash
# test if /etc/passwd exists
# test if /etc/passwd exists
if [ -e /etc/passwd ]; then
echo "Alright man..." >&2
else
echo "Yuck! Where is it??" >&2
exit 1
fi
```
One might **think** now that these \"\[\" and \"\]\" belong to the
syntax of Bash\'s if-clause: **No they don\'t! It\'s a simple, ordinary
command, still!**
One might **think** now that these `[` and `]` belong to the syntax of Bash's if-clause: **No they don't! It's a simple, ordinary command, still!**
Another thing you have to remember is that if the test command wants one
parameter for a test, you have to give it one parameter. Let\'s check
for some of your music files:
Another thing you have to remember is that if the test command wants one parameter for a test, you have to give it one parameter.
Let's check for some of your music files:
```bash
#!/bin/bash
mymusic="/data/music/Van Halen/Van Halen - Right Now.mp3"
@ -61,306 +56,276 @@ for some of your music files:
echo "No music today, sorry..." >&2
exit 1
fi
```
As you definitely noted, the filename contains spaces. Since we call a
normal ordinary command (\"test\" or \"\[\") the shell will word-split
the expansion of the variable `mymusic`: You need to quote it when you
don\'t want the `test`-command to complain about too many arguments for
this test-type! If you didn\'t understand it, please read the [article
about words\...](/syntax/words)
As you definitely noted, the filename contains spaces.
Since we call a normal ordinary command (`test` or `[`) the shell will word-split the expansion of the variable `mymusic`:
You need to quote it when you don't want the `test`-command to complain about too many arguments for this test-type!
If you didn't understand it, please read the [article about words\...](/syntax/words).
Please also note that the file-tests want **one filename** to test.
Don\'t give a glob (filename-wildcards) as it can expand to many
filenames =\> **too many arguments!**
Don't give a glob (filename-wildcards) as it can expand to many filenames => **too many arguments!**
[**Another common mistake**]{.underline} is to provide too **few**
arguments:
**Another common mistake** is to provide too **few** arguments:
```bash
[ "$mystring"!="test" ]
```
This provides exactly **one** test-argument to the command. With one
parameter, it defaults to the `-n` test: It tests if a provided string
is empty (`FALSE`) or not (`TRUE`) - due to the lack of **spaces to
separate the arguments** the shown command always ends `TRUE`!
This provides exactly **one** test-argument to the command.
With one parameter, it defaults to the `-n` test:
It tests if a provided string is empty (`FALSE`) or not (`TRUE`) - due to the lack of **spaces to separate the arguments** the shown command always ends `TRUE`!
Well, I addressed several basic rules, now let\'s see what the
test-command can do for you. The Bash test-types can be split into
several sections: **file tests**, **string tests**, **arithmetic
tests**, **misc tests**. Below, the tests marked with :!: are
non-standard tests (i.e. not in SUS/POSIX/etc..).
Well, I addressed several basic rules, now let's see what the test-command can do for you.
The Bash test-types can be split into several sections: **file tests**, **string tests**, **arithmetic tests**, **misc tests**.
Below, the tests marked with :warning: are non-standard tests (i.e. not in SUS/POSIX/etc..).
## File tests
This section probably holds the most tests, I\'ll list them in some
logical order. Since Bash 4.1, all tests related to permissions respect
ACLs, if the underlying filesystem/OS supports them.
This section probably holds the most tests, I'll list them in some logical order.
Since Bash 4.1, all tests related to permissions respect ACLs, if the underlying filesystem/OS supports them.
Operator syntax Description
----------------------------- -------------------------------------------------------------------------------------------- --
**-a** \<FILE\> True if \<FILE\> exists. :!: (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). :!:
\<FILE1\> **-ot** \<FILE2\> True, if \<FILE1\> is **older than** \<FILE2\> (mtime). :!:
\<FILE1\> **-ef** \<FILE2\> True, if \<FILE1\> and \<FILE2\> refer to the **same device and inode numbers**. :!:
| 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: |
## 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 `\>`
| 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 `\>` |
## 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.
| 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. |
## 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) \<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)
| 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) <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
The `test` builtin, especially hidden under its `[` name, may seem
simple but is in fact **causing a lot of trouble sometimes**. One of the
difficulty is that the behaviour of `test` not only depends on its
arguments but also on the **number of its arguments**.
The `test` builtin, especially hidden under its `[` name, may seem simple but is in fact **causing a lot of trouble sometimes**.
One of the difficulty is that the behaviour of `test` not only depends on its arguments but also on the **number of its arguments**.
Here are the rules taken from the manual ([**Note:**]{.underline} This
is for the command `test`, for `[` the number of arguments is calculated
without the final `]`, for example `[ ]` follows the \"zero arguments\"
rule):
Here are the rules taken from the manual:
!!! note
This is for the command `test`, for `[` the number of arguments is calculated without the final `]`, for example `[ ]` follows the "zero arguments" rule.
- **0 arguments**
- The expression is false.
- **1 argument**
- The expression is true if, and only if, the argument is not null
- **2 arguments**
- If the first argument is `!` (exclamation mark), the expression
is true if, and only if, the second argument is null
- If the first argument is one of the unary conditional operators
listed above under the syntax rules, the expression is true if
the unary test is true
- If the first argument is not a valid unary conditional operator,
the expression is false
- If the first argument is `!` (exclamation mark), the expression is true if, and only if, the second argument is null
- If the first argument is one of the unary conditional operators listed above under the syntax rules, the expression is true if the unary test is true
- If the first argument is not a valid unary conditional operator, the expression is false
- **3 arguments**
- If the second argument is one of the binary conditional
operators listed above under the syntax rules, the result of the
expression is the result of the binary test using the first and
third arguments as operands
- If the first argument is `!`, the value is the negation of the
two-argument test using the second and third arguments
- If the first argument is exactly `(` and the third argument is
exactly `)`, the result is the one-argument test of the second
argument. Otherwise, the expression is false. The `-a` and `-o`
operators are considered binary operators in this case
(**Attention:** This means the operator `-a` is not a file
operator in this case!)
- If the second argument is one of the binary conditional operators listed above under the syntax rules, the result of the expression is the result of the binary test using the first and third arguments as operands
- If the first argument is `!`, the value is the negation of the two-argument test using the second and third arguments
- If the first argument is exactly `(` and the third argument is exactly `)`, the result is the one-argument test of the second argument. Otherwise, the expression is false. The `-a` and `-o` operators are considered binary operators in this case (**Attention:** This means the operator `-a` is not a file operator in this case!)
- **4 arguments**
- If the first argument is `!`, the result is the negation of the
three-argument expression composed of the remaining arguments.
Otherwise, the expression is parsed and evaluated according to
precedence using the rules listed above
- If the first argument is `!`, the result is the negation of the three-argument expression composed of the remaining arguments. Otherwise, the expression is parsed and evaluated according to precedence using the rules listed above
- **5 or more arguments**
- The expression is parsed and evaluated according to precedence
using the rules listed above
- The expression is parsed and evaluated according to precedence using the rules listed above
These rules may seem complex, but it\'s not so bad in practice. Knowing
them might help you to explain some of the \"unexplicable\" behaviours
you might encounter:
These rules may seem complex, but it's not so bad in practice.
Knowing them might help you to explain some of the "unexplicable" behaviours you might encounter:
```bash
var=""
if [ -n $var ]; then echo "var is not empty"; fi
```
This code prints \"var is not empty\", even though `-n something` is
supposed to be true if `$var` is not empty - **why?**
This code prints "var is not empty", even though `-n something` is supposed to be true if `$var` is not empty - **why?**
Here, as `$var` is **not quoted**, word splitting occurs and `$var`
results in actually nothing (Bash removes it from the command\'s
argument list!). So the test is in fact `[ -n ]` **and falls into the
\"one argument\" rule**, the only argument is \"-n\" which is not null
and so the test returns true. The solution, as usual, is to **quote the
parameter expansion**: `[ -n "$var" ]` so that the test has always 2
arguments, even if the second one is the null string.
Here, as `$var` is **not quoted**, word splitting occurs and `$var` results in actually nothing (Bash removes it from the command's argument list!).
So the test is in fact `[ -n ]` **and falls into the "one argument" rule**, the only argument is "-n" which is not null and so the test returns true.
The solution, as usual, is to **quote the parameter expansion**:
`[ -n "$var" ]` so that the test has always 2 arguments, even if the second one is the null string.
These rules also explain why, for instance, -a and -o can have several
meanings.
These rules also explain why, for instance, -a and -o can have several meanings.
## AND and OR
### The Prefered Way
The way often recommended to logically connect several tests with AND
and OR is to use **several single test commands** and to **combine**
them with the shell `&&` and `||` **list control operators**.
The way often recommended to logically connect several tests with AND and OR is to use **several single test commands** and to **combine** them with the shell `&&` and `||` **list control operators**.
See this:
```bash
if [ -n "$var"] && [ -e "$var"]; then
echo "\$var is not null and a file named $var exists!"
fi
```
The return status of AND and OR lists is the exit status of the last
command executed in the list
The return status of AND and OR lists is the exit status of the last command executed in the list
- With `command1 && command2`, `command2` is executed if, and only if,
`command1` returns an exit status of zero (true)
- With `command1 ││ command2`, `command2` is executed if, and only if,
`command1` returns a non-zero exit status (false)
- With `command1 && command2`, `command2` is executed if, and only if, `command1` returns an exit status of zero (true)
- With `command1 ││ command2`, `command2` is executed if, and only if, `command1` returns a non-zero exit status (false)
### The other way: -a and -o
The logical operators AND and OR for the test-command itself are `-a`
and `-o`, thus:
The logical operators AND and OR for the test-command itself are `-a` and `-o`, thus:
```bash
if [ -n "$var" -a -e "$var" ] ; then
echo "\$var is not null and a file named $var exists"
fi
```
They are **not** `&&` or `||`:
```bash
$ if [ -n "/tmp" && -d "/tmp"]; then echo true; fi # DOES NOT WORK
bash: [: missing `]'
```
You might find the error message confusing, `[` does not find the
required final `]`, because as seen above `&&` is used to write a **list
of commands**. The `if` statement actually **sees two commands**:
You might find the error message confusing, `[` does not find the required final `]`, because as seen above `&&` is used to write a **list of commands**.
The `if` statement actually **sees two commands**:
- `[ -n "/tmp"`
- `-d "/tmp" ]`
\...which **must** fail.
...which **must** fail.
### Why you should avoid using -a and -o
#### If portability is a concern
POSIX(r)/SUSv3 does **not** specify the behaviour of `test` in cases
where there are more than 4 arguments. If you write a script that might
not be executed by Bash, the behaviour might be different! [^1]
POSIX(r)/SUSv3 does **not** specify the behaviour of `test` in cases where there are more than 4 arguments.
If you write a script that might not be executed by Bash, the behaviour might be different! [^1]
#### If you want the cut behaviour
Let\'s say, we want to check the following two things (AND):
Let's say, we want to check the following two things (AND):
1. if a string is null (empty)
2. if a command produced an output
Let\'s see:
```bash
if [ -z "false" -a -z "$(echo I am executed >&2)" ] ; then ...
```
=\> The arguments are all expanded **before** `test` runs, thus the
echo-command **is executed**.
=> The arguments are all expanded **before** `test` runs, thus the echo-command **is executed**.
```bash
if [ -z "false" ] && [ -z "$(echo I am not executed >&2)" ]; then...
```
=\> Due to the nature of the `&&` list operator, the second test-command
runs only if the first test-command returns true, our echo-command **is
not executed**.
=> Due to the nature of the `&&` list operator, the second test-command runs only if the first test-command returns true, our echo-command **is not executed**.
[**Note:**]{.underline} In my opinion, `-a` and `-o` are also less
readable `[pgas]`
!!! note
In my opinion, `-a` and `-o` are also less readable `[pgas]`
### Precedence and Parenthesis
Take care if you convert your scripts from using `-a` and `-o` to use
the list way (`&&` and `||`):
Take care if you convert your scripts from using `-a` and `-o` to use the list way (`&&` and `||`):
- in the test-command rules, `-a` has **precedence over** `-o`
- in the shell grammar rules, `&&` and `||` have **equal precedence**
That means, **you can get different results**, depending on the manner
of use:
That means, **you can get different results**, depending on the manner of use:
```bash
$ if [ "true" ] || [ -e /does/not/exist ] && [ -e /does/not/exist ]; then echo true; else echo false; fi
false
$ if [ "true" -o -e /does/not/exist -a -e /does/not/exist ]; then echo true; else echo false;fi
true
```
As a result you have to think about it a little or add precedence
control (parenthesis).
As a result you have to think about it a little or add precedence control (parenthesis).
For `&&` and `||` parenthesis means (shell-ly) grouping the commands,
and since `( ... )` introduces a subshell we will use `{ ... }` instead:
For `&&` and `||` parenthesis means (shell-ly) grouping the commands, and since `( ... )` introduces a subshell we will use `{ ... }` instead:
```bash
$ if [ "true" ] || { [ -e /does/not/exist ] && [ -e /does/not/exist ] ;} ; then echo true; else echo false; fi
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:
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
false
# equivalent, but less readable IMHO:
$ if [ '(' "true" -o -e /does/not/exist ')' -a -e /does/not/exist ]; then echo true; else echo false; fi
false
```
## NOT
As for AND and OR, there are 2 ways to negate a test with the shell
keyword `!` or passing `!` as an argument to `test`.
As for AND and OR, there are 2 ways to negate a test with the shell keyword `!` or passing `!` as an argument to `test`.
Here `!` negates the exit status of the command `test` which is 0
(true), and the else part is executed:
Here `!` negates the exit status of the command `test` which is 0 (true), and the else part is executed:
```bash
if ! [ -d '/tmp' ]; then echo "/tmp doesn't exists"; else echo "/tmp exists"; fi
```
Here the `test` command itself exits with status 1 (false) and the else
is also executed:
Here the `test` command itself exits with status 1 (false) and the else is also executed:
```plain
if [ ! -d '/tmp' ]; then echo "/tmp doesn't exists"; else echo "/tmp exists"; fi
```
Unlike for AND and OR, both methods for NOT have an identical behaviour,
at least for doing one single test.
Unlike for AND and OR, both methods for NOT have an identical behaviour, at least for doing one single test.
## Pitfalls summarized
In this section you will get all the mentioned (and maybe more) possible
pitfalls and problems in a summary.
In this section you will get all the mentioned (and maybe more) possible pitfalls and problems in a summary.
### General
Here\'s the copy of a mail on bug-bash list. A user asking a question
about using the test command in Bash, **he\'s talking about a problem,
which you may have already had yourself**:
Here's the copy of a mail on bug-bash list.
A user asking a question about using the test command in Bash, **he's talking about a problem, which you may have already had yourself**:
```plain
From: (PROTECTED)
Subject: -d option not working. . .?
Date: Tue, 11 Sep 2007 21:51:59 -0400
@ -389,20 +354,20 @@ which you may have already had yourself**:
}
done
Regards
```
See the problem regarding the used test-command (the other potential
problems are not of interest here)?
See the problem regarding the used test-command (the other potential problems are not of interest here)?
```bash
[-d $i]
```
He simply didn\'t know that `test` or `[` is a normal, simple command.
Well, here\'s the answer he got. I quote it here, because it\'s a well
written text that addresses most of the common issues with the
\"classic\" test command:
He simply didn't know that `test` or `[` is a normal, simple command.
Well, here's the answer he got.
I quote it here, because it's a well written text that addresses most of the common issues with the "classic" test command:
```plain
From: Bob Proulx (EMAIL PROTECTED)
Subject: Re: -d option not working. . .?
Date: Wed, 12 Sep 2007 10:32:35 -0600
@ -522,12 +487,12 @@ written text that addresses most of the common issues with the
useful as a gentle introduction and interesting anyway.
Bob
```
I hope this text protects you a bit from stepping from one pitfall into
the next.
I hope this text protects you a bit from stepping from one pitfall into the next.
I find it very interesting and informative, that\'s why I quoted it
here. Many thanks, Bob, also for the permission to copy the text here!
I find it very interesting and informative, that's why I quoted it here.
Many thanks, Bob, also for the permission to copy the text here!
## Code examples
@ -538,37 +503,31 @@ Some code snipplets follow, different ways of shell reaction is used.
- **check if a variable is defined/non-NULL**
- `test "$MYVAR"`
- `[ "$MYVAR" ]`
- **Note:** There are possibilities to make a difference if a
variable is *undefined* or *NULL* - see [Parameter Expansion -
Using an alternate value](/syntax/pe#use_an_alternate_value)
- **Note:** There are possibilities to make a difference if a variable is *undefined* or *NULL* - see [Parameter Expansion - Using an alternate value](/syntax/pe#use_an_alternate_value)
- **check if a directory exists, if not, create it**
- `test ! -d /home/user/foo && mkdir /home/user/foo`
- `[ ! -d /home/user/foo ] && mkdir /home/user/foo`
- `if [ ! -d /home/user/foo ]; then mkdir /home/user/foo; fi`
- **check if minimum one parameter was given, and that one is
\"Hello\"**
- **check if minimum one parameter was given, and that one is "Hello"**
- `test $# -ge 1 -a "$1" = "Hello" || exit 1`
- `[ $# -ge 1 ] && [ "$1" = "Hello" ] || exit 1` (see [lists
description](/syntax/basicgrammar#lists))
- `[ $# -ge 1 ] && [ "$1" = "Hello" ] || exit 1` (see [lists description](/syntax/basicgrammar#lists))
### Listing directories
Using a [for-loop](/syntax/ccmd/classic_for) to iterate through all
entries of a directory, if an entry is a directory (`[ -d "$fn" ]`),
print its name:
Using a [for-loop](/syntax/ccmd/classic_for) to iterate through all entries of a directory, if an entry is a directory (`[ -d "$fn" ]`), print its name:
```bash
for fn in *; do
[ -d "$fn" ] && echo "$fn"
done
```
## See also
- Internal: [conditional
expression](/syntax/ccmd/conditional_expression) (aka \"the new test
command\")
- Internal: [conditional expression](/syntax/ccmd/conditional_expression) (aka "the new test command")
- Internal: [the if-clause](/syntax/ccmd/if_clause)
[^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\>

11
mkdocs.yml
View File

@ -38,6 +38,17 @@ plugins:
markdown_extensions:
- admonition
- pymdownx.emoji:
emoji_index: !!python/name:materialx.emoji.twemoji
emoji_generator: !!python/name:materialx.emoji.to_svg
- pymdownx.highlight:
anchor_linenums: true
- pymdownx.superfences
- pymdownx.highlight
- pymdownx.inlinehilite
- pymdownx.keys
- pymdownx.smartsymbols
- footnotes
nav:
- Start: index.md