What is escape character in linux

Escape Codes in Linux

ANSI escape codes can be used to style the output of echo or printf . An escape code is a sequence of characters start with an ESC character, followed by second character in the ASCII range 64 to 95 . This sequence can be of different length.

The general format of escape code for styling the terminal text is:
ESC [ ;;.

Note that above escape code sequece ends with m and there is no ; before that.

The ASCII equivalent of ESC character is 033(in decimal) or 0x1b(in hexa). We use 033 because it works for all operating systems.

Some examples for escape codes are:

If we examine the code ‘\033[1;42m’ ,

\033	[	1	;	42	m
Octal value of ESC char.	left square bracket	Attribute 1 (bold)	Divider	Attribute 2 (Green)	Ending Char.

Usage with echo

Don’t forget to use -e option along with echo command. Any text following the above code sequence will print with green background color.

Usage with printf

Text Formatting

Examples of text formatting:

Value	Escape Code	Text Style
0	‘\033[0;31m’	Regular
1	‘\033[1;31m’	Bold
2	‘\033[2;31m’	Low Intensity
3	‘\033[3;31m’	Italic
4	‘\033[4;31m’	Underline
5	‘\033[5;31m’	Blinking
6	‘\033[6;31m’	Reverse
7	‘\033[7;31m’	Background
8	‘\033[8;31m’	Invisible

Terminal text decoration escape codes

Text Colour

Examples of text color:

Value	Escape Code	Text Color
30	‘\033[0;30m’	Black
31	‘\033[0;31m’	Red
32	‘\033[0;32m’	Green
33	‘\033[0;33m’	Yello
34	‘\033[0;34m’	Blue
35	‘\033[0;35m’	Magenta
36	‘\033[0;36m’	Cyan
37	‘\033[0;37m’	White

Terminal text color escape codes

Background Colour

Examples of Background color:

Value	Escape Code	Background Color
40	‘\033[0;40m’	Black
41	‘\033[0;41m’	Red
42	‘\033[0;42m’	Green
43	‘\033[0;43m’	Yello
44	‘\033[0;44m’	Blue
45	‘\033[0;45m’	Magenta
46	‘\033[0;46m’	Cyan
47	‘\033[0;47m’	White

Terminal text color escape codes

Random Text Style Attributes

One or more attributes can be clubbed together for more styling.

Random Text Style Attributes

A simple color echo solution for shell scripts

Save the following code in a file, let’s say cecho.sh

Including the above file in any shell script will allow us to print color text on terminal.

Let’s say file display.sh has the following content.

Now executing second shell script will display output in red color.

color text on terminal using shell script

Источник

Linux Special and Escape Characters in FileName

In Linux, whitespace is a special character and one of the most frequently used characters. It separates the commands or arguments to the commands. For example, the copy command treats the first file assigned to it as the source file and the second file as the destination file.

These two file arguments are separated by whitespace. So if the file name contains whitespace, it creates a problem on the command line. This tutorial we discuss how you can create files with special characters and how to use them on the command line effectively.

Handling special characters

Let us try to create a file with spaces in its name with touch command.

The ls command in the above output shows that we do not get a single file but three files, i.e. file, spaces and with. This is because touch command considers the name as three different files, and not as a single file.

Two methods are available for handling these characters that have special meaning for shell. First, one is using quotes and second is with escape character.

Quotes

The simplest method is using quotes with the file name. Now, let us try creating the above file with quotes.

Now, you can see the file named «file with spaces». Both single quotes and double quotes can be used with file names, but it is advised to use single quotes. This is because some special characters cannot be escaped by double quotes. Single quotes handle them as well. Other special characters like $, *, ? etc can also be used in file names.

Another example

In the above example quotes are more important. Because * is a shell wildcard that matches any character, you will be in trouble if you don’t use the quotes. Without the quotes, the shell removes File*.txt as intended, but in addition File.txt, File2.txt, File22.txt and others will get deleted.

Escaping characters

This is another method that can be used for files with special characters in their names. The backslash character escapes the character following it. It means that the character that immediately follows backslash character is treated as normal character by the shell and not as special character.

For example, we can use backslash for creating a file that contains spaces in its name.

Similarly, the other special characters can also be escaped with backslash:

Now, you have seen that the quotes (single or double) and the backslash characters are the special characters that are used for handling special characters. So how can you use these characters in your file names? For quotes, you can use backslash:

That was simple. So what about backslash? Remember, backslash escapes every special character immediately following it? So we use backslash for escaping backslash itself.

Источник

What characters need to be escaped in files without quotes?

I have browser-based shell/terminal that executes bash commands and I’m escaping spaces but it turns out that parenthesis also need to be escaped. What other characters need to be escaped for file names that are not in quotes?

1 Answer 1

The simple solution is to put a single quote ( ‘ ) at the beginning and another single quote at the end, and to replace every ‘ character inside the file name by the 4-character sequence ‘\» . All characters lose their special meaning inside a single-quoted string, except ‘ itself which marks the end of the string. The sequence ‘\» ends the single-quoted literal, immediately follows by a quoted single quote, and opens a new single-quoted literal. Thus the file name

can be quoted as follows:

Double quotes have more complex escaping rules and don’t allow you to include an exclamation mark ! if history substitution is activated, so I won’t consider them further.

An alternative approach is to protect characters with backslashes. This works for every character except newlines; for a newline, putting it inside single quotes (or double quotes) is the only solution. If you want to minimize the number of backslashes to present the quoted name to the user, you may restrict it to places where the backslash is needed; however, the more backslashes you omit, the more you risk forgetting one that’s needed. Letters, digits and non-ASCII characters are always ok¹. Quote whitespace and punctuation whenever you’re unsure.

With a typical shell (ksh, bash or zsh), you need to quote the following characters in at least some circumstances.

• Whitespace (space, tab, newline — remembering that newlines can’t be quoted with a backslash).
• ! — history expansion.
• » — shell syntax.
• # — comment start when preceded by whitespace; zsh wildcards.
• $ — shell syntax.
• & — shell syntax.
• ‘ — shell syntax.
• ( — even in the middle of a word: ksh extended globs (also available in bash and zsh); zsh wildcards.
• ) (see ( )
• * — sh wildcard.
• , — only inside brace expansion.
• ; — shell syntax.
• — shell syntax.
• = — in zsh, when it’s at the beginning of a file name (filename expansion with PATH lookup).
• > — shell syntax.
• ? — sh wildcard.
• [ — sh wildcard.
• \ — shell syntax.
• ] — you may get away with leaving it unquoted.
• ^ — history expansion; zsh wildcard.
• ` — shell syntax.
• < — brace expansion.
• | — shell syntax.
• > — needs to be escaped in zsh, other shells are more lenient when there’s no matching opening brace.

— home directory expansion when it’s at the beginning of a file name; zsh wildcard; always safe when it’s the last character.

A few more characters can require special handling sometimes:

• — isn’t special for the shell, but when it’s at the beginning of a command argument, it indicates an option. It can’t be protected with quotes since the special handling is in the command, not in the shell. To protect a file name that begins with — , you can put ./ before it — this way it’s still the same file, but the argument doesn’t begin with — anymore.
• . isn’t special in itself, but dot files are excluded from * globs by default.
• : isn’t special for the shell, but some commands parse it specially, e.g. to indicate a remote file ( hostname:filename ). Consult the documentation of the command to see how to cope with file nams containing colons.

¹ _{Unless the user has configured alternate history expansion characters. Some shells allow this. This is another reason to use single quotes rather than backslashes.}

Источник

Which characters need to be escaped when using Bash?

Is there any comprehensive list of characters that need to be escaped in Bash? Can it be checked just with sed ?

In particular, I was checking whether % needs to be escaped or not. I tried

and worked fine, without escaping % . Does it mean % does not need to be escaped? Was this a good way to check the necessity?

And more general: are they the same characters to escape in shell and bash ?

7 Answers 7

There are two easy and safe rules which work not only in sh but also bash .

1. Put the whole string in single quotes

This works for all chars except single quote itself. To escape the single quote, close the quoting before it, insert the single quote, and re-open the quoting.

2. Escape every char with a backslash

This works for all characters except newline. For newline characters use single or double quotes. Empty strings must still be handled — replace with «»

2b. More readable version of 2

There’s an easy safe set of characters, like [a-zA-Z0-9,._+:@%/-] , which can be left unescaped to keep it more readable

Note that in a sed program, one can’t know whether the last line of input ends with a newline byte (except when it’s empty). That’s why both above sed commands assume it does not. You can add a quoted newline manually.

Note that shell variables are only defined for text in the POSIX sense. Processing binary data is not defined. For the implementations that matter, binary works with the exception of NUL bytes (because variables are implemented with C strings, and meant to be used as C strings, namely program arguments), but you should switch to a «binary» locale such as latin1.

(You can easily validate the rules by reading the POSIX spec for sh . For bash, check the reference manual linked by @AustinPhillips)

Источник

What characters are required to be escaped in command line arguments?

In Bash, when specifying command line arguments to a command, what characters are required to be escaped?

Are they limited to the metacharacters of Bash: space, tab, | , & , ; , ( , ) , , and > ?

3 Answers 3

The following characters have special meaning to the shell itself in some contexts and may need to be escaped in arguments:

Character	Unicode	Name	Usage
`	U+0060 (Grave Accent)	Backtick	Command substitution
U+007E	Tilde	Tilde expansion
!	U+0021	Exclamation mark	History expansion
#	U+0023 Number sign	Hash	Comments
$	U+0024	Dollar sign	Parameter expansion
&	U+0026	Ampersand	Background commands
*	U+002A	Asterisk	Filename expansion and globbing
(	U+0028	Left Parenthesis	Subshells
)	U+0029	Right Parenthesis	Subshells
U+0009	Tab ( ⇥ )	Word splitting (whitespace)
<	U+007B Left Curly Bracket	Left brace	Brace expansion
[	U+005B	Left Square Bracket	Filename expansion and globbing
|	U+007C Vertical Line	Vertical bar	Pipelines
\	U+005C Reverse Solidus	Backslash	Escape character
;	U+003B	Semicolon	Separating commands
‘	U+0027 Apostrophe	Single quote	String quoting
«	U+0022 Quotation Mark	Double quote	String quoting with interpolation
↩	U+000A Line Feed	Newline	Line break
U+003C	Less than	Input redirection
>	U+003E	Greater than	Output redirection
?	U+003F	Question mark	Filename expansion and globbing
U+0020	Space	Word splitting 1 (whitespace)

Some of those characters are used for more things and in more places than the one I linked.

There are a few corner cases that are explicitly optional:

• ! can be disabled with set +H , which is the default in non-interactive shells.
• < can be disabled with set +B .
• * and ? can be disabled with set -f or set -o noglob .
• = Equals sign (U+003D) also needs to be escaped if set -k or set -o keyword is enabled.

Escaping a newline requires quoting — backslashes won’t do the job. Any other characters listed in IFS will need similar handling. You don’t need to escape ] or > , but you do need to escape ) because it’s an operator.

Some of these characters have tighter limits on when they truly need escaping than others. For example, a#b is ok, but a #b is a comment, while > would need escaping in both contexts. It doesn’t hurt to escape them all conservatively anyway, and it’s easier than remembering the fine distinctions.

If your command name itself is a shell keyword ( if , for , do ) then you’ll need to escape or quote it too. The only interesting one of those is in , because it’s not obvious that it’s always a keyword. You don’t need to do that for keywords used in arguments, only when you’ve (foolishly!) named a command after one of them. Shell operators ( ( , & , etc) always need quoting wherever they are.

1 _{Stéphane has noted that any other single-byte blank character from your locale also needs escaping. In most common, sensible locales, at least those based on C or UTF-8, it’s only the whitespace characters above. In some ISO-8859-1 locales, U+00A0 no-break space is considered blank, including Solaris, the BSDs, and OS X (I think incorrectly). If you’re dealing with an arbitrary unknown locale, it could include just about anything, including letters, so good luck.}

_{Conceivably, a single byte considered blank could appear within a multi-byte character that wasn’t blank, and you’d have no way to escape that other than putting the whole thing in quotes. This isn’t a theoretical concern: in an ISO-8859-1 locale from above, that A0 byte which is considered a blank can appear within multibyte characters like UTF-8 encoded «à» ( C3 A0 ). To handle those characters safely you would need to quote them «à» . This behaviour depends on the locale configuration in the environment running the script, not the one where you wrote it.}

_{I think this behaviour is broken multiple ways, but we have to play the hand we’re dealt. If you’re working with any non-self-synchronising multibyte character set, the safest thing would be to quote everything. If you’re in UTF-8 or C, you’re safe (for the moment).}

Источник