diff --git a/docs/bash4.md b/docs/bash4.md index 805d898..47fe28e 100644 --- a/docs/bash4.md +++ b/docs/bash4.md @@ -90,7 +90,7 @@ See [read](commands/builtin/read.md) ### Changes to the "help" builtin -The builtin itself didn\'t change much, but the data displayed is more +The builtin itself didn't change much, but the data displayed is more structured now. The help texts are in a better format, much easier to read. diff --git a/docs/commands/builtin/caller.md b/docs/commands/builtin/caller.md index f5d3c37..2cca00a 100644 --- a/docs/commands/builtin/caller.md +++ b/docs/commands/builtin/caller.md @@ -60,7 +60,7 @@ f3 ## Notes - `caller` produces no output unless used within a script that's run - from a real file. It isn\'t particularly useful for interactive use, + from a real file. It isn't particularly useful for interactive use, but can be used to create a decent `die` function to track down errors in moderately complex scripts. `{ bash /dev/stdin; } <<<$'f(){ g; }\ng(){ h; }\nh(){ while caller $((n++)); do :; done; }\nf'` diff --git a/docs/commands/builtin/declare.md b/docs/commands/builtin/declare.md index 296f8af..9094f5f 100644 --- a/docs/commands/builtin/declare.md +++ b/docs/commands/builtin/declare.md @@ -22,7 +22,7 @@ variable. When used in a function, `declare` makes `NAMEs` local variables, unless used with the `-g` option. -Don\'t use it's synonym `typeset` when coding for Bash, since it's +Don't use it's synonym `typeset` when coding for Bash, since it's tagged as obsolete. ### Options @@ -167,7 +167,7 @@ for details. ksh93 namerefs are much more powerful than Bash's. possible exception of Zsh in Bash compatibility mode. Bash marks the synonym `typeset` as obsolete, which in Bash behaves identically to `declare`. All other Korn-like shells use `typeset`, so it probably - isn\'t going away any time soon. Unfortunately, being a non-standard + isn't going away any time soon. Unfortunately, being a non-standard builtin, `typeset` differs significantly between shells. ksh93 also considers `typeset` a special builtin, while Bash does not - even in POSIX mode. If you use `typeset`, you should attempt to only use it diff --git a/docs/commands/builtin/echo.md b/docs/commands/builtin/echo.md index d371049..e99d9a1 100644 --- a/docs/commands/builtin/echo.md +++ b/docs/commands/builtin/echo.md @@ -10,7 +10,7 @@ newline. The return status is always `0`. If the [shopt](../../commands/builtin/shopt.md) option `xpg_echo` is set, Bash dynamically determines whether echo should expand escape characters -(listed below) by default based on the current platform. `echo` doesn\'t +(listed below) by default based on the current platform. `echo` doesn't interpret `--` as the end of options, and will simply print this string if given. diff --git a/docs/commands/builtin/eval.md b/docs/commands/builtin/eval.md index 7ed9577..9a3009e 100644 --- a/docs/commands/builtin/eval.md +++ b/docs/commands/builtin/eval.md @@ -33,7 +33,7 @@ the `eval` command below it. Frequently, `eval` is used to cause side-effects by performing a pass of expansion on the code before executing the resulting string. This allows -for things that otherwise wouldn\'t be possible with ordinary Bash +for things that otherwise wouldn't be possible with ordinary Bash syntax. This also, of course, makes `eval` the most powerful command in all of shell programming (and in most other languages for that matter). @@ -106,7 +106,7 @@ controlled carefully by the caller is a good way to use it. of eval will leak out into the surrounding environment. It is possible to work around this limitation by prefixing special builtins with the `command` regular builtin, but current versions of - ~~ksh93~~ and zsh don\'t do this properly + ~~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 @@ -129,12 +129,12 @@ controlled carefully by the caller is a good way to use it. $ ( x=a; eval "$x"'=( a b\ c d )'; printf '<%s> ' "${a[@]}"; echo ) # Proper quoting then gives us the expected results. -We don\'t know why Bash does this. Since parentheses are metacharacters, +We don't know why Bash does this. Since parentheses are metacharacters, they must ordinary be quoted or escaped when used as arguments. The first example above is the same error as the second in all non-Bash shells, even those with compound assignment. -In the case of `eval` it isn\'t recommended to use this behavior, +In the case of `eval` it isn't recommended to use this behavior, because unlike e.g. [declare](../../commands/builtin/declare.md), the initial expansion is still subject to all expansions including [word-splitting](../../syntax/expansion/wordsplit.md) and [pathname diff --git a/docs/commands/builtin/exit.md b/docs/commands/builtin/exit.md index 5d181a0..b2b6e3a 100644 --- a/docs/commands/builtin/exit.md +++ b/docs/commands/builtin/exit.md @@ -22,7 +22,7 @@ There are no options. ### Exit status -Naturally, you can\'t ask for the exit status from within the shell that +Naturally, you can't ask for the exit status from within the shell that executed the `exit` command, because the shell exits. Status Reason diff --git a/docs/commands/builtin/let.md b/docs/commands/builtin/let.md index f98d9f2..274dfb6 100644 --- a/docs/commands/builtin/let.md +++ b/docs/commands/builtin/let.md @@ -24,7 +24,7 @@ difference being `let` is a builtin (simple command), and `((` is a compound command. The arguments to `let` are therefore subject to all the same expansions and substitutions as any other simple command - requiring proper quoting and escaping - whereas the contents of `((` -aren\'t subject to [word-splitting](../../syntax/expansion/wordsplit.md) or +aren't subject to [word-splitting](../../syntax/expansion/wordsplit.md) or [pathname expansion](../../syntax/expansion/globs.md) (almost never desirable for arithmetic). For this reason, **the [arithmetic compound command](../../syntax/ccmd/arithmetic_eval.md) should generally be preferred @@ -80,7 +80,7 @@ needed. - It seems to be a common misunderstanding that `let` has some legacy purpose. Both `let` and [[^1]](../../syntax/ccmd/arithmetic_eval.md) were ksh88 features and almost identical in terms of portability as - everything that inherited one also tended to get the other. Don\'t + everything that inherited one also tended to get the other. Don't choose `let` over `((` expecting it to work in more places. - [expr(1)](http://pubs.opengroup.org/onlinepubs/9699919799/utilities/expr.html#tag_20_42) is a command one is likely to come across sooner or later. While it diff --git a/docs/commands/builtin/local.md b/docs/commands/builtin/local.md index f8febec..4646650 100644 --- a/docs/commands/builtin/local.md +++ b/docs/commands/builtin/local.md @@ -26,7 +26,7 @@ way, and takes all the same options, with 3 exceptions: ## Portability considerations -- `local` is not specified by POSIX. Most bourne-like shells don\'t +- `local` is not specified by POSIX. Most bourne-like shells don't have a builtin called `local`, but some such as `dash` and the busybox shell do. @@ -41,15 +41,15 @@ way, and takes all the same options, with 3 exceptions: ```{=html} ``` -- In ksh93, using POSIX-style function definitions, `typeset` doesn\'t +- In ksh93, using POSIX-style function definitions, `typeset` doesn't set `local` variables, but rather acts upon variables of the next-outermost scope (e.g. setting attributes). Using `typeset` within functions defined using ksh `function name {` syntax, variables follow roughly [lexical-scoping](http://community.schemewiki.org/?lexical-scope), - except that functions themselves don\'t have scope, just like Bash. + except that functions themselves don't have scope, just like Bash. This means that even functions defined within a \"function's - scope\" don\'t have access to non-local variables except through + scope\" don't have access to non-local variables except through `namerefs`. ## See also diff --git a/docs/commands/builtin/mapfile.md b/docs/commands/builtin/mapfile.md index f7d137d..1b408bb 100644 --- a/docs/commands/builtin/mapfile.md +++ b/docs/commands/builtin/mapfile.md @@ -29,13 +29,13 @@ given array `ARRAY` is set readonly. `-t` Remove any trailing newline from a line read, before it is assigned to an array element. `-u FD` Read from filedescriptor `FD` rather than standard input. -While `mapfile` isn\'t a common or portable shell feature, it's +While `mapfile` isn't a common or portable shell feature, it's functionality will be familiar to many programmers. Almost all programming languages (aside from shells) with support for compound datatypes like arrays, and which handle open file objects in the traditional way, have some analogous shortcut for easily reading all lines of some input as a standard feature. In Bash, `mapfile` in itself -can\'t do anything that couldn\'t already be done using read and a loop, +can't do anything that couldn't already be done using read and a loop, and if portability is even a slight concern, should never be used. However, it does *significantly* outperform a read loop, and can make for shorter and cleaner code - especially convenient for interactive @@ -62,7 +62,7 @@ Note the use of command grouping to keep the emerge command inside the pipe's subshell and within the scope of \"args\". Also note the unusual redirection. This is because the -a flag makes emerge interactive, asking the user for confirmation before continuing, and checking with -isatty(3) to abort if stdin isn\'t pointed at a terminal. Since stdin of +isatty(3) to abort if stdin isn't pointed at a terminal. Since stdin of the entire command group is still coming from the pipe even though mapfile has read all available input, we just borrow FD 1 as it just so happens to be pointing where we want it. More on this over at greycat's @@ -216,6 +216,6 @@ each subsequent 2 iterations. The RETURN trap is unimportant. ## See also - [arrays](../../syntax/arrays.md) -- [read](../../commands/builtin/read.md) - If you don\'t know about this yet, +- [read](../../commands/builtin/read.md) - If you don't know about this yet, why are you reading this page? - - It's FAQ 1 for a reason. diff --git a/docs/commands/builtin/printf.md b/docs/commands/builtin/printf.md index 34ad5fa..c91d2ae 100644 --- a/docs/commands/builtin/printf.md +++ b/docs/commands/builtin/printf.md @@ -12,7 +12,7 @@ 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). \ -Unlike other documentations, I don\'t want to redirect you to the manual +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 experienced, that should be the most detailed description for the format strings and modifiers. @@ -54,7 +54,7 @@ argument!). `-v VAR` If given, the output is assigned to the variable `VAR` instead of printed to `stdout` (comparable to `sprintf()` in some way) ---------- ------------------------------------------------------------------------------------------------------------------------------- -The `-v` Option can\'t assign directly to array indexes in Bash versions +The `-v` Option can't assign directly to array indexes in Bash versions older than Bash 4.1. \ In versions newer than 4.1, one must be careful when @@ -84,8 +84,8 @@ recognized to give a number-argument to `printf`: `0N` An octal number `0xN` A hexadecimal number `0XN` A hexadecimal number - `"X` (a literal double-quote infront of a character): interpreted as number (underlying codeset) **don\'t forget escaping** - `'X` (a literal single-quote infront of a character): interpreted as number (underlying codeset) **don\'t forget escaping** + `"X` (a literal double-quote infront of a character): interpreted as number (underlying codeset) **don't forget escaping** + `'X` (a literal single-quote infront of a character): interpreted as number (underlying codeset) **don't forget escaping** [**If more arguments than format specifiers**]{.underline} are present, then the format string is re-used until the last argument is @@ -143,7 +143,7 @@ all mean the same: A placeholder for data with a specified format: `%G` Same as `%g`, but print it like `%E` `%c` Interprets the associated argument as **char**: only the first character of a given argument is printed `%s` Interprets the associated argument literally as string - `%n` Assigns the number of characters printed so far to the variable named in the corresponding argument. Can\'t specify an array index. If the given name is already an array, the value is assigned to the zeroth element. + `%n` Assigns the number of characters printed so far to the variable named in the corresponding argument. Can't specify an array index. If the given name is already an array, the value is assigned to the zeroth element. `%a` Interprets the associated argument as **double**, and prints it in the form of a C99 [hexadecimal floating-point literal](http://www.exploringbinary.com/hexadecimal-floating-point-constants/). `%A` Same as `%a`, but print it like `%E` `%(FORMAT)T` output the date-time string resulting from using `FORMAT` as a format string for `strftime(3)`. The associated argument is the number of seconds since Epoch, or `-1` (current time) or `-2` (shell startup time). If no corresponding argument is supplies, the current time is used as default @@ -192,7 +192,7 @@ that precedes the number to print, like (prints 4,3000000000): printf "%.*f\n" 10 4,3 -The format `.*N` to specify the N\'th argument for precision does not +The format `.*N` to specify the N'th argument for precision does not work in Bash. For strings, the precision specifies the maximum number of characters to @@ -364,7 +364,7 @@ correct awk syntax. With appropriate metacharacter escaping the bash printf can be called from inside awk (as from perl and other languages that support shell -callout) as long as you don\'t care about program efficiency or +callout) as long as you don't care about program efficiency or readability. echo "Foo" | awk '{ system( "printf \"%s\\n \" \"" $1 "\"" ) }' @@ -453,7 +453,7 @@ fmt++; synopsis as: `print: print [-Rnprs] [-u unit] [-f format] [arguments]`. However, only `-Rrnfu` are actually functional. Internally, `-p` is a noop - (it doesn\'t tie in with Bash coprocs at all), and `-s` only sets a + (it doesn't tie in with Bash coprocs at all), and `-s` only sets a flag but has no effect. `-Cev` are unimplemented. ```{=html} diff --git a/docs/commands/builtin/read.md b/docs/commands/builtin/read.md index 4cbb83c..4360283 100644 --- a/docs/commands/builtin/read.md +++ b/docs/commands/builtin/read.md @@ -49,7 +49,7 @@ line is read). That means the timeout can occur during input, too. `-N ` reads `` characters of input, *ignoring any delimiter*, then quits `-p ` the prompt string `` is output (without a trailing automatic newline) before the read is performed `-r` raw input - **disables** interpretion of **backslash escapes** and **line-continuation** in the read data - `-s` secure input - don\'t echo input if on a terminal (passwords!) + `-s` secure input - don't echo input if on a terminal (passwords!) `-t ` wait for data `` seconds, then quit (exit code 1). Fractional seconds (\"5.33\") are allowed since Bash 4. A value of 0 immediately returns and indicates if data is waiting in the exit code. Timeout is indicated by an exit code greater than 128. If timeout arrives before data is read completely (before end-of-line), the partial data is saved. `-u ` use the filedescriptor number `` rather than `stdin` (0) @@ -254,9 +254,9 @@ date/time string are recognized correctly. - POSIX(r) only specified the `-r` option (raw read); `-r` is not only POSIX, you can find it in earlier Bourne source code -- POSIX(r) doesn\'t support arrays +- POSIX(r) doesn't support arrays - `REPLY` is not POSIX(r), you need to set `IFS` to the empty string - to get the whole line for shells that don\'t know `REPLY`. + to get the whole line for shells that don't know `REPLY`. `while IFS= read -r line; do ... done < text.txt diff --git a/docs/commands/builtin/readonly.md b/docs/commands/builtin/readonly.md index 17f606b..e0e4a55 100644 --- a/docs/commands/builtin/readonly.md +++ b/docs/commands/builtin/readonly.md @@ -7,7 +7,7 @@ ## Description The `readonly` builtin command is used to mark variables or functions as -read-only, which means unchangeable. This implies that it can\'t be +read-only, which means unchangeable. This implies that it can't be unset anymore. A `readonly` variable may not be redefined in child scopes. A readonly global may not be redefined as a function local variable. Simple command environment assignments may not reference diff --git a/docs/commands/builtin/return.md b/docs/commands/builtin/return.md index dbbff8c..1b6a5c3 100644 --- a/docs/commands/builtin/return.md +++ b/docs/commands/builtin/return.md @@ -18,7 +18,7 @@ There are no options. ### Exit status -If everything is okay, the `return` command doesn\'t come back. If it +If everything is okay, the `return` command doesn't come back. If it comes back, there was a problem in doing the return. Status Reason diff --git a/docs/commands/builtin/set.md b/docs/commands/builtin/set.md index 03a74bb..a5067d7 100644 --- a/docs/commands/builtin/set.md +++ b/docs/commands/builtin/set.md @@ -27,7 +27,7 @@ set flags (true for most commands on UNIX(r)). Flag Optionname Description ------ ---------------------------------------------------------- --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- `-a` `allexport` Automatically mark new and altered variables to be exported to subsequent environments. - `-b` `notify` Don\'t wait for the next prompt to print when showing the reports for a terminated background job (only with job control) + `-b` `notify` Don't wait for the next prompt to print when showing the reports for a terminated background job (only with job control) `-e` `errexit` When set, the shell exits when a simple command in a command list exits non-zero (`FALSE`). This is not done in situations, where the exit code is already checked (`if`, `while`, `until`, `||`, `&&`) `-f` `noglob` Disable [pathname expansion](../../syntax/expansion/globs.md) (globbing) `-h` `hashall` Remembers the location of commands when they\'re called (hashing). Enabled by default. @@ -41,10 +41,10 @@ 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` \`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` \`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. + `-P` `physical` Don't follow symlinks when changing directories - use the physical filesystem structure. `-T` `functrace` `DEBUG`- and `RETURN`-traps are inherited by subsequent environments, like `-E` for `ERR` trap. `-` \"End of options\" - all following arguments are assigned to the positional parameters, even when they begin with a dash. `-x` and `-v` options are turned off. Positional parameters are unchanged (unlike using `--`!) when no further arguments are given. `--` If no arguments follow, the positional parameters are unset. With arguments, the positional parameters are set, even if the strings begin with a `-` (dash) like an option. diff --git a/docs/commands/builtin/shift.md b/docs/commands/builtin/shift.md index cb98c32..fb60a16 100644 --- a/docs/commands/builtin/shift.md +++ b/docs/commands/builtin/shift.md @@ -67,8 +67,8 @@ There are no options. command shift 2\>/dev/null; then echo \"\$1\"; else echo \"no args\"; fi; }; f\' -no args \ While, POSIX requires this behavior, it isn\'t very -obvious and some shells don\'t do it correctly. To work around this, you +no args \ 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: \ \$ mksh -c \'f() { if ! \${1+false} && shift; then echo diff --git a/docs/commands/builtin/shopt.md b/docs/commands/builtin/shopt.md index 8f8e00e..f3f135e 100644 --- a/docs/commands/builtin/shopt.md +++ b/docs/commands/builtin/shopt.md @@ -33,7 +33,7 @@ When listing options, the exit code is `TRUE` (0), if all options are enabled, `FALSE` otherwise. When setting/unsetting an option, the exit code is `TRUE` unless the -named option doesn\'t exitst. +named option doesn't exitst. ## Examples diff --git a/docs/commands/builtin/unset.md b/docs/commands/builtin/unset.md index 1bec59b..f8f4328 100644 --- a/docs/commands/builtin/unset.md +++ b/docs/commands/builtin/unset.md @@ -51,7 +51,7 @@ variable has been set, then the variable of the same name in the next-outermost scope becomes visible to its scope and all children - as if the variable that was unset was never set to begin with. This property allows looking upwards through the stack as variable names are -unset, so long as unset and the local it unsets aren\'t together in the +unset, so long as unset and the local it unsets aren't together in the same scope level. Here's a demonstration of this behavior. @@ -130,7 +130,7 @@ Some things to observe: - Declaring a global with declare -g bypasses all locals and sets or modifies the variable of the global scope (outside of all functions). It has no affect on the visibility of the global. -- This doesn\'t apply to individual array elements. If two local +- This doesn't apply to individual array elements. If two local arrays of the same name appear in different scopes, the entire array of the inner scope needs to be unset before any elements of the outer array become visible. This makes \"unset\" and \"unset2\" diff --git a/docs/dict/exit_status.md b/docs/dict/exit_status.md index af4c580..96b2f21 100644 --- a/docs/dict/exit_status.md +++ b/docs/dict/exit_status.md @@ -36,9 +36,9 @@ purposes, like reporting a termination by a signal: --------- ------------------------------------------------------------------------------------------------------------------------------------------------------------ 0 success 1-255 failure (in general) - 126 the requested command (file) can\'t be executed (but was found) + 126 the requested command (file) can't be executed (but was found) 127 command (file) not found - 128 according to ABS it's used to report an invalid argument to the exit builtin, but I wasn\'t able to verify that in the source code of Bash (see code 255) + 128 according to ABS it's used to report an invalid argument to the exit builtin, but I wasn't able to verify that in the source code of Bash (see code 255) 128 + N the shell was terminated by the signal N (also used like this by various other programs) 255 wrong argument to the exit builtin (see code 128) @@ -51,7 +51,7 @@ control statements like `if` or `while`. ## Portability Tables of shell behavior involving non-portable side-effects or common -bugs with exit statuses. Note heirloom doesn\'t support pipeline +bugs with exit statuses. Note heirloom doesn't support pipeline negation (`! pipeline`). ### Misc diff --git a/docs/dict/hardlink.md b/docs/dict/hardlink.md index 014aba3..b4d1598 100644 --- a/docs/dict/hardlink.md +++ b/docs/dict/hardlink.md @@ -26,7 +26,7 @@ file and a hard link, let's take a look at the example: $ ln a b $ ln -s a c -as you can see file(1) can\'t differentiate between a real file \'a\' +as you can see file(1) can't differentiate between a real file \'a\' and a hard link \'b\', but it can tell \'c\' is a sym link $ file * @@ -41,7 +41,7 @@ same inode number AND are on the same file system it means they are $ ls -i * 5262 a 5262 b 5263 c -hard links don\'t consume additional space on the filesystem, the space +hard links don't consume additional space on the filesystem, the space is freed when the last hard link pointing to it is deleted. ## See also diff --git a/docs/dict/interpreter_directive.md b/docs/dict/interpreter_directive.md index f41750c..41dfe44 100644 --- a/docs/dict/interpreter_directive.md +++ b/docs/dict/interpreter_directive.md @@ -26,7 +26,7 @@ systems, including: - may be able to take arguments for the interpreter - \... -POSIX(r) doesn\'t specify the shebang, though in general it's commonly +POSIX(r) doesn't specify the shebang, though in general it's commonly supported by operating systems. ## See also diff --git a/docs/dict/parameter.md b/docs/dict/parameter.md index ade39f2..9f9a6cd 100644 --- a/docs/dict/parameter.md +++ b/docs/dict/parameter.md @@ -39,7 +39,7 @@ A positional parameter is denoted by a number other than `0` (zero). Positional parameters reflect the shell's arguments that are not given to the shell itself (in practise, the script arguments, also the -function arguments). You can\'t directly assign to the positional +function arguments). You can't directly assign to the positional parameters, however, [the set builtin command](../commands/builtin/set.md) can be used to indirectly set them. diff --git a/docs/dict/shell.md b/docs/dict/shell.md index 6b598ad..4d6bc7f 100644 --- a/docs/dict/shell.md +++ b/docs/dict/shell.md @@ -1,12 +1,12 @@ # Shell On UNIX(r), the shell is the main interaction tool between the -user-level and the system. That doesn\'t necessarily mean the user +user-level and the system. That doesn't necessarily mean the user always sits infront of a shell, but it's integral part of the system, not only an \"optional commandline interpreter\". The main job of a shell is to execute commands as a user requests them. -This behaviour alone doesn\'t help much. A shell knits some intelligence +This behaviour alone doesn't help much. A shell knits some intelligence and flow control around the possibility to execute commands - it's a complete commandline-oriented user-interface (UI). diff --git a/docs/dict/symlink.md b/docs/dict/symlink.md index 625d46a..1e982a9 100644 --- a/docs/dict/symlink.md +++ b/docs/dict/symlink.md @@ -5,7 +5,7 @@ to another filename. Since it really only points to another **filename** it can - reference filenames on other filesystems -- reference filenames that don\'t actually exist +- reference filenames that don't actually exist - save a reference to the name of a directory ## See also diff --git a/docs/howto/calculate-dc.md b/docs/howto/calculate-dc.md index 947cda1..e132f03 100644 --- a/docs/howto/calculate-dc.md +++ b/docs/howto/calculate-dc.md @@ -18,7 +18,7 @@ In brief, the *reverse polish notation* means the numbers are put on the stack first, then an operation is applied to them. Instead of writing `1+1`, you write `1 1+`. -By default `dc`, unlike `bc`, doesn\'t print anything, the result is +By default `dc`, unlike `bc`, doesn't print anything, the result is pushed on the stack. You have to use the \"p\" command to print the element at the top of the stack. Thus a simple operation looks like: @@ -26,7 +26,7 @@ element at the top of the stack. Thus a simple operation looks like: 2 I used a \"here string\" present in bash 3.x, ksh93 and zsh. if your -shell doesn\'t support this, you can use `echo '1 1+p' | dc` or if you +shell doesn't support this, you can use `echo '1 1+p' | dc` or if you have GNU `dc`, you can use `dc -e '1 1 +p`\'. Of course, you can also just run `dc` and enter the commands. @@ -142,7 +142,7 @@ command `f`. The stack remains unchanged: Note how the first element that will be popped from the stack is printed first, if you are used to an HP calculator, it's the reverse. -Don\'t hesitate to put `f` in the examples of this tutorial, it doesn\'t +Don't hesitate to put `f` in the examples of this tutorial, it doesn't change the result, and it's a good way to see what's going on. ## Registers @@ -159,7 +159,7 @@ supposed to use the NUL byte. Using a register is easy: +p # add the 2 values and print EOF -The above snippet uses newlines to embed comments, but it doesn\'t +The above snippet uses newlines to embed comments, but it doesn't really matter, you can use `echo '12sa10la+p'| dc`, with the same results. @@ -184,7 +184,7 @@ enclosed in `[]`. You can print it with `p`: `dc <<< '[Hello World!]p'` and you can evalute it with x: `dc <<< '[1 2+]xp'`. This is not that interesting until combined with registers. First, -let's say we want to calculate the square of a number (don\'t forget to +let's say we want to calculate the square of a number (don't forget to include `f` if you get lost!): dc << EOF @@ -223,7 +223,7 @@ we are used to reading: Some `dc` have `>R R 1 2 >R f"` doesn\'t print anything) +`dc <<< "[f]sR 2 1 >R 1 2 >R f"` doesn't print anything) Have you noticed how we can *include* a macro (string) in a macro? and as `dc` relies on a stack we can, in fact, use the macro recursively @@ -261,7 +261,7 @@ stack instead of a register for the index. ## Next -Check your dc manual, i haven\'t decribed everything, like arrays (only +Check your dc manual, i haven't decribed everything, like arrays (only documented with \"; : are used by bc(1) for array operations\" on solaris, probably because *echo \'1 0:a 0Sa 2 0:a La 0;ap\' \| dc* results in //Segmentation Fault (core dump) //, the latest solaris uses diff --git a/docs/howto/collapsing_functions.md b/docs/howto/collapsing_functions.md index 2350297..34a774e 100644 --- a/docs/howto/collapsing_functions.md +++ b/docs/howto/collapsing_functions.md @@ -41,7 +41,7 @@ common example is a script that gives the user the option of having ## How does it work? The first time you run chatter(), the function redefines itself based on -the value of verbose. Thereafter, chatter doesn\'t check \$verbose, it +the value of verbose. Thereafter, chatter doesn't check \$verbose, it simply is. Further calls to the function reflect its collapsed nature. If verbose is unset, chatter will echo nothing, with no extra effort from the developer. diff --git a/docs/howto/conffile.md b/docs/howto/conffile.md index 15cfda2..0daad90 100644 --- a/docs/howto/conffile.md +++ b/docs/howto/conffile.md @@ -4,7 +4,7 @@ ## General -For this task, you don\'t have to write large parser routines (unless +For this task, you don't have to write large parser routines (unless you want it 100% secure or you want a special file syntax) - you can use the Bash source command. The file to be sourced should be formated in key=\"value\" format, otherwise bash will try to interpret commands: @@ -74,10 +74,10 @@ malicious code: echo rm -fr ~/* mailto=netadmin@example.com -You don\'t want these `echo`-commands (which could be any other +You don't want these `echo`-commands (which could be any other commands!) to be executed. One way to be a bit safer is to filter only the constructs you want, write the filtered results to a new file and -source the new file. We also need to be sure something nefarious hasn\'t +source the new file. We also need to be sure something nefarious hasn't been added to the end of one of our name=value parameters, perhaps using ; or && command separators. In those cases, perhaps it is simplest to just ignore the line entirely. Egrep (`grep -E`) will help us here, it @@ -99,11 +99,11 @@ filters by description: source "$configfile" **[To make clear what it does:]{.underline}** egrep checks if the file -contains something we don\'t want, if yes, egrep filters the file and +contains something we don't want, if yes, egrep filters the file and writes the filtered contents to a new file. If done, the original file name is changed to the name stored in the variable `configfile`. The file named by that variable is sourced, as if it were the original file. This filter allows only `NAME=VALUE` and comments in the file, but it -doesn\'t prevent all methods of code execution. I will address that +doesn't prevent all methods of code execution. I will address that later. diff --git a/docs/howto/dissectabadoneliner.md b/docs/howto/dissectabadoneliner.md index ae37324..e6434dd 100644 --- a/docs/howto/dissectabadoneliner.md +++ b/docs/howto/dissectabadoneliner.md @@ -45,7 +45,7 @@ of the old style backticks: sh $ for i in *.zip; do j=$(basename "$i" ".zip"); mkdir $j; cd $j; unzip ../$i; cd ..; done ``` -In Bash we don\'t need the subshell or the external basename command. +In Bash we don't need the subshell or the external basename command. See [Substring removal with parameter expansion](../syntax/pe.md#substring_removal): @@ -66,7 +66,7 @@ command(s), check for success! You can do this with the \"`&&`\" conjunction, that way, if the previous command fails, bash will not try to execute the following command(s). It's fully POSIX(r). Oh, and remember what I said about [wordsplitting](../syntax/expansion/wordsplit.md) -in the previous step? Well, if you don\'t quote `$j`, wordsplitting can +in the previous step? Well, if you don't quote `$j`, wordsplitting can happen again. ``` bash @@ -106,7 +106,7 @@ mkdir "$j" && cd "$j" && unzip ../$i && cd - Well, besides word splitting, there's nothing terribly wrong with this. Still, did it occur to you that unzip might already be able to target a -directory? There isn\'t a standard for the `unzip` command, but all the +directory? There isn't a standard for the `unzip` command, but all the implementations I\'ve seen can do it with the -d flag. So we can drop the cd commands entirely: diff --git a/docs/howto/edit-ed.md b/docs/howto/edit-ed.md index 1e8e4a7..a1799f4 100644 --- a/docs/howto/edit-ed.md +++ b/docs/howto/edit-ed.md @@ -13,14 +13,14 @@ that, e.g. editing active and open files, the lack of GNU, or other Why `ed`? -- maybe your `sed` doesn\'t support in-place edit +- maybe your `sed` doesn't support in-place edit - maybe you need to be as portable as possible - maybe you need to really edit in-file (and not create a new file like GNU `sed`) - last but not least: standard `ed` has very good editing and addressing possibilities, compared to standard `sed` -Don\'t get me wrong, this is **not** meant as anti-`sed` article! It's +Don't get me wrong, this is **not** meant as anti-`sed` article! It's just meant to show you another way to do the job. ## Commanding ed @@ -133,7 +133,7 @@ always a good idea to have a backup copy!** ## Editing your files Most of these things can be done with `sed`. But there are also things -that can\'t be done in `sed` or can only be done with very complex code. +that can't be done in `sed` or can only be done with very complex code. ### Simple word substitutions @@ -179,7 +179,7 @@ regexp \...using the `m` command: `
m ` -This is definitely something that can\'t be done easily with sed. +This is definitely something that can't be done easily with sed. # moving lines 5-9 to the end of the file ed -s test.txt <<< $'5,9m$\nw' @@ -206,7 +206,7 @@ command: `j` (join). ed -s file <<< $'1,$j\nw' -Compared with two other methods (using `tr` or `sed`), you don\'t have +Compared with two other methods (using `tr` or `sed`), you don't have to delete all newlines and manually add one at the end. ### File operations @@ -288,7 +288,7 @@ attempt the substitution on all non blank lines **\_\_ shell parameters are expanded \_\_** -If you don\'t quote the delimiter, \$ has a special meaning. This sounds +If you don't quote the delimiter, \$ has a special meaning. This sounds obvious but it's easy to forget this fact when you use addresses like \$-1 or commands like \$a. Either quote the \$ or the delimiter: diff --git a/docs/howto/getopts_tutorial.md b/docs/howto/getopts_tutorial.md index 6322420..b1d3124 100644 --- a/docs/howto/getopts_tutorial.md +++ b/docs/howto/getopts_tutorial.md @@ -40,14 +40,14 @@ several logical groups: - `-f` is also an option, but this option has an associated **option argument** (an argument to the option `-f`): `/etc/mybackup.conf`. The option argument is usually the argument following the option - itself, but that isn\'t mandatory. Joining the option and option + itself, but that isn't mandatory. Joining the option and option argument into a single argument `-f/etc/mybackup.conf` is valid. -- `-r` depends on the configuration. In this example, `-r` doesn\'t +- `-r` depends on the configuration. In this example, `-r` doesn't take arguments so it's a standalone option like `-x`. - `./foo.txt` and `./bar.txt` are remaining arguments without any associated options. These are often used as **mass-arguments**. For example, the filenames specified for `cp(1)`, or arguments that - don\'t need an option to be recognized because of the intended + don't need an option to be recognized because of the intended behavior of the program. POSIX(r) calls them **operands**. To give you an idea about why `getopts` is useful, The above command @@ -79,8 +79,8 @@ left to parse, it's easy to use in a while-loop: done `getopts` will parse options and their possible arguments. It will stop -parsing on the first non-option argument (a string that doesn\'t begin -with a hyphen (`-`) that isn\'t an argument for any option in front of +parsing on the first non-option argument (a string that doesn't begin +with a hyphen (`-`) that isn't an argument for any option in front of it). It will also stop parsing when it sees the `--` (double-hyphen), which means [end of options](../dict/terms/end_of_options.md). @@ -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). @@ -138,7 +138,7 @@ default (which means it parses `"$@"`). You can give your own set of arguments to the utility to parse. Whenever additional arguments are given after the `VARNAME` parameter, `getopts` -doesn\'t try to parse the positional parameters, but these given words. +doesn't try to parse the positional parameters, but these given words. This way, you are able to parse any option set you like, here for example from an array: @@ -160,7 +160,7 @@ Regarding error-reporting, there are two modes `getopts` can run in: - silent mode For productive scripts I recommend to use the silent mode, since -everything looks more professional, when you don\'t see annoying +everything looks more professional, when you don't see annoying standard messages. Also it's easier to handle, since the failure cases are indicated in an easier way. @@ -211,17 +211,17 @@ Let's do some tests: $ ./go_test.sh $ -Nothing happened? Right. `getopts` didn\'t see any valid or invalid -options (letters preceded by a dash), so it wasn\'t triggered. +Nothing happened? Right. `getopts` didn't see any valid or invalid +options (letters preceded by a dash), so it wasn't triggered. #### Calling it with non-option arguments $ ./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. +wasn't triggered. The arguments given to your script are of course accessible as `$1` - `${N}`. @@ -236,7 +236,7 @@ First, an **invalid** one: Invalid option: -b $ -As expected, `getopts` didn\'t accept this option and acted like told +As expected, `getopts` didn't accept this option and acted like told above: It placed `?` into `$opt` and the invalid option character (`b`) into `$OPTARG`. With our `case` statement, we were able to detect this. @@ -271,7 +271,7 @@ times**: The last examples lead us to some points you may consider: -- **invalid options don\'t stop the processing**: If you want to stop +- **invalid options don't stop the processing**: If you want to stop the script, you have to do it yourself (`exit` in the right place) - **multiple identical options are possible**: If you want to disallow these, you have to check manually (e.g. by setting a variable or so) @@ -310,14 +310,14 @@ Let's do the very same tests we did in the last example: $ ./go_test.sh $ -As above, nothing happened. It wasn\'t triggered. +As above, nothing happened. It wasn't triggered. #### Calling it with non-option arguments $ ./go_test.sh /etc/passwd $ -The **very same** case: It wasn\'t triggered. +The **very same** case: It wasn't triggered. #### Calling it with option-arguments @@ -327,7 +327,7 @@ The **very same** case: It wasn\'t triggered. Invalid option: -b $ -As expected, as above, `getopts` didn\'t accept this option and acted +As expected, as above, `getopts` didn't accept this option and acted like programmed. **Valid** option, but without the mandatory **argument**: diff --git a/docs/howto/mutex.md b/docs/howto/mutex.md index 29a9eb7..660fcaa 100644 --- a/docs/howto/mutex.md +++ b/docs/howto/mutex.md @@ -12,11 +12,11 @@ prevent this, a form of `MUTEX` (**mutual exclusion**) lock is needed. The basic procedure is simple: The script checks if a specific condition (locking) is present at startup, if yes, it's locked - the scipt -doesn\'t start. +doesn't start. This article describes locking with common UNIX(r) tools. There are other special locking tools available, But they\'re not standardized, or -worse yet, you can\'t be sure they\'re present when you want to run your +worse yet, you can't be sure they\'re present when you want to run your scripts. **A tool designed for specifically for this purpose does the job much better than general purpose code.** @@ -32,7 +32,7 @@ limits. ## Choose the locking method The best way to set a global lock condition is the UNIX(r) filesystem. -Variables aren\'t enough, as each process has its own private variable +Variables aren't enough, as each process has its own private variable space, but the filesystem is global to all processes (yes, I know about chroots, namespaces, \... special case). You can \"set\" several things in the filesystem that can be used as locking indicator: @@ -47,7 +47,7 @@ the existance of the lockfile, if no lockfile exists, it creates one and continues. Those are **two separate steps**! That means it's **not an atomic operation**. There's a small amount of time between checking and creating, where another instance of the same script could perform -locking (because when it checked, the lockfile wasn\'t there)! In that +locking (because when it checked, the lockfile wasn't there)! In that case you would have 2 instances of the script running, both thinking they are succesfully locked, and can operate without colliding. Setting the timestamp is similar: One step to check the timespamp, a second step @@ -129,7 +129,7 @@ differences compared to the very simple example above: - traps are created to automatically remove the lock when the script terminates, or is killed -Details on how the script is killed aren\'t given, only code relevant to +Details on how the script is killed aren't given, only code relevant to the locking process is shown: ``` bash diff --git a/docs/howto/pax.md b/docs/howto/pax.md index a0dc018..dd209af 100644 --- a/docs/howto/pax.md +++ b/docs/howto/pax.md @@ -17,7 +17,7 @@ only an introduction. This article is based on the debianized Berkeley implementation of `pax`, but implementation-specific things should be tagged as such. -Unfortunately, the Debian package doesn\'t seem to be maintained +Unfortunately, the Debian package doesn't seem to be maintained anymore. ## Overview @@ -71,7 +71,7 @@ options, e.g. rewriting groups) to another location. ### Archive data -When you don\'t specify anything special, `pax` will attempt to read +When you don't specify anything special, `pax` will attempt to read archive data from standard input (read/list modes) and write archive data to standard output (write mode). This ensures `pax` can be easily used as part of a shell pipe construct, e.g. to read a compressed @@ -170,7 +170,7 @@ customized to include permissions, timestamps, etc. with the specification is strongly derived from the `printf(3)` format specification. -**Unfortunately** the `pax` utility delivered with Debian doesn\'t seem +**Unfortunately** the `pax` utility delivered with Debian doesn't seem to support these extended listing formats. However, `pax` lists archive members in a `ls -l`-like format, when you @@ -238,7 +238,7 @@ The same, but with an archive, can be accomplished by: pax -w -T 0000 -f /n/mybackups/$(date +%A) -In this case, the day-name is an archive-file (you don\'t need a +In this case, the day-name is an archive-file (you don't need a filename extension like `.tar` but you can add one, if desired). ### Changing filenames while archiving @@ -292,7 +292,7 @@ that you want to extract only the \"usr\" directory: Like `cpio`, pax can read filenames from standard input (`stdin`). This provides great flexibility - for example, a `find(1)` command may select -files/directories in ways pax can\'t do itself. In **write** mode +files/directories in ways pax can't do itself. In **write** mode (creating an archive) or **copy** mode, when no filenames are given, pax expects to read filenames from standard input. For example: diff --git a/docs/howto/redirection_tutorial.md b/docs/howto/redirection_tutorial.md index eb1d9d2..1cca8de 100644 --- a/docs/howto/redirection_tutorial.md +++ b/docs/howto/redirection_tutorial.md @@ -227,7 +227,7 @@ So, as a simple example (albeit slightly contrived), is the following: ## Order Of Redirection, i.e., \"\> file 2\>&1\" vs. \"2\>&1 \>file\" -While it doesn\'t matter where the redirections appears on the command +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. - `2>&1 >file` @@ -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 @@ -329,7 +329,7 @@ truncated. When `sed` starts to read the file, it contains nothing. In Bash the `exec` built-in replaces the shell with the specified program. So what does this have to do with redirection? `exec` also -allow us to manipulate the file descriptors. If you don\'t specify a +allow us to manipulate the file descriptors. If you don't specify a program, the redirection after `exec` modifies the file descriptors of the current shell. @@ -366,7 +366,7 @@ user to press a key: while read -r line;do echo "$line"; read -p "Press any key" -n 1;done < file -And, surprise this doesn\'t work. Why? because the shell descriptor of +And, surprise this doesn't work. Why? because the shell descriptor of the while loop looks like: --- +-----------------------+ diff --git a/docs/internals/shell_options.md b/docs/internals/shell_options.md index 8f53570..a0611da 100644 --- a/docs/internals/shell_options.md +++ b/docs/internals/shell_options.md @@ -3,7 +3,7 @@ ![](keywords>bash shell scripting options runtime variable behaviour) This information was taken from a Bash version \"`4.1`\", every now and -then new options are added, so likely, this list isn\'t complete. +then new options are added, so likely, this list isn't complete. The shell-options can be set with the [shopt builtin command](../commands/builtin/shopt.md). @@ -490,7 +490,7 @@ There are two options that influence the parsing this way: - `extglob` - `extquote` -Consequence: You **can\'t** use the new syntax (e.g. the extended +Consequence: You **can't** use the new syntax (e.g. the extended globbing syntax) and the command to enable it **in the same line**. $ shopt -s extglob; echo !(*.txt) # this is the WRONG way! diff --git a/docs/misc/bashphorisms.md b/docs/misc/bashphorisms.md index 1550e07..adb2f44 100644 --- a/docs/misc/bashphorisms.md +++ b/docs/misc/bashphorisms.md @@ -21,14 +21,14 @@ And yes, these bashphorisms reflect the daily reality in `#bash`. 4 The questioner will not read and apply the answers he is given but will instead continue to practice bashphorism #1 and bashphorism #2. 5 The ignorant will continually mis-educate the other noobies. 6 When given a choice of solutions, the newbie will always choose the wrong one. - 7 The newbie will always find a reason to say, \"It doesn\'t work.\" - 8 If you don\'t know to whom the bashphorism's referring, it's you. + 7 The newbie will always find a reason to say, \"It doesn't work.\" + 8 If you don't know to whom the bashphorism's referring, it's you. 9 All examples given by the questioner will be broken, misleading, wrong, and not representative of the actual question. 10 See B1 11 Please apply `(( % 10 ))` to the bashphorism value. 12 All logic is deniable; however, some logic will \*plonk\* you if you deny it. 13 Everyone ignores greycat when he is right. When he is wrong, it is !b1 - 14 The newbie doesn\'t actually know what he's asking. If he did, he wouldn\'t need to ask. + 14 The newbie doesn't actually know what he's asking. If he did, he wouldn't need to ask. 15 The more advanced you are, the more likely you are to be overcomplicating it. 16 The more beginner you are, the more likely you are to be overcomplicating it. 17 A newbie comes to #bash to get his script confirmed. He leaves disappointed. @@ -39,14 +39,14 @@ And yes, these bashphorisms reflect the daily reality in `#bash`. 22 The newcomer will abuse the bot's factoid triggers for their own entertainment until someone gets annoyed enough to ask them to message it privately instead. 23 Everyone is a newcomer. 24 The newcomer will address greybot as if it were human. - 25 The newbie won\'t accept any answer that uses practical or standard tools. + 25 The newbie won't accept any answer that uses practical or standard tools. 26 The newbie will not TELL you about this restriction until you have wasted half an hour. 27 The newbie will lie. 28 When the full horror of the newbie's true goal is revealed, the newbie will try to restate the goal to trick you into answering. Newbies are stupid. 29 It's always git. Or python virtualenv. Or docker. One of those pieces of shit. ALWAYS. - 30 They won\'t show you the homework assignment. That would make it too easy. + 30 They won't show you the homework assignment. That would make it too easy. 31 Your teacher is a f\*\*king idiot. 32 The more horrifyingly wrong a proposed solution is, the more likely it will be used. - 33 The newbie cannot explain what he is doing, or why. He will show you incomprehensible, nonworking code instead. What? You can\'t read his mind?! + 33 The newbie cannot explain what he is doing, or why. He will show you incomprehensible, nonworking code instead. What? You can't read his mind?! Please feel free to correct or extend this page whenever needed. diff --git a/docs/scripting/bashbehaviour.md b/docs/scripting/bashbehaviour.md index 1989dfa..9b4cbbd 100644 --- a/docs/scripting/bashbehaviour.md +++ b/docs/scripting/bashbehaviour.md @@ -76,7 +76,7 @@ mode (for running, not for starting!)](#posix_run_mode). [**Bash starts in `sh` compatiblity mode when:**]{.underline} - the base filename in `argv[0]` is `sh` (:!: NB: `/bin/sh` may be - linked to `/bin/bash`, but that doesn\'t mean it acts like + linked to `/bin/bash`, but that doesn't mean it acts like `/bin/bash` :!:) ### POSIX mode @@ -85,7 +85,7 @@ When Bash is started in POSIX(r) mode, it follows the POSIX(r) standard for startup files. In this mode, **interactive shells** expand the [ENV](../syntax/shellvars.md#ENV) variable and commands are read and executed from the file whose name is the expanded value.\ -No other startup files are read. Hence, a non-interactive shell doesn\'t +No other startup files are read. Hence, a non-interactive shell doesn't read any startup files in POSIX(r) mode. [**Bash starts in POSIX(r) mode when:**]{.underline} @@ -315,29 +315,29 @@ In restricted mode, Bash sets up (and runs) a shell environment that's far more controlled and limited than the standard shell mode. It acts like normal Bash with the following restrictions: -- the `cd` command can\'t be used to change directories +- the `cd` command can't be used to change directories - the variables [SHELL](../syntax/shellvars.md#SHELL), [PATH](../syntax/shellvars.md#PATH), [ENV](../syntax/shellvars.md#ENV) and - [BASH_ENV](../syntax/shellvars.md#BASH_ENV) can\'t be set or unset -- command names that contain a `/` (slash) can\'t be called (hence + [BASH_ENV](../syntax/shellvars.md#BASH_ENV) can't be set or unset +- command names that contain a `/` (slash) can't be called (hence you\'re limited to `PATH`) -- filenames containing a `/` (slash) can\'t be specified as argument +- filenames containing a `/` (slash) can't be specified as argument to the `source` or `.` builtin command -- filenames containing a `/` (slash) can\'t be specified as argument +- filenames containing a `/` (slash) can't be specified as argument to the `-p` option of the `hash` builtin command - function definitions are not inherited from the environment at shell startup - the environment variable [SHELLOPTS](../syntax/shellvars.md#SHELLOPTS) is ignored at startup - redirecting output using the `>`, `>|`, `<>`, `>&`, `&>`, and `>>` - redirection operators isn\'t allowed -- the `exec` builtin command can\'t replace the shell with another + redirection operators isn't allowed +- the `exec` builtin command can't replace the shell with another process - adding or deleting builtin commands with the `-f` and `-d` options to the enable builtin command is forbidden - using the `enable` builtin command to enable disabled shell builtins - doesn\'t work -- the `-p` option to the `command` builtin command doesn\'t work + doesn't work +- the `-p` option to the `command` builtin command doesn't work - turning off restricted mode with `set +r` or `set +o restricted` is (of course) forbidden diff --git a/docs/scripting/bashchanges.md b/docs/scripting/bashchanges.md index 029e417..f6fafd5 100644 --- a/docs/scripting/bashchanges.md +++ b/docs/scripting/bashchanges.md @@ -154,7 +154,7 @@ For this topic, see also `echo` `\uNNNN` and `\UNNNNNNNN` escape sequences 4.2-alpha for: `printf`, `echo -e`, `$'...'` `exec` option `-a` to give a `argv[0]` string 4.2-alpha `time` allowed as a command by itself to display timing values of the shell and its children 4.2-alpha POSIX change - `help` `help` now searches exact topic-strings (i.e. `help read` won\'t find `readonly` anymore) 4.3-alpha + `help` `help` now searches exact topic-strings (i.e. `help read` won't find `readonly` anymore) 4.3-alpha `return` accept negative values as return value (e.g. `return -1` will show as (8 bit) 255 in the caller) 4.3-alpha `exit` accept negative values as return value (e.g. `return -1` will show as (8 bit) 255 in the caller) 4.3-alpha `read` `read` skips `NUL` (ASCII Code 0) in input 4.3-alpha diff --git a/docs/scripting/basics.md b/docs/scripting/basics.md index c2c8ebb..4ea9454 100644 --- a/docs/scripting/basics.md +++ b/docs/scripting/basics.md @@ -40,7 +40,7 @@ You can follow the process by using `echo` as a fake interpreter: #!/bin/echo -We don\'t need a script body here, as the file will never be interpreted +We don't need a script body here, as the file will never be interpreted and executed by \"`echo`\". You can see what the Operating System does, it calls \"`/bin/echo`\" with the name of the executable file and following arguments. @@ -58,7 +58,7 @@ be is system-specific (see executes a file with a #!/bin/bash shebang, the shebang itself is ignored, since the first character is a hashmark \"#\", which indicates 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 +Programs that don't ignore such lines, may not work as shebang driven interpreters. \ [**Attention:**]{.underline}When the @@ -145,11 +145,11 @@ code is a number between 0 and 255. Values from 126 to 255 are reserved for use by the shell directly, or for special purposes, like reporting a termination by a signal: -- **126**: the requested command (file) was found, but can\'t be +- **126**: the requested command (file) was found, but can't be executed - **127**: command (file) not found - **128**: according to ABS it's used to report an invalid argument - to the exit builtin, but I wasn\'t able to verify that in the source + to the exit builtin, but I wasn't able to verify that in the source code of Bash (see code 255) - **128 + N**: the shell was terminated by the signal N - **255**: wrong argument to the exit builtin (see code 128) @@ -242,7 +242,7 @@ SOMEWORD ``` What happened? The `:` pseudo command was given some input by -redirection (a here-document) - the pseudo command didn\'t care about +redirection (a here-document) - the pseudo command didn't care about it, effectively, the entire block was ignored. The here-document-tag was quoted here **to avoid substitutions** in the diff --git a/docs/scripting/debuggingtips.md b/docs/scripting/debuggingtips.md index 621a217..a248877 100644 --- a/docs/scripting/debuggingtips.md +++ b/docs/scripting/debuggingtips.md @@ -9,16 +9,16 @@ but as hints and comments about debugging a Bash script. Do **not** name your script `test`, for example! *Why?* `test` is the name of a UNIX(r)-command, and [most likely built into your -shell]{.underline} (it's a built-in in Bash) - so you won\'t be able to +shell]{.underline} (it's a built-in in Bash) - so you won't be able to run a script with the name `test` in a normal way. -**Don\'t laugh!** This is a classic mistake :-) +**Don't laugh!** This is a classic mistake :-) ## Read the error messages Many people come into IRC and ask something like *\"Why does my script fail? I get an error!\"*. And when you ask them what the error message -is, they don\'t even know. Beautiful. +is, they don't even know. Beautiful. Reading and interpreting error messages is 50% of your job as debugger! Error messages actually **mean** something. At the very least, they can @@ -329,11 +329,11 @@ carriage return character!): Here's what happens because of the `#!/bin/bash^M` in our shebang: -- the file `/bin/bash^M` doesn\'t exist (hopefully) +- the file `/bin/bash^M` doesn't exist (hopefully) - So Bash prints an error message which (depending on the terminal, the Bash version, or custom patches!) may or may not expose the problem. -- the script can\'t be executed +- the script can't be executed The error message can vary. If you\'re lucky, you\'ll get: diff --git a/docs/scripting/newbie_traps.md b/docs/scripting/newbie_traps.md index 7b5ab09..f5bbcb6 100644 --- a/docs/scripting/newbie_traps.md +++ b/docs/scripting/newbie_traps.md @@ -28,7 +28,7 @@ See also: - [Bash startup mode: SH mode](../scripting/bashbehaviour.md#sh_mode) - [Bash run mode: POSIX mode](../scripting/bashbehaviour.md#posix_run_mode) -### Your script named \"test\" doesn\'t execute +### Your script named \"test\" doesn't execute Give it another name. The executable `test` already exists. @@ -59,7 +59,7 @@ text formed by the prefix, the postfix and the braces themselves are generated. In the example, these are only two: `-i*.vob` and `-i`. The filename expansion happens **after** that, so there is a chance that `-i*.vob` is expanded to a filename - if you have files like -`-ihello.vob`. But it definitely doesn\'t do what you expected. +`-ihello.vob`. But it definitely doesn't do what you expected. Please see: @@ -90,7 +90,7 @@ variable! Bash is not PHP! A variable name preceeded with a dollar-sign always means that the variable gets **expanded**. In the example above, it might expand to -nothing (because it wasn\'t set), effectively resulting in\... +nothing (because it wasn't set), effectively resulting in\... ="Hello world!" @@ -140,7 +140,7 @@ A typical beginner's trap is quoting. As noted above, when you want to **expand** a variable i.e. \"get the content\", the variable name needs to be prefixed with a dollar-sign. But, since Bash knows various ways to quote and does word-splitting, the -result isn\'t always the same. +result isn't always the same. Let's define an example variable containing text with spaces: @@ -195,7 +195,7 @@ process you execute to start that script `./script.sh`): Exporting is one-way. The direction is from parent process to child process, not the reverse. The above example **will** work, when you -don\'t execute the script, but include (\"source\") it: +don't execute the script, but include (\"source\") it: $ source ./script.sh $ echo $hello @@ -213,7 +213,7 @@ Please see: ### Reacting to exit codes If you just want to react to an exit code, regardless of its specific -value, you **don\'t need** to use `$?` in a test command like this: +value, you **don't need** to use `$?` in a test command like this: ``` bash grep ^root: /etc/passwd >/dev/null 2>&1 diff --git a/docs/scripting/nonportable.md b/docs/scripting/nonportable.md index 9cf85a8..ca2aa6e 100644 --- a/docs/scripting/nonportable.md +++ b/docs/scripting/nonportable.md @@ -22,9 +22,9 @@ In these cases the portable syntax should be preferred. `command\ <<<\ WORD` `command <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/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. - `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. + `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. This table lists syntax that is specified by POSIX (unless otherwise specified below), but has been superseded by superior alternatives @@ -34,19 +34,19 @@ historical reasons. ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Syntax Replacement Description ----------------------------------------------------------------------------------------------------- ----------------------------------------------------------------------------------------------------------------------------------------------------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- - Unquoted expansions, [wordsplit](../syntax/expansion/wordsplit.md), and [globs](../syntax/expansion/globs.md) [Proper quoting](http://mywiki.wooledge.org/Quotes), Ksh/Bash-style [arrays](../syntax/arrays.md), The \"\$@\" expansion, [read](../commands/builtin/read.md) *Quoting errors* are a broad category of common mistakes brought about by a few unintuitive features carried over from the Bourne shell due to complaints of broken scripts and changes in previously documented behavior. Most of the important expansions are performed at the same time from left to right. However, a few expansions, most notably word-splitting and globbing, and in shells other than Bash, [brace expansion](../syntax/expansion/brace.md), are performed **on the results of previous expansions, by default, unless they are quoted.** This means that the act of expanding an unquoted variable in an ordinary argument context, depending on the value of the variable, can yield different results depending on possibly uncontrolled side-effects like the value of `IFS`, and the names of files in the current working directory. You can\'t get globbing without word-splitting, or vice versa (without `set -f`). [You can\'t store a command or character-delimited list in a variable and safely evaluate it with unquoted expansion](http://mywiki.wooledge.org/BashFAQ/050). If possible, always choose a shell that supports Korn shell arrays such as Bash. They are a vital but non-standard feature for writing clean, safe scripts. Well-written scripts don\'t use word-splitting. A few exceptions are listed on the [word splitting page](../syntax/expansion/wordsplit.md). A significant proportion of the issues on the famous [Pitfalls list](http://mywiki.wooledge.org/BashPitfalls) fall under this category. See also: *[Don\'t read lines with for!](http://mywiki.wooledge.org/DontReadLinesWithFor)* + Unquoted expansions, [wordsplit](../syntax/expansion/wordsplit.md), and [globs](../syntax/expansion/globs.md) [Proper quoting](http://mywiki.wooledge.org/Quotes), Ksh/Bash-style [arrays](../syntax/arrays.md), The \"\$@\" expansion, [read](../commands/builtin/read.md) *Quoting errors* are a broad category of common mistakes brought about by a few unintuitive features carried over from the Bourne shell due to complaints of broken scripts and changes in previously documented behavior. Most of the important expansions are performed at the same time from left to right. However, a few expansions, most notably word-splitting and globbing, and in shells other than Bash, [brace expansion](../syntax/expansion/brace.md), are performed **on the results of previous expansions, by default, unless they are quoted.** This means that the act of expanding an unquoted variable in an ordinary argument context, depending on the value of the variable, can yield different results depending on possibly uncontrolled side-effects like the value of `IFS`, and the names of files in the current working directory. You can't get globbing without word-splitting, or vice versa (without `set -f`). [You can't store a command or character-delimited list in a variable and safely evaluate it with unquoted expansion](http://mywiki.wooledge.org/BashFAQ/050). If possible, always choose a shell that supports Korn shell arrays such as Bash. They are a vital but non-standard feature for writing clean, safe scripts. Well-written scripts don't use word-splitting. A few exceptions are listed on the [word splitting page](../syntax/expansion/wordsplit.md). A significant proportion of the issues on the famous [Pitfalls list](http://mywiki.wooledge.org/BashPitfalls) fall under this category. See also: *[Don't read lines with for!](http://mywiki.wooledge.org/DontReadLinesWithFor)* `` `COMMANDS` `` `$(COMMANDS)` This is the older Bourne-compatible form of the [command substitution](../syntax/expansion/cmdsubst.md). Both the `` `COMMANDS` `` and `$(COMMANDS)` syntaxes are specified by POSIX, but the latter is [greatly]{.underline} preferred, though the former is unfortunately still very prevalent in scripts. New-style command substitutions are widely implemented by every modern shell (and then some). The only reason for using backticks is for compatibility with a real Bourne shell (like Heirloom). Backtick command substitutions require special escaping when nested, and examples found in the wild are improperly quoted more often than not. See: *[Why is \$(\...) preferred over \`\...\` (backticks)?](http://mywiki.wooledge.org/BashFAQ/082)*. - `[\ EXPRESSION\ ]`\\ and\\ `test\ EXPRESSION` `[[\ EXPRESSION\ ]]` `test` and `[` are the Bourne/POSIX commands for evaluating test expressions (they are almost identical, and `[` is somewhat more common). The expressions consist of regular arguments, unlike the Ksh/Bash `[[` command. While the issue is analogous to `let` vs `((`, the advantages of `[[` vs `[` are even more important because the arguments/expansions aren\'t just concatenated into one expression. With the classic `[` command, the number of arguments is significant. If at all possible, use the [conditional expression](../syntax/ccmd/conditional_expression.md) (\"new test command\") `[[ EXPRESSION ]]`. Unless there is a need for POSIX compatibility, there are only a few reasons to use `[`. `[[` is one of the most portable and consistent non-POSIX ksh extensions available. See: [conditional_expression](../syntax/ccmd/conditional_expression.md) and *[What is the difference between test, \[ and \[\[ ?](http://mywiki.wooledge.org/BashFAQ/031)* + `[\ EXPRESSION\ ]`\\ and\\ `test\ EXPRESSION` `[[\ EXPRESSION\ ]]` `test` and `[` are the Bourne/POSIX commands for evaluating test expressions (they are almost identical, and `[` is somewhat more common). The expressions consist of regular arguments, unlike the Ksh/Bash `[[` command. While the issue is analogous to `let` vs `((`, the advantages of `[[` vs `[` are even more important because the arguments/expansions aren't just concatenated into one expression. With the classic `[` command, the number of arguments is significant. If at all possible, use the [conditional expression](../syntax/ccmd/conditional_expression.md) (\"new test command\") `[[ EXPRESSION ]]`. Unless there is a need for POSIX compatibility, there are only a few reasons to use `[`. `[[` is one of the most portable and consistent non-POSIX ksh extensions available. See: [conditional_expression](../syntax/ccmd/conditional_expression.md) and *[What is the difference between test, \[ and \[\[ ?](http://mywiki.wooledge.org/BashFAQ/031)* `set -e`, `set -o errexit`\ proper control flow and error handling `set -e` causes untested non-zero exit statuses to be fatal. It is a debugging feature intended for use only during development and should not be used in production code, especially init scripts and other high-availability scripts. Do not be tempted to think of this as \"error handling\"; it's not, it's just a way to find the place you\'ve *forgotten* to put error handling.\ and the `ERR` trap Think of it as akin to `use strict` in Perl or `throws` in C++: tough love that makes you write better code. Many guides recommend avoiding it entirely because of the apparently-complex rules for when non-zero statuses cause the script to abort. Conversely, large software projects with experienced coders may recommend or even mandate its use.\ Because it provides no notification of the location of the error, it's more useful combined with `set -x` or the `DEBUG` trap and other Bash debug features, and both flags are normally better set on the command line rather than within the script itself.\ Most of this also applies to the `ERR` trap, though I\'ve seen it used in a few places in shells that lack `pipefail` or `PIPESTATUS`. The `ERR` trap is not POSIX, but `set -e` is. `failglob` is another Bash feature that falls into this category (mainly useful for debugging).\ - **The `set -e` feature generates more questions and false bug reports on the Bash mailing list than all other features combined!** Please do not rely on `set -e` for logic in scripts. If you still refuse to take this advice, make sure you understand **exactly** how it works. See: *[Why doesn\'t set -e (or set -o errexit, or trap ERR) do what I expected?](http://mywiki.wooledge.org/BashFAQ/105)* and + **The `set -e` feature generates more questions and false bug reports on the Bash mailing list than all other features combined!** Please do not rely on `set -e` for logic in scripts. If you still refuse to take this advice, make sure you understand **exactly** how it works. See: *[Why doesn't set -e (or set -o errexit, or trap ERR) do what I expected?](http://mywiki.wooledge.org/BashFAQ/105)* and - `set -u` or `set -o nounset` Proper control flow and error handling `set -u` causes attempts to expand unset variables or parameters as fatal errors. Like `set -e`, it bypasses control flow and exits immediately from the current shell environment. Like non-zero statuses, unset variables are a normal part of most non-trivial shell scripts. Living with `set -u` requires hacks like `${1+"$1"}` for each expansion that might possibly be unset. Only very current shells guarantee that expanding `@` or `*` won\'t trigger an error when no parameters are set (, ). Apparently some find it useful for debugging. See *[How do I determine whether a variable is already defined? Or a function?](http://mywiki.wooledge.org/BashFAQ/083)* for how to properly test for defined variables. Don\'t use `set -u`. + `set -u` or `set -o nounset` Proper control flow and error handling `set -u` causes attempts to expand unset variables or parameters as fatal errors. Like `set -e`, it bypasses control flow and exits immediately from the current shell environment. Like non-zero statuses, unset variables are a normal part of most non-trivial shell scripts. Living with `set -u` requires hacks like `${1+"$1"}` for each expansion that might possibly be unset. Only very current shells guarantee that expanding `@` or `*` won't trigger an error when no parameters are set (, ). Apparently some find it useful for debugging. See *[How do I determine whether a variable is already defined? Or a function?](http://mywiki.wooledge.org/BashFAQ/083)* for how to properly test for defined variables. Don't use `set -u`. `${var?msg}` or `${var:?msg}` Proper control flow and error handling Like `set -u`, this expansion causes a fatal error which immediately exits the current shell environment if the given parameter is unset or is null. It prints the error message given, to the right of the operator. If a value is expected and you\'d like to create an assertion or cause errors, it's better to test for undefined variables using one of [these techniques](http://mywiki.wooledge.org/BashFAQ/083) and handle the error manually, or call a `die` function. This expansion is defined by POSIX. It's better than `set -u`, because it's explicit, but not by much. It also allows you to accidentally construct hilariously deceptive error messages: `bash -c 'f() { definitely_not_printf "${printf:?"$1" - No such option}"; }; f -v' bash: printf: -v - No such option` @@ -59,15 +59,15 @@ portability requirements, or in order to make use of some subtle behavioral differences. These are frequently (mis)used for no reason. Writing portable scripts that go outside of POSIX features requires knowing how to account for many (often undocumented) differences across -many shells. If you do happen to know what you\'re doing, don\'t be too +many shells. If you do happen to know what you\'re doing, don't be too surprised if you run across someone telling you not to use these. Syntax Replacement Description ------------------------------- --------------------------------------------------------------------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- - `function\ NAME\ {\ CMDS;\ }` `NAME()\ COMPOUND-CMD` This is the ksh form of function definition created to extend the Bourne and POSIX form with modified behaviors and additional features like local variables. The idea was for new-style functions to be analogous to regular builtins with their own environment and scope, while POSIX-style functions are more like special builtins. `function` is supported by almost every ksh-derived shell including Bash and Zsh, but isn\'t specified by POSIX. Bash treats all function styles the same, but this is unusual. `function` has some preferable characteristics in many ksh variants, making it more portable for scripts that use non-POSIX extensions by some measures. If you\'re going to use the `function` keyword, it implies that you\'re either targeting Ksh specifically, or that you have detailed knowledge of how to compensate for differences across shells. It should always be used consistently with `typeset`, but never used with `declare` or `local`. Also in ksh93, the braces are not a [command group](../syntax/ccmd/grouping_plain.md), but a required part of the syntax (unlike Bash and others). See [shell function definitions](../syntax/basicgrammar.md#shell_function_definitions) - `typeset` `declare`, `local`, `export`, `readonly` This is closely related to the above, and should often be used together. `typeset` exists primarily for `ksh` compatibility, but is marked as \"deprecated\" in Bash (though I don\'t entirely agree with this). This makes some sense, because future compatibility can\'t be guaranteed, and any compatibility at all, requires understanding the non-POSIX features of other shells and their differences. Using `declare` instead of `typeset` emphasizes your intention to be \"Bash-only\", and definitely breaks everywhere else (except possibly zsh if you\'re lucky). The issue is further complicated by Dash and the [Debian policy](http://www.debian.org/doc/debian-policy/ch-files.html#s-scripts) requirement for a `local` builtin, which is itself not entirely compatible with Bash and other shells. - \'\'let \'EXPR\' \'\' `((EXPR))` or `[\ $((EXPR))\ -ne\ 0 ]` `let` is the \"simple command\" variant of arithmetic evaluation command, which takes regular arguments. Both `let` and `((expr))` were present in ksh88, and everything that supports one should support the other. Neither are POSIX. The compound variant is preferable because it doesn\'t take regular arguments for [wordsplitting](../syntax/expansion/wordsplit.md) and [globbing](../syntax/expansion/globs.md), which makes it safer and clearer. It is also usually faster, especially in Bash, where compound commands are typically significantly faster. Some of the (few) reasons for using `let` are detailed on the [let](../commands/builtin/let.md) page. See [arithmetic evaluation compound command](../syntax/ccmd/arithmetic_eval.md) - `eval` Depends. Often code can be restructured to use better alternatives. `eval` is thrown in here for good measure, as sadly it is so often misused that any use of `eval` (even the rare clever one) is immediately dismissed as wrong by experts, and among the most immediate solutions abused by beginners. In reality, there are correct ways to use `eval`, and even cases in which it's necessary, even in sophisticated shells like Bash and Ksh. `eval` is unusual in that it is less frequently appropriate in more feature-rich shells than in more minimal shells like Dash, where it is used to compensate for more limitations. If you find yourself needing `eval` too frequently, it might be a sign that you\'re either better off using a different language entirely, or trying to borrow an idiom from some other paradigm that isn\'t well suited to the shell language. By the same token, there are some cases in which working too hard to avoid `eval` ends up adding a lot of complexity and sacrificing all portability. Don\'t substitute a clever `eval` for something that's a bit \"too clever\", just to avoid the `eval`, yet, take reasonable measures to avoid it where it is sensible to do so. See: [eval](../commands/builtin/eval.md) and [Eval command and security issues](http://mywiki.wooledge.org/BashFAQ/048). + `function\ NAME\ {\ CMDS;\ }` `NAME()\ COMPOUND-CMD` This is the ksh form of function definition created to extend the Bourne and POSIX form with modified behaviors and additional features like local variables. The idea was for new-style functions to be analogous to regular builtins with their own environment and scope, while POSIX-style functions are more like special builtins. `function` is supported by almost every ksh-derived shell including Bash and Zsh, but isn't specified by POSIX. Bash treats all function styles the same, but this is unusual. `function` has some preferable characteristics in many ksh variants, making it more portable for scripts that use non-POSIX extensions by some measures. If you\'re going to use the `function` keyword, it implies that you\'re either targeting Ksh specifically, or that you have detailed knowledge of how to compensate for differences across shells. It should always be used consistently with `typeset`, but never used with `declare` or `local`. Also in ksh93, the braces are not a [command group](../syntax/ccmd/grouping_plain.md), but a required part of the syntax (unlike Bash and others). See [shell function definitions](../syntax/basicgrammar.md#shell_function_definitions) + `typeset` `declare`, `local`, `export`, `readonly` This is closely related to the above, and should often be used together. `typeset` exists primarily for `ksh` compatibility, but is marked as \"deprecated\" in Bash (though I don't entirely agree with this). This makes some sense, because future compatibility can't be guaranteed, and any compatibility at all, requires understanding the non-POSIX features of other shells and their differences. Using `declare` instead of `typeset` emphasizes your intention to be \"Bash-only\", and definitely breaks everywhere else (except possibly zsh if you\'re lucky). The issue is further complicated by Dash and the [Debian policy](http://www.debian.org/doc/debian-policy/ch-files.html#s-scripts) requirement for a `local` builtin, which is itself not entirely compatible with Bash and other shells. + \'\'let \'EXPR\' \'\' `((EXPR))` or `[\ $((EXPR))\ -ne\ 0 ]` `let` is the \"simple command\" variant of arithmetic evaluation command, which takes regular arguments. Both `let` and `((expr))` were present in ksh88, and everything that supports one should support the other. Neither are POSIX. The compound variant is preferable because it doesn't take regular arguments for [wordsplitting](../syntax/expansion/wordsplit.md) and [globbing](../syntax/expansion/globs.md), which makes it safer and clearer. It is also usually faster, especially in Bash, where compound commands are typically significantly faster. Some of the (few) reasons for using `let` are detailed on the [let](../commands/builtin/let.md) page. See [arithmetic evaluation compound command](../syntax/ccmd/arithmetic_eval.md) + `eval` Depends. Often code can be restructured to use better alternatives. `eval` is thrown in here for good measure, as sadly it is so often misused that any use of `eval` (even the rare clever one) is immediately dismissed as wrong by experts, and among the most immediate solutions abused by beginners. In reality, there are correct ways to use `eval`, and even cases in which it's necessary, even in sophisticated shells like Bash and Ksh. `eval` is unusual in that it is less frequently appropriate in more feature-rich shells than in more minimal shells like Dash, where it is used to compensate for more limitations. If you find yourself needing `eval` too frequently, it might be a sign that you\'re either better off using a different language entirely, or trying to borrow an idiom from some other paradigm that isn't well suited to the shell language. By the same token, there are some cases in which working too hard to avoid `eval` ends up adding a lot of complexity and sacrificing all portability. Don't substitute a clever `eval` for something that's a bit \"too clever\", just to avoid the `eval`, yet, take reasonable measures to avoid it where it is sensible to do so. See: [eval](../commands/builtin/eval.md) and [Eval command and security issues](http://mywiki.wooledge.org/BashFAQ/048). ## See also diff --git a/docs/scripting/posparams.md b/docs/scripting/posparams.md index 11ef49a..dcc95a7 100644 --- a/docs/scripting/posparams.md +++ b/docs/scripting/posparams.md @@ -47,7 +47,7 @@ is the prompt\...): > /usr/bin/testscript /usr/bin/testscript -However, this isn\'t true for login shells: +However, this isn't true for login shells: > echo "$0" -bash @@ -135,7 +135,7 @@ a given wordlist. The loop uses the positional parameters as a wordlist: ------------------------------------------------------------------------ The next method is similar to the first example (the `for` loop), but it -doesn\'t test for reaching `$#`. It shifts and checks if `$1` still +doesn't test for reaching `$#`. It shifts and checks if `$1` still expands to something, using the [test command](../commands/classictest.md): while [ "$1" ] @@ -275,7 +275,7 @@ To make your program accept options as standard command syntax: `COMMAND [options] ` \# Like \'cat -A file.txt\' See simple option parsing code below. It's not that flexible. It -doesn\'t auto-interpret combined options (-fu USER) but it works and is +doesn't auto-interpret combined options (-fu USER) but it works and is a good rudimentary way to parse your arguments. #!/bin/sh @@ -335,7 +335,7 @@ This simple wrapper enables filtering unwanted options (here: `-a` and `--all` for `ls`) out of the command line. It reads the positional parameters and builds a filtered array consisting of them, then calls `ls` with the new option set. It also respects the `--` as \"end of -options\" for `ls` and doesn\'t change anything after it: +options\" for `ls` and doesn't change anything after it: #!/bin/bash diff --git a/docs/scripting/processtree.md b/docs/scripting/processtree.md index 7bb873c..6ece590 100644 --- a/docs/scripting/processtree.md +++ b/docs/scripting/processtree.md @@ -8,7 +8,7 @@ The processes in UNIX(r) are - unlike other systems - **organized as a tree**. Every process has a parent process that started, or is responsible, for it. Every process has its own **context memory** (Not the memory where the process stores its data, rather, the memory where -data is stored that doesn\'t directly belong to the process, but is +data is stored that doesn't directly belong to the process, but is needed to run the process) i.e. [**The environment**]{.underline}. Every process has its **own** environment space. @@ -34,7 +34,7 @@ set by login scripts or programs). All the diagrams of the process tree use names like \"`xterm`\" or \"`bash`\", but that's just to make it easier to understand what's -going on, it doesn\'t mean those processes are actually executed. +going on, it doesn't mean those processes are actually executed. Let's take a short look at what happens when you \"execute a program\" from the Bash prompt, a program like \"ls\": @@ -65,7 +65,7 @@ The copy of the environment from the first step (forking) becomes the environment for the final running program (in this case, `ls`). [**What is so important about it?**]{.underline} In our example, what -the program `ls` does inside its own environment, it can\'t affect the +the program `ls` does inside its own environment, it can't affect the environment of its parent process (in this case, `bash`). The environment was copied when ls was executed. Nothing is \"copied back\" to the parent environment when `ls` terminates. @@ -73,7 +73,7 @@ to the parent environment when `ls` terminates. ## Bash playing with pipes Pipes are a very powerful tool. You can connect the output of one -process to the input of another process. We won\'t delve into piping at +process to the input of another process. We won't delve into piping at this point, we just want to see how it looks in the process tree. Again, we execute some commands, this time, we\'ll run `ls` and `grep`: @@ -85,8 +85,8 @@ It results in a tree like this: xterm ----- bash --| +-- grep -Note once again, `ls` can\'t influence the `grep` environment, `grep` -can\'t influence the `ls` environment, and neither `grep` nor `ls` can +Note once again, `ls` can't influence the `grep` environment, `grep` +can't influence the `ls` environment, and neither `grep` nor `ls` can influence the `bash` environment. [**How is that related to shell programming?!?**]{.underline} @@ -112,10 +112,10 @@ See the relationship? The forked Bash process will count the lines like a charm. It will also set the variable `counter` as directed. But if everything ends, this extra process will be terminated - **your \"counter\" variable is gone.** You see a 0 because in the main shell it -was 0, and wasn\'t changed by the child process! +was 0, and wasn't changed by the child process! [**So, how do we count the lines?**]{.underline} Easy: **Avoid the -subshell.** The details don\'t matter, the important thing is the shell +subshell.** The details don't matter, the important thing is the shell that sets the counter must be the \"main shell\". For example: counter=0 @@ -126,7 +126,7 @@ that sets the counter must be the \"main shell\". For example: It's nearly self-explanatory. The `while` loop runs in the **current shell**, the counter is incremented in the **current shell**, everything vital happens in the **current shell**, also the `read` command sets the -variable `REPLY` (the default if nothing is given), though we don\'t use +variable `REPLY` (the default if nothing is given), though we don't use it here. ## Actions that create a subshell @@ -140,10 +140,10 @@ As shown above, Bash will create subprocesses everytime it executes commands. That's nothing new. But if your command is a subprocess that sets variables you want to use -in your main script, that won\'t work. +in your main script, that won't work. For exactly this purpose, there's the `source` command (also: the *dot* -`.` command). Source doesn\'t execute the script, it imports the other +`.` command). Source doesn't execute the script, it imports the other script's code into the current shell: source ./myvariables.sh diff --git a/docs/scripting/style.md b/docs/scripting/style.md index 8db6c12..d30b5bb 100644 --- a/docs/scripting/style.md +++ b/docs/scripting/style.md @@ -10,8 +10,8 @@ it\". This is not a bible, of course. But I have seen so much ugly and terrible code (not only in shell) during all the years, that I\'m 100% convinced there needs to be *some* code layout and style. No matter -which one you use, use it throughout your code (at least don\'t change -it within the same shellscript file); don\'t change your code layout +which one you use, use it throughout your code (at least don't change +it within the same shellscript file); don't change your code layout with your mood. Some good code layout helps you to read your own code after a while. And @@ -203,7 +203,7 @@ in-code documentation for them. Unless you are really sure what you\'re doing, **quote every parameter expansion**. -There are some cases where this isn\'t needed from a technical point of +There are some cases where this isn't needed from a technical point of view, e.g. - inside `[[ ... ]]` (other than the RHS of the `==`, `!=`, and `=~` @@ -214,7 +214,7 @@ view, e.g. But quoting these is never a mistake. If you quote every parameter expansion, you\'ll be safe. -If you need to parse a parameter as a list of words, you can\'t quote, +If you need to parse a parameter as a list of words, you can't quote, of course, e.g. list="one two three" @@ -260,7 +260,7 @@ Avoid it, unless absolutely neccesary: - `eval` can be your neckshot - there are most likely other ways to achieve what you want - if possible, re-think the way your script works, if it seems you - can\'t avoid `eval` with your current method + can't avoid `eval` with your current method - if you really, really, have to use it, then take care, and be sure about what you\'re doing @@ -309,7 +309,7 @@ declared before the main script code runs. This gives a far better overview and ensures that all function names are known before they are used. -Since a function isn\'t parsed before it is executed, you usually don\'t +Since a function isn't parsed before it is executed, you usually don't have to ensure they\'re in a specific order. The portable form of the function definition should be used, without the @@ -321,7 +321,7 @@ command](../syntax/ccmd/grouping_plain.md)): } Speaking about the command grouping in function definitions using -`{ ...; }`: If you don\'t have a good reason to use another compound +`{ ...; }`: If you don't have a good reason to use another compound command directly, you should always use this one. ## Behaviour and robustness diff --git a/docs/scripting/terminalcodes.md b/docs/scripting/terminalcodes.md index 6433790..4492a15 100644 --- a/docs/scripting/terminalcodes.md +++ b/docs/scripting/terminalcodes.md @@ -4,13 +4,13 @@ Terminal (control) codes are used to issue specific commands to your terminal. This can be related to switching colors or positioning the -cursor, i.e. anything that can\'t be done by the application itself. +cursor, i.e. anything that can't be done by the application itself. ## How it technically works A terminal control code is a special sequence of characters that is printed (like any other text). If the terminal understands the code, it -won\'t display the character-sequence, but will perform some action. You +won't display the character-sequence, but will perform some action. You can print the codes with a simple `echo` command. [**Note:**]{.underline} I see codes referenced as \"Bash colors\" @@ -43,11 +43,11 @@ I listed only the most relevant codes, of course, any ANSI terminal understands many more! But let's keep the discussion centered on common shell scripting ;-) -If I couldn\'t find a matching ANSI escape, you\'ll see a :?: as the +If I couldn't find a matching ANSI escape, you\'ll see a :?: as the code. Feel free to mail me or fix it. The ANSI codes always start with the ESC character. (ASCII 0x1B or octal -033) This isn\'t part of the list, but **you should avoid using the ANSI +033) This isn't part of the list, but **you should avoid using the ANSI codes directly - use the `tput` command!** All codes that can be used with `tput` can be found in terminfo(5). (on @@ -178,7 +178,7 @@ termcap/terminfo. While `xterm` and most of its clones (`rxvt`, `urxvt`, etc) will support the instructions, your operating system may not include references to them in its default xterm profile. (FreeBSD, in particular, falls into this category.) If \`tput smcup\` appears to do -nothing for you, and you don\'t want to modify your system +nothing for you, and you don't want to modify your system termcap/terminfo data, and you KNOW that you are using a compatible xterm application, the following may work for you: @@ -210,7 +210,7 @@ terminals](https://gist.github.com/XVilka/8346728#now-supporting-truecolour) also support full 24-bit colors, and any X11 color code can be written directly into a special escape sequence. ([More infos](https://gist.github.com/XVilka/8346728)) Only a few programs make -use of anything beyond 256 colors, and tput doesn\'t know about them. +use of anything beyond 256 colors, and tput doesn't know about them. Colors beyond 16 usually only apply to modern terminal emulators running in graphical environments. @@ -304,7 +304,7 @@ at most 16, and reduces raw output by more than half. The `doBash` function uses integer arithmetic, but is still ksh93-compatible (run as e.g. `bash ./mandelbrot` to use it). The ksh93-only floating-point `doKsh` is almost 10x faster than `doBash` (thus the ksh shebang by -default), but uses only features that don\'t make the Bash parser crash. +default), but uses only features that don't make the Bash parser crash. #!/usr/bin/env ksh diff --git a/docs/snipplets/add_color_to_your_scripts.md b/docs/snipplets/add_color_to_your_scripts.md index d1dd952..f25442c 100644 --- a/docs/snipplets/add_color_to_your_scripts.md +++ b/docs/snipplets/add_color_to_your_scripts.md @@ -8,7 +8,7 @@ type : snipplet Make your scripts output more readable using bash colors. Simply add these variables to your script, and you will be able to echo in color. -(I haven\'t added all the colors available, just some basics) +(I haven't added all the colors available, just some basics) # Colors ESC_SEQ="\x1b[" diff --git a/docs/snipplets/awkcsv.md b/docs/snipplets/awkcsv.md index 033f338..241f59d 100644 --- a/docs/snipplets/awkcsv.md +++ b/docs/snipplets/awkcsv.md @@ -14,7 +14,7 @@ data fields that can contain the delimiter. "fir,st", "second", "last" "firtst one", "sec,ond field", "final,ly" -Simply using the comma as separator for `awk` won\'t work here, of +Simply using the comma as separator for `awk` won't work here, of course. Solution: Use the field separator `", "|^"|"$` for `awk`. @@ -28,7 +28,7 @@ This is an OR-ed list of 3 possible separators: -------- ----------------------------------------------- You can tune these delimiters if you have other needs (for example if -you don\'t have a space after the commas). +you don't have a space after the commas). Test: diff --git a/docs/snipplets/kill_bg_job_without_message.md b/docs/snipplets/kill_bg_job_without_message.md index e7d6183..996382b 100644 --- a/docs/snipplets/kill_bg_job_without_message.md +++ b/docs/snipplets/kill_bg_job_without_message.md @@ -31,7 +31,7 @@ You will get something like this: ./bg_kill1.sh: line 11: 3413 Killed sleep 300 Yes, we killed it -This is more or less a normal message. And it can\'t be easily +This is more or less a normal message. And it can't be easily redirected since it's the shell itself that yells this message, not the command `kill` or something else. You would have to redirect the whole script's output. diff --git a/docs/snipplets/print_horizontal_line.md b/docs/snipplets/print_horizontal_line.md index 1ad267b..e33c795 100644 --- a/docs/snipplets/print_horizontal_line.md +++ b/docs/snipplets/print_horizontal_line.md @@ -98,7 +98,7 @@ principle as this [string reverse example](../commands/builtin/eval.md#expansion_side-effects). It completely depends on Bash due to its brace expansion evaluation order and array parameter parsing details. As above, the eval only inserts the COLUMNS -expansion into the expression and isn\'t involved in the rest, other +expansion into the expression and isn't involved in the rest, other than to put the `_` value into the environment of the `_[0]` expansion. This works well since we\'re not creating one set of arguments and then editing or deleting them to create another as in the previous examples. diff --git a/docs/snipplets/rndstr.md b/docs/snipplets/rndstr.md index a6abdcb..d72bb86 100644 --- a/docs/snipplets/rndstr.md +++ b/docs/snipplets/rndstr.md @@ -65,7 +65,7 @@ rndstr() \ -The remaining examples don\'t use quite the same tricks, which will +The remaining examples don't use quite the same tricks, which will hopefully be explained elsewhere eventually. See [unset](../commands/builtin/unset.md#scope) for why doing assignments in this way works well. @@ -108,10 +108,10 @@ modifier instructs printf to use the value preceding each parameter as the field width. Note the space between the parameters. This example unfortunately relies upon the unquoted command substitution to perform unsafe wordsplitting so that the outer printf gets each argument. Values -in the array can\'t contain characters in IFS, or anything that might be +in the array can't contain characters in IFS, or anything that might be interpreted as a pattern without using `set -f`. -Lastly, empty brace expansions can be used which don\'t generate any +Lastly, empty brace expansions can be used which don't generate any output that would need to be filtered. The disadvantage of course is that you must construct the brace expansion syntax to add up to the number of arguments to be generated, where the most optimal solution is diff --git a/docs/snipplets/ssh_fetchkeys.md b/docs/snipplets/ssh_fetchkeys.md index b9c1e49..e9de8be 100644 --- a/docs/snipplets/ssh_fetchkeys.md +++ b/docs/snipplets/ssh_fetchkeys.md @@ -8,7 +8,7 @@ LastUpdate_dt: 2010-07-31 Contributors: Jan Schampera Applies at least to `openssh`. To get the hostkeys for a server, and write them to `known_hosts`-file -(to avoid that yes/no query when the key isn\'t known), you can do: +(to avoid that yes/no query when the key isn't known), you can do: ssh-keyscan -t rsa foo foo.example.com 1.2.3.4 >> ~/.ssh/known_host diff --git a/docs/syntax/arith_expr.md b/docs/syntax/arith_expr.md index 0c8b3b0..2e50bae 100644 --- a/docs/syntax/arith_expr.md +++ b/docs/syntax/arith_expr.md @@ -91,7 +91,7 @@ mean: bash: 43#H: value too great for base (error token is "43#H") If you have no clue what a base is and why there might be other bases, -and what numbers are and how they are built, then you don\'t need +and what numbers are and how they are built, then you don't need different bases. If you want to convert between the usual bases (octal, decimal, hex), @@ -103,7 +103,7 @@ strings. Shell variables can of course be used as operands, even when the integer attribute is not turned on (by `declare -i `). If the variable is empty (null) or unset, its reference evaluates to 0. If the variable -doesn\'t hold a value that looks like a valid expression (numbers or +doesn't hold a value that looks like a valid expression (numbers or operations), the expression is re-used to reference, for example, the named parameters, e.g.: @@ -265,7 +265,7 @@ codes of commands or functions to be executed. `if` statements, `while` loops, etc., they all take the return codes of commands as conditions. Now the problem is: The return codes (0 means \"TRUE\" or \"SUCCESS\", -not 0 means \"FALSE\" or \"FAILURE\") don\'t correspond to the meaning +not 0 means \"FALSE\" or \"FAILURE\") don't correspond to the meaning of the result of an arithmetic expression (0 means \"FALSE\", not 0 means \"TRUE\"). diff --git a/docs/syntax/arrays.md b/docs/syntax/arrays.md index 9739322..cd4c399 100644 --- a/docs/syntax/arrays.md +++ b/docs/syntax/arrays.md @@ -43,7 +43,7 @@ Bash supports two different types of ksh-like one-dimensional arrays. arrays allow you to look up a value from a table based upon its corresponding string label. **Associative arrays are always unordered**, they merely *associate* key-value pairs. If you - retrieve multiple values from the array at once, you can\'t count on + retrieve multiple values from the array at once, you can't count on them coming out in the same order you put them in. Associative arrays always carry the `-A` attribute, and unlike indexed arrays, Bash requires that they always be declared explicitly (as indexed @@ -127,7 +127,7 @@ variables. `ARRAY+=(E1\ E2\ ...)` Append to ARRAY. `ARRAY=("${ANOTHER_ARRAY[@]}")` Copy ANOTHER_ARRAY to ARRAY, copying each element. -As of now, arrays can\'t be exported. +As of now, arrays can't be exported. ### Getting values @@ -137,7 +137,7 @@ check the notes about arrays. \ Syntax Description ----------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- - `${ARRAY[N]}` Expands to the value of the index `N` in the **indexed** array `ARRAY`. If `N` is a negative number, it's treated as the offset from the maximum assigned index (can\'t be used for assignment) - 1 + `${ARRAY[N]}` Expands to the value of the index `N` in the **indexed** array `ARRAY`. If `N` is a negative number, it's treated as the offset from the maximum assigned index (can't be used for assignment) - 1 `${ARRAY[S]}` Expands to the value of the index `S` in the **associative** array `ARRAY`. `"${ARRAY[@]}" ${ARRAY[@]} "${ARRAY[*]}" ${ARRAY[*]}` Similar to [mass-expanding positional parameters](../scripting/posparams.md#mass_usage), this expands to all elements. If unquoted, both subscripts `*` and `@` expand to the same result, if quoted, `@` expands to all elements individually quoted, `*` expands to all elements quoted as a whole. `"${ARRAY[@]:N:M}" ${ARRAY[@]:N:M} "${ARRAY[*]:N:M}" ${ARRAY[*]:N:M}` Similar to what this syntax does for the characters of a single string when doing [substring expansion](../syntax/pe.md#substring_expansion), this expands to `M` elements starting with element `N`. This way you can mass-expand individual indexes. The rules for quoting and the subscripts `*` and `@` are the same as above for the other mass-expansions. @@ -246,7 +246,7 @@ sometimes. Please understand that **numerical array indexing begins at 0 The method above, walking through an array by just knowing its number of elements, only works for arrays where all elements are set, of course. If one element in the middle is removed, then the calculation is -nonsense, because the number of elements doesn\'t correspond to the +nonsense, because the number of elements doesn't correspond to the highest used index anymore (we call them \"*sparse arrays*\"). Now, suppose that you want to replace your array `sentence` with the @@ -297,7 +297,7 @@ starting at zero) just is replaced with an arbitrary string: sentence[End]='in what you send' sentence['Very end']=... -[**Beware:**]{.underline} don\'t rely on the fact that the elements are +[**Beware:**]{.underline} don't rely on the fact that the elements are ordered in memory like they were declared, it could look like this: # output from 'set' command @@ -305,7 +305,7 @@ ordered in memory like they were declared, it could look like this: This effectively means, you can get the data back with `"${sentence[@]}"`, of course (just like with numerical indexing), but -you can\'t rely on a specific order. If you want to store ordered data, +you can't rely on a specific order. If you want to store ordered data, or re-order data, go with numerical indexes. For associative arrays, you usually query known index values: @@ -479,7 +479,7 @@ dynamically calls a function whose name is resolved from the array. prior to assignment. In order to preserve attributes, you must use the `+=` operator. However, declaring an associative array, then attempting an `a=(...)` style compound assignment without specifying - indexes is an error. I can\'t explain this + indexes is an error. I can't explain this inconsistency.` $ ksh -c 'function f { typeset -a a; a=([0]=foo [1]=bar); typeset -p a; }; f' # Attribute is lost, and since subscripts are given, we default to associative. typeset -A a=([0]=foo [1]=bar) $ ksh -c 'function f { typeset -a a; a+=([0]=foo [1]=bar); typeset -p a; }; f' # Now using += gives us the expected results. @@ -490,7 +490,7 @@ dynamically calls a function whose name is resolved from the array. - Only Bash and mksh support compound assignment with mixed explicit subscripts and automatically incrementing subscripts. In ksh93, in order to specify individual subscripts within a compound assignment, - all subscripts must be given (or none). Zsh doesn\'t support + all subscripts must be given (or none). Zsh doesn't support specifying individual subscripts at all. - Appending to a compound assignment is a fairly portable way to append elements after the last index of an array. In Bash, this also @@ -526,7 +526,7 @@ dynamically calls a function whose name is resolved from the array. portability. - Zsh and mksh do not support compound assignment arguments to `typeset`. -- Ksh88 didn\'t support modern compound array assignment syntax. The +- Ksh88 didn't support modern compound array assignment syntax. The original (and most portable) way to assign multiple elements is to use the `set -A name arg1 arg2 ...` syntax. This is supported by almost all shells that support ksh-like arrays except for Bash. @@ -563,9 +563,9 @@ dynamically calls a function whose name is resolved from the array. - Assigning or referencing negative indexes in mksh causes wrap-around. The max index appears to be `UINT_MAX`, which would be addressed by `arr[-1]`. -- So far, Bash's `-v var` test doesn\'t support individual array +- So far, Bash's `-v var` test doesn't support individual array subscripts. You may supply an array name to test whether an array is - defined, but can\'t check an element. ksh93's `-v` supports both. + defined, but can't check an element. ksh93's `-v` supports both. Other shells lack a `-v` test. ### Bugs @@ -608,7 +608,7 @@ dynamically calls a function whose name is resolved from the array. ` - **Fixed in 4.3** Process substitutions are evaluated within array - indexes. Zsh and ksh don\'t do this in any arithmetic context. + indexes. Zsh and ksh don't do this in any arithmetic context. `# print "moo" dev=fd=1 _[1<(echo moo >&2)]= diff --git a/docs/syntax/basicgrammar.md b/docs/syntax/basicgrammar.md index 6554637..39d44c0 100644 --- a/docs/syntax/basicgrammar.md +++ b/docs/syntax/basicgrammar.md @@ -7,7 +7,7 @@ code you see everywhere, the code you use, is based on those rules. However, **this is a very theoretical view**, but if you\'re interested, it may help you understand why things look the way they look. -If you don\'t know the commands used in the following examples, just +If you don't know the commands used in the following examples, just trust the explanation. ## Simple Commands @@ -29,7 +29,7 @@ Every complex Bash operation can be split into simple commands: LC_ALL=C ls The last one might not be familiar. That one simply adds \"`LC_ALL=C`\" -to the environment of the `ls` program. It doesn\'t affect your current +to the environment of the `ls` program. It doesn't affect your current shell. This also works while calling functions, unless Bash runs in POSIX(r) mode (in which case it affects your current shell). @@ -50,8 +50,8 @@ FIXME Missing an additional article about pipelines and pipelining `[time [-p]] [ ! ] command [ | command2 ... ]` -**Don\'t get confused** about the name \"pipeline.\" It's a grammatic -name for a construct. Such a pipeline isn\'t necessarily a pair of +**Don't get confused** about the name \"pipeline.\" It's a grammatic +name for a construct. Such a pipeline isn't necessarily a pair of commands where stdout/stdin is connected via a real pipe. Pipelines are one or more [simple @@ -254,14 +254,14 @@ It is possible to create function names containing slashes: echo LS FAKE } -The elements of this name aren\'t subject to a path search. +The elements of this name aren't subject to a path search. Weird function names should not be used. Quote from the maintainer: - * It was a mistake to allow such characters in function names - (\`unset\' doesn\'t work to unset them without forcing -f, for + (\`unset\' doesn't work to unset them without forcing -f, for instance). We\'re stuck with them for backwards compatibility, but I - don\'t have to encourage their use. * + don't have to encourage their use. * ## Grammar summary diff --git a/docs/syntax/ccmd/c_for.md b/docs/syntax/ccmd/c_for.md index e41f820..166de33 100644 --- a/docs/syntax/ccmd/c_for.md +++ b/docs/syntax/ccmd/c_for.md @@ -68,7 +68,7 @@ command](../../syntax/ccmd/arithmetic_eval.md) would be structured as: (( )) done -The equivalent `while` construct isn\'t exactly the same, because both, +The equivalent `while` construct isn't exactly the same, because both, the `for` and the `while` loop behave differently in case you use the [continue](../../commands/builtin/continuebreak.md) command. @@ -83,7 +83,7 @@ Bash, Ksh93, Mksh, and Zsh also provide an alternate syntax for the echo $x } -This syntax is **not documented** and shouldn\'t be used. I found the +This syntax is **not documented** and shouldn't be used. I found the parser definitions for it in 1.x code, and in modern 4.x code. My guess is that it's there for compatibility reasons. Unlike the other aforementioned shells, Bash does not support the analogous syntax for @@ -220,16 +220,16 @@ variables. ## Portability considerations -- C-style for loops aren\'t POSIX. They are available in Bash, ksh93, +- C-style for loops aren't POSIX. They are available in Bash, ksh93, and zsh. All 3 have essentially the same syntax and behavior. -- C-style for loops aren\'t available in mksh. +- C-style for loops aren't available in mksh. ## Bugs - *Fixed in 4.3*. ~~There appears to be a bug as of Bash 4.2p10 in - which command lists can\'t be distinguished from the for loop's + which command lists can't be distinguished from the for loop's arithmetic argument delimiter (both semicolons), so command - substitutions within the C-style for loop expression can\'t contain + substitutions within the C-style for loop expression can't contain more than one command.~~ ## See also diff --git a/docs/syntax/ccmd/case.md b/docs/syntax/ccmd/case.md index ef7d0c5..e273a80 100644 --- a/docs/syntax/ccmd/case.md +++ b/docs/syntax/ccmd/case.md @@ -25,9 +25,9 @@ Bash 4 introduces two new action terminators. The classic behavior using `;;` is to execute only the list associated with the first matching pattern, then break out of the `case` block. The `;&` terminator causes `case` to also execute the next block without testing its pattern. The -`;;&` operator is like `;;`, except the case statement doesn\'t +`;;&` operator is like `;;`, except the case statement doesn't terminate after executing the associated list - Bash just continues -testing the next pattern as though the previous pattern didn\'t match. +testing the next pattern as though the previous pattern didn't match. Using these terminators, a `case` statement can be configured to test against all patterns, or to share code between blocks, for example. @@ -74,7 +74,7 @@ Another one of my stupid examples\... echo 'Hm, a bit awry, no?' ;; orange|tangerine) - echo $'Eeeks! I don\'t like those!\nGo away!' + echo $'Eeeks! I don't like those!\nGo away!' exit 1 ;; *) @@ -153,7 +153,7 @@ f a b c and close braces may be used in place of `in` and `esac`: `case word { x) ...; };`. This is similar to the alternate form Bash supports for its [for loops](../../syntax/ccmd/classic_for.md), but Bash - doesn\'t support this syntax for `case..esac`. + doesn't support this syntax for `case..esac`. ## See also diff --git a/docs/syntax/ccmd/conditional_expression.md b/docs/syntax/ccmd/conditional_expression.md index a6085da..ef84edd 100644 --- a/docs/syntax/ccmd/conditional_expression.md +++ b/docs/syntax/ccmd/conditional_expression.md @@ -8,7 +8,7 @@ The conditional expression is meant as the modern variant of the [classic test command](../../commands/classictest.md). Since it is **not** a -normal command, Bash doesn\'t need to apply the normal commandline +normal command, Bash doesn't need to apply the normal commandline parsing rules like recognizing `&&` as [command list](../../syntax/basicgrammar.md#lists) operator. @@ -153,7 +153,7 @@ Example: 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 +same primitives for the builtin test command don't. This leads to the following situation where they behave differently: $ ./cond.sh @@ -162,7 +162,7 @@ following situation where they behave differently: [ ' 4' \< '1' ] --> exit 0 [ 'step+' \< 'step-' ] --> exit 0 -It won\'t be aligned. The conditional expression continues to respect +It won't be aligned. The conditional expression continues to respect the locate, as introduced with 4.1-alpha, the builtin `test`/`[` command continues to behave differently. @@ -178,7 +178,7 @@ both contains whitespace and is not the result of an expansion. ## Portability considerations -- `[[ ... ]]` functionality isn\'t specified by POSIX(R), though it's +- `[[ ... ]]` functionality isn't specified by POSIX(R), though it's a reserved word - Amongst the major \"POSIX-shell superset languages\" (for lack of a better term) which do have `[[`, the test expression compound @@ -192,7 +192,7 @@ both contains whitespace and is not the result of an expansion. - As an extension to POSIX ERE, most GNU software supports backreferences in ERE, including Bash. According to POSIX, only BRE is supposed to support them. This requires Bash to be linked against - glibc, so it won\'t necessarily work on all platforms. For example, + glibc, so it won't necessarily work on all platforms. For example, `$(m='(abc(def))(\1)(\2)'; [[ abcdefabcdefdef =~ $m ]]; printf '<%s> ' $? "${BASH_REMATCH[@]}" )` will give `<0> `. - the `=~` (regex) operator was introduced in Bash 3.0, and its diff --git a/docs/syntax/expansion/arith.md b/docs/syntax/expansion/arith.md index fd1bac9..de86785 100644 --- a/docs/syntax/expansion/arith.md +++ b/docs/syntax/expansion/arith.md @@ -26,7 +26,7 @@ function printSum { } ``` -**Note** that in Bash you don\'t need the arithmetic expansion to check +**Note** that in Bash you don't need the arithmetic expansion to check for the boolean value of an arithmetic expression. This can be done using the [arithmetic evaluation compound command](../../syntax/ccmd/arithmetic_eval.md): @@ -58,7 +58,7 @@ echo $(($x[0])) # Error. This expands to $((1[0])), an invalid expression. ## Bugs and Portability considerations -- The original Bourne shell doesn\'t have arithmetic expansions. You +- The original Bourne shell doesn't have arithmetic expansions. You have to use something like `expr(1)` within backticks instead. Since `expr` is horrible (as are backticks), and arithmetic expansion is required by POSIX, you should not worry about this, and preferably diff --git a/docs/syntax/expansion/brace.md b/docs/syntax/expansion/brace.md index f99f9f0..6e558eb 100644 --- a/docs/syntax/expansion/brace.md +++ b/docs/syntax/expansion/brace.md @@ -34,7 +34,7 @@ Another common pitfall is to assume that a range like `{1..200}` can be expressed with variables using `{$a..$b}`. Due to what I described above, it **simply is not possible**, because it's the very first step in doing expansions. A possible way to achieve this, if you really -can\'t handle this in another way, is using the `eval` command, which +can't handle this in another way, is using the `eval` command, which basically evaluates a commandline twice: `eval echo {$a..$b}` For instance, when embedded inside a for loop : `for i in $(eval echo {$a..$b})` This requires that the entire command @@ -78,7 +78,7 @@ With prefix or suffix strings, the result is a space-separated list of The brace expansion is only performed, if the given string list is really a **list of strings**, i.e., if there is a minimum of one \"`,`\" -(comma)! Something like `{money}` doesn\'t expand to something special, +(comma)! Something like `{money}` doesn't expand to something special, it's really only the text \"`{money}`\". ## Ranges @@ -160,7 +160,7 @@ then the lowercase ones: In this example, `wget` is used to download documentation that is split over several numbered webpages. -`wget` won\'t see your braces. It will see **6 different URLs** to +`wget` won't see your braces. It will see **6 different URLs** to download. wget http://docs.example.com/documentation/slides_part{1,2,3,4,5,6}.html diff --git a/docs/syntax/expansion/globs.md b/docs/syntax/expansion/globs.md index ae37b78..b84bdde 100644 --- a/docs/syntax/expansion/globs.md +++ b/docs/syntax/expansion/globs.md @@ -26,7 +26,7 @@ other `IFS`-characters they contain. be matched explicitly - the dot at the beginning of a filename must be matched explicitly (also one following a `/` in the glob) -- a glob that doesn\'t match a filename is unchanged and remains what +- a glob that doesn't match a filename is unchanged and remains what it is ## Customization @@ -42,8 +42,8 @@ other `IFS`-characters they contain. - when the shell option `dirspell` is set, Bash performs spelling corrections when matching directory names - when the shell option `globstar` is set, the glob `**` will - recursively match all files and directories. This glob isn\'t - \"configurable\", i.e. you **can\'t** do something like `**.c` to + recursively match all files and directories. This glob isn't + \"configurable\", i.e. you **can't** do something like `**.c` to recursively get all `*.c` filenames. - when the shell option `globasciiranges` is set, the bracket-range globs (e.g. `[A-Z]`) use C locale order rather than the configured @@ -80,7 +80,7 @@ with an error, since no file named `*.txt` exists. Now, when the shell option `nullglob` is set, Bash will remove the entire glob from the command line. In case of the for-loop here, not -even one iteration will be done. It just won\'t run. +even one iteration will be done. It just won't run. So in our first example: diff --git a/docs/syntax/expansion/intro.md b/docs/syntax/expansion/intro.md index f732172..cb1e3d4 100644 --- a/docs/syntax/expansion/intro.md +++ b/docs/syntax/expansion/intro.md @@ -14,7 +14,7 @@ The most simple example of this behaviour is a referenced variable: mystring="Hello world" echo "$mystring" -The `echo` program definitely doesn\'t care about what a shell variable +The `echo` program definitely doesn't care about what a shell variable is. It is Bash's job to deal with the variable. Bash **expands** the string \"`$mystring`\" to \"`Hello world`\", so that `echo` will only see `Hello world`, not the variable or anything else! @@ -22,12 +22,12 @@ see `Hello world`, not the variable or anything else! After all these expansions and substitutions are done, all quotes that are not meant literally (i.e., [the quotes that marked contiguous words](../../syntax/quoting.md), as part of the shell syntax) are removed from -the commandline text, so the called program won\'t see them. This step +the commandline text, so the called program won't see them. This step is called **quote-removal**. ## Overview -Saw a possible expansion syntax but don\'t know what it is? Here's a +Saw a possible expansion syntax but don't know what it is? Here's a small list. - [Parameter expansion](../../syntax/pe.md) (it has its own [overview diff --git a/docs/syntax/expansion/proc_subst.md b/docs/syntax/expansion/proc_subst.md index ad86cfa..7b558df 100644 --- a/docs/syntax/expansion/proc_subst.md +++ b/docs/syntax/expansion/proc_subst.md @@ -24,8 +24,8 @@ is connected to a FIFO or a file in `/dev/fd/`. The filename (where the filedescriptor is connected) is then used as a substitution for the `<(...)`-construct. -That, for example, allows to give data to a command that can\'t be -reached by pipelining (that doesn\'t expect its data from `stdin` but +That, for example, allows to give data to a command that can't be +reached by pipelining (that doesn't expect its data from `stdin` but from a file). ### Scope @@ -53,7 +53,7 @@ the caller when the callee returns. In essence, process substitutions expanded to variables within functions remain open until the function in which the process substitution occured returns - even when assigned to locals that were set by a function's -caller. Dynamic scope doesn\'t protect them from closing. +caller. Dynamic scope doesn't protect them from closing. ## Examples @@ -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 @@ -88,7 +88,7 @@ where those files are written to and destroyed automatically. \ 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?* \ +the loop terminates? Or, why can't I pipe data to read?* \ One of the most common uses for process substitutions is to avoid the final subshell that results from executing a pipeline. The following is @@ -159,7 +159,7 @@ See the above section on [#scope](#scope) - Process substitution is supported only on systems that support either named pipes (FIFO - a [special file](../../dict/terms/special_file.md)) or the `/dev/fd/*` method for - accessing open files. If the system doesn\'t support `/dev/fd/*`, + accessing open files. If the system doesn't support `/dev/fd/*`, Bash falls back to creating named pipes. Note that not all shells that support process substitution have that fallback. - Bash evaluates process substitutions within array indices, but not diff --git a/docs/syntax/expansion/tilde.md b/docs/syntax/expansion/tilde.md index fbb0726..085657d 100644 --- a/docs/syntax/expansion/tilde.md +++ b/docs/syntax/expansion/tilde.md @@ -39,7 +39,7 @@ Tilde expansion is also performed everytime a variable is assigned: echo foo=~ echo foo=:~ -I don\'t know yet, if this is a bug or intended. \ +I don't know yet, if this is a bug or intended. \ This way you can correctly use the tilde expansion in your [PATH](../../syntax/shellvars.md#PATH): @@ -60,8 +60,8 @@ This way you can correctly use the tilde expansion in your This form expands to the home-directory of the current user (`~`) or the home directory of the given user (`~`). -If the given user doesn\'t exist (or if his home directory isn\'t -determinable, for some reason), it doesn\'t expand to something else, it +If the given user doesn't exist (or if his home directory isn't +determinable, for some reason), it doesn't expand to something else, it stays what it is. The requested home directory is found by asking the operating system for the associated home directory for ``. diff --git a/docs/syntax/expansion/wordsplit.md b/docs/syntax/expansion/wordsplit.md index 775283b..a6b57a0 100644 --- a/docs/syntax/expansion/wordsplit.md +++ b/docs/syntax/expansion/wordsplit.md @@ -31,14 +31,14 @@ The results of the expansions mentioned above are scanned for `IFS`-characters. If **one or more** (in a sequence) of them is found, the expansion result is split at these positions into multiple words. -This doesn\'t happen when the expansion results were **double-quoted**. +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 `""`). [**Again note:**]{.underline} Without any expansion beforehand, Bash -won\'t perform word splitting! In this case, the initial token parsing +won't perform word splitting! In this case, the initial token parsing is solely responsible. ## See also diff --git a/docs/syntax/grammar/parser_exec.md b/docs/syntax/grammar/parser_exec.md index 951ed5c..7cf6e9d 100644 --- a/docs/syntax/grammar/parser_exec.md +++ b/docs/syntax/grammar/parser_exec.md @@ -113,7 +113,7 @@ As of Bash Version 4, when a command search fails, the shell executes a shell function named `command_not_found_handle()` using the failed command as arguments. This can be used to provide user friendly messages or install software packages etc. Since this function runs in a separate -execution environment, you can\'t really influence the main shell with +execution environment, you can't really influence the main shell with it (changing directory, setting variables). FIXME to be continued diff --git a/docs/syntax/keywords/coproc.md b/docs/syntax/keywords/coproc.md index 7778806..bb37512 100644 --- a/docs/syntax/keywords/coproc.md +++ b/docs/syntax/keywords/coproc.md @@ -100,7 +100,7 @@ nothing read ``` Even though this example is the same as the first `awk` example, the -`read` doesn\'t return because the output is waiting in a buffer. +`read` doesn't return because the output is waiting in a buffer. See [this faq entry on Greg's wiki](http://mywiki.wooledge.org/BashFAQ/009) for some workarounds and @@ -147,7 +147,7 @@ Here, fd 3 is inherited. ### Anonymous Coprocess -Unlike ksh, Bash doesn\'t have true anonymous coprocesses. Instead, Bash +Unlike ksh, Bash doesn't have true anonymous coprocesses. Instead, Bash assigns FDs to a default array named `COPROC` if no `NAME` is supplied. Here's an example: @@ -171,7 +171,7 @@ $ IFS= read -ru ${COPROC[0]} x; printf '%s\n' "$x" foobar ``` -When we don\'t need our command anymore, we can kill it via its pid: +When we don't need our command anymore, we can kill it via its pid: $ kill $COPROC_PID $ @@ -229,7 +229,7 @@ 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 `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 +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 which point it can be accessed at the new FD using ordinary redirection, and another coprocess may then be started, again using `|&`. diff --git a/docs/syntax/pe.md b/docs/syntax/pe.md index 8bbf270..47b7402 100644 --- a/docs/syntax/pe.md +++ b/docs/syntax/pe.md @@ -168,9 +168,9 @@ It was an unfortunate design decision to use the `!` prefix for indirection, as it introduces parsing ambiguity with other parameter expansions that begin with `!`. Indirection is not possible in combination with any parameter expansion whose modifier requires a -prefix to the parameter name. Specifically, indirection isn\'t possible +prefix to the parameter name. Specifically, indirection isn't possible on the `${!var@}`, `${!var*}`, `${!var[@]}`, `${!var[*]}`, and `${#var}` -forms. This means the `!` prefix can\'t be used to retrieve the indices +forms. This means the `!` prefix can't be used to retrieve the indices of an array, the length of a string, or number of elements in an array indirectly (see [syntax/arrays#indirection](../syntax/arrays.md#indirection) for workarounds). Additionally, the `!`-prefixed parameter expansion @@ -401,9 +401,9 @@ example string: `Be liberal in what you accept, and conservativehappy in what you send` Since there is only one \"conservative\" in that example, it really -doesn\'t matter which of the two forms we use. +doesn't matter which of the two forms we use. -Let's play with the word \"in\", I don\'t know if it makes any sense, +Let's play with the word \"in\", I don't know if it makes any sense, but let's substitute it with \"by\". [**First form: Substitute first occurrence**]{.underline} @@ -491,7 +491,7 @@ Assume: `array=(This is a text)` [**Attention:**]{.underline} The number of used elements does not need to conform to the highest index. Sparse arrays are possible in Bash, that means you can have 4 elements, but with indexes 1, 7, 20, 31. **You -can\'t loop through such an array with a counter loop based on the +can't loop through such an array with a counter loop based on the number of elements!** ## Substring expansion @@ -603,7 +603,7 @@ useful, you need to put that parameter syntax in. read -p "Enter your gender (just press ENTER to not tell us): " GENDER echo "Your gender is ${GENDER:-a secret}." -It will print \"Your gender is a secret.\" when you don\'t enter the +It will print \"Your gender is a secret.\" when you don't enter the gender. Note that the default value is **used on expansion time**, it is **not assigned to the parameter**. @@ -802,7 +802,7 @@ Removing the first 6 characters from a text string: - **Fixed in 4.2.36** ([patch](ftp://ftp.cwru.edu/pub/bash/bash-4.2-patches/bash42-036)). - Bash doesn\'t follow either POSIX or its own documentation when + Bash doesn't follow either POSIX or its own documentation when expanding either a quoted `"$@"` or `"${arr[@]}"` with an adjacent expansion. `"$@$x"` expands in the same way as `"$*$x"` - i.e. all parameters plus the adjacent expansion are concatenated into a @@ -857,7 +857,7 @@ Removing the first 6 characters from a text string: `When `IFS` is set to a non-null value, or unset, all shells behave the same - first expanding into separate args, then applying pathname expansion and word-splitting to the results, except for - zsh, which doesn\'t do pathname expansion in its default mode. + zsh, which doesn't do pathname expansion in its default mode. ```{=html} @@ -884,7 +884,7 @@ Removing the first 6 characters from a text string: ksh : zsh : `ksh93 and mksh can additionally achieve this side effect (and - others) via the `${ cmds;}` expansion. I haven\'t yet tested every + others) via the `${ cmds;}` expansion. I haven't yet tested every possible side-effect that can affect expansion halfway through expansion that way. @@ -900,7 +900,7 @@ Removing the first 6 characters from a text string: ```{=html} ``` -- Bash (and most other shells) don\'t allow .'s in identifiers. In +- Bash (and most other shells) don't allow .'s in identifiers. In ksh93, dots in variable names are used to reference methods (i.e. \"Discipline Functions\"), attributes, special shell variables, and to define the \"real value\" of an instance of a class. @@ -920,7 +920,7 @@ Removing the first 6 characters from a text string: - Bash only evaluates the subscripts of the slice expansion (`${x:y:z}`) if the parameter is set (for both nested expansions and arithmetic). For ranges, Bash evaluates as little as possible, i.e., - if the first part is out of range, the second won\'t be evaluated. + if the first part is out of range, the second won't be evaluated. ksh93 and mksh always evaluate the subscript parts even if the parameter is unset. ` $ bash -c 'n="y[\$(printf yo >&2)1]" m="y[\$(printf jo >&2)1]"; x=(); echo "${x[@]:n,6:m}"' # No output diff --git a/docs/syntax/quoting.md b/docs/syntax/quoting.md index 40bd255..79fd4f8 100644 --- a/docs/syntax/quoting.md +++ b/docs/syntax/quoting.md @@ -43,7 +43,7 @@ backslash: echo \$HOME is set to \"$HOME\" -- `\$HOME` won\'t expand because it's not in variable-expansion +- `\$HOME` won't expand because it's not in variable-expansion syntax anymore - The backslash changes the quotes into literals - otherwise Bash would interpret them @@ -112,7 +112,7 @@ single-quote that closes the string. echo 'Your PATH is: $PATH' -`$PATH` won\'t be expanded, it's interpreted as ordinary text because +`$PATH` won't be expanded, it's interpreted as ordinary text because it's surrounded by strong quotes. In practise that means, to produce a text like `Here's my test...` as a @@ -259,8 +259,8 @@ Now the command has three parameters, which makes sense for a binary (two argument) operator. **[Hint:]{.underline}** Inside the [conditional -expression](../syntax/ccmd/conditional_expression.md) (`[[ ]]`) Bash doesn\'t -perform word splitting, and thus you don\'t need to quote your variable +expression](../syntax/ccmd/conditional_expression.md) (`[[ ]]`) Bash doesn't +perform word splitting, and thus you don't need to quote your variable references - they are always seen as \"one word\". ## See also diff --git a/docs/syntax/shellvars.md b/docs/syntax/shellvars.md index 2d3d375..cf3546a 100644 --- a/docs/syntax/shellvars.md +++ b/docs/syntax/shellvars.md @@ -883,7 +883,7 @@ the history list: --------------- ------------------------------------------------------------------------------------------------------------ `ignorespace` lines which begin with a space character are not saved in the history list - `ignoredups` don\'t save lines matching the previous history entry + `ignoredups` don't save lines matching the previous history entry `ignoreboth` short for `ignorespace:ignoredups` `erasedups` remove all previous lines matching the current line from the history list before the current line is saved --------------- ------------------------------------------------------------------------------------------------------------ diff --git a/docs/syntax/words.md b/docs/syntax/words.md index f121730..d1018e2 100644 --- a/docs/syntax/words.md +++ b/docs/syntax/words.md @@ -22,7 +22,7 @@ by a space. When you enter an echo command at the Bash prompt, Bash will look for those special characters, and use them to separate the parameters. -You don\'t know what I\'m talking about? I\'m talking about this: +You don't know what I\'m talking about? I\'m talking about this: $ echo Hello little world Hello little world @@ -40,7 +40,7 @@ Bash splits the command line at the blanks into words, then it calls echo with **each word as an argument**. In this example, echo is called with three arguments: \"`Hello`\", \"`little`\" and \"`world`\"! -[Does that mean we can\'t echo more than one Space?]{.underline} Of +[Does that mean we can't echo more than one Space?]{.underline} Of course not! Bash treats blanks as special characters, but there are two ways to tell Bash not to treat them special: **Escaping** and **quoting**. @@ -56,7 +56,7 @@ None of the escaped spaces will be used to perform word splitting. Thus, echo is called with one argument: \"`Hello little world`\". Bash has a mechanism to \"escape\" an entire string: **Quoting**. In the -context of command-splitting, which this section is about, it doesn\'t +context of command-splitting, which this section is about, it doesn't matter which kind of quoting you use: weak quoting or strong quoting, both cause Bash to not treat spaces as special characters: