Tag Info

Hot answers tagged

41

You need to quote your argument error* because the shell expands it. So what you're actually running now is find -name error_log, because that's what the shell can expand it to (there's a file named error_log in your current directory). find . -name 'error*' Is the correct invocation for your use case.


29

There are two different things going on here, both documented in the bash manual $' Dollar-sign single quote is a special form of quoting: ANSI C Quoting Words of the form $'string' are treated specially. The word expands to string, with backslash-escaped characters replaced as specified by the ANSI C standard. $" Dollar-sign double-quote is for ...


29

In the same way that you can't run ls "*.txt" in a normal shell, you can't run it in a subshell either. When you put *.txt in quotes, you made ls search for a literal file called *.txt when instead you should be doing this: $ echo $(ls *.txt) # => file.txt otherfile.txt A better way to do this is to not use ls at all. $ echo *.txt # => file.txt ...


27

The single bracket [ is actually an alias for the test command, it's not syntax. One of the downsides (of many) of the single bracket is that if one or more of the operands it is trying to evaluate return an empty string, it will complain that it was expecting two operands (binary). This is why you see people do [ x$foo = x$blah ], the x guarantees that ...


27

First, you need to protect the pattern from expansion by the shell. The easiest way to do that is to put single quotes around it. Single quotes prevent expansion of anything between them (including backslashes); the only thing you can't do then is have single quotes in the pattern. grep 'foo*' *.txt If you do need a single quote, you can write it as '\'' ...


25

Dealing with multiple levels of quoting (really, multiple levels of parsing/interpretation) can get complicated. It helps to keep a few things in mind: Each “level of quoting” can potentially involve a different language. Quoting rules vary by language. When dealing with more than one or two nested levels, it is usually easiest to work “from the bottom, ...


24

In order from worst to best: DIRNAME="$(dirname $FILE)" will not do what you want if $FILE contains whitespace or globbing characters \[?*. DIRNAME=`dirname "$FILE"` is technically correct, but backticks are not recommended for command expansion because of the extra quoting issues when nesting them. DIRNAME=$(dirname "$FILE") is correct, but only because ...


22

VAR=$VAR1 is a simplified version of VAR=${VAR1}. There are things the second can do that the first cant, for instance reference an array index (not portable) or remove a substring (POSIX-portable). See the More on variables section of the Bash Guide for Beginners and Parameter Expansion in the POSIX spec. Using quotes around a variable as in rm -- "$VAR1" ...


22

This is a backtick. Backtick is not a quotation sign, it has a very special meaning. Everything you type between backticks is evaluated (executed) by the shell before the main command (like chown in your examples), and the output of that execution is used by that command, just as if you'd type that output at that place in the command line. So, what sudo ...


21

${VAR} and $VAR are exactly equivalent. For a plain variable expansion, the only reason to use ${VAR} is when parsing would otherwise grab too many characters into the variable name, as in ${VAR1}_$VAR2 (which without braces would be equivalent to ${VAR1_}$VAR2). Most adorned expansions (${VAR:=default}, ${VAR#prefix}, …) require braces. In a variable ...


21

In bash you can use the syntax str=$'Hello World\n===========\n' Single quotes preceded by a $ is a new syntax that allows to insert escape sequences in strings. Also printf builtin allows to save the resulting output to a variable printf -v str 'Hello World\n===========\n' Both solutions do not require a subshell. If in the following you need to ...


21

Short answer: Try this: 0 * * * * echo hello >> ~/cron-logs/hourly/test`date "+\%d"`.log Note the backslash escaping the % sign. Long answer: The error message suggests that the shell which executes your command doesn't see the second back tick character: /bin/sh: -c: line 0: unexpected EOF while looking for matching ``' This is also ...


19

There are two levels of interpretation here: the shell, and sed. In the shell, everything between single quotes is interpreted literally, except for single quotes themselves. You can effectively have a single quotes between single quotes by writing '\'' (close single quote, one literal single quote, open single quote). Sed uses basic regular expressions. ...


18

You always need quotes around variables in all list contexts, that is everywhere the variable may be expanded to multiple values unless you do want the 3 side effects of leaving a variable unquoted. list contexts include arguments to simple commands like [ or echo, the for i in <here>, assignments to arrays... There are other contexts where variables ...


16

The * (star, or asterisk) is a special character which is (usually) interpreted by the shell before it is given the command. It is (usually) expanded to all filenames except those with leading dots. See the bash manual about pattern matching for more information. If placed in quotes the star will not be interpreted by the shell and is given to the command ...


16

No need for any fancy stuff. Simply escape the ? so that it's not considered part of the glob: rm -f ./\?* This works for ! too: rm -f ./\!* Or in one fell swoop: rm -f ./{\?,\!}* Update Just noticed that you were suggesting to grep the output of ls. I wanted to bring your attention to the fact that you shouldn't parse the output of ls


14

First, separate zsh from the rest. It's not a matter of old vs modern shells: zsh behaves differently. The zsh designers decided to make it incompatible with traditional shells (Bourne, ksh, bash), but easier to use. Second, it is far easier to use double quotes all the time than to remember when they are needed. They are needed most of the time, so you'll ...


13

$@ expands to separate words (whereas $* expands to a single word), as explained in the bash manual. Thus, when you write zenity --text="$@" it expands to zenity --text="$1" "$2" "$3" However, shell variable assignments do not undergo word splitting. Note that field / word splitting is omitted in the list of expansions for variable assignments in the ...


13

The oldest usage I know of is TeX. TeX uses `single-quote' and ``double-quote'' instead of 'singe-quote' and "double-quote". It uses them because opening and closing quotes are typeset differently, they curve around the quoted text. At the time, the Unicode open and close quotation marks didn't exist. TeX was initially released in 1978 according to ...


12

Shell variables vs. environment variables MY_HOME="/home/my_user" sets the shell variable called MY_HOME. Shells are programming languages, and have variables (also called parameters). After this assignment, you can use the value of the variable, e.g. with echo "$MY_HOME". Shell variables are an internal shell concept. When that shell instance terminates, ...


12

The answers of Vegar Nilsen and edfuh are very good and the proper solutions to a problem like this. I do want to add a general response to this question that allows you to delete any file with a difficult file name. First its inode number is obtained using ls -i or some form of stat and then the file is removed by searching for files in the current ...


12

Summary: If there ever was a shell that expanded {}, it's really old legacy stuff by now. In the Bourne shell and in POSIX-compliant shells, braces ({ and }) are ordinary characters (unlike ( and ) which are word delimiters like ; and &, and [ and ] which are globbing characters). The following strings are all supposed to be printed literally: $ echo { ...


12

You can put literal newlines within single quotes (in any Bourne/POSIX-style shell). str='Hello World =========== ' For a multiline string, here documents are often convenient. The string is fed as input to a command. mycommand <<'EOF' Hello World =========== EOF If you want to store the string in a variable, use the cat command in a command ...


12

Your shell is interpreting the quotes, both ' and ", before they even get to echo. I generally just put double quotes around my argument to echo even if they're unnecessary; for example: $ echo "Hello world" Hello world So in your first example, if you want to include literal quote marks in your output, they either need to be escaped: $ echo \'Hello ...


12

The [ command is an ordinary command. Although most shells provide it as a built-in for efficiency, it obeys the shell's normal syntactic rules. [ is exactly equivalent to test, except that [ requires a ] as its last argument and test doesn't. The double brackets [[ … ]] are special syntax. They were introduced in ksh (several years after [) because [ can ...


11

As the other answers mention, the issue is nested quotes. I suggest you review how quoting works in bash. In short, quotes (of any kind, single quotes ', double quotes " or backticks `) are almost always matched with the first occurrence of a quote of the same kind; you have to escape a quote in order for it not to match (but you cannot escape single ...


11

The echo $Result command will convert the value of the variable into multiple arguments for echo, splitting on any whitespace, and echo prints all the arguments separated by spaces. On the other hand, echo "$Result" will put the whole string, including whitespace, into the first and only echo argument, which gets printed directly.


11

Here is a simple script to demonstrates the different between $* and $@: #!/bin/bash function test_param() { echo "Receive $# parameters"; echo Using '$*'; echo for param in $*; do echo "==>$param<=="; done; echo echo Using '"$*"'; for param in "$*"; do echo "==>$param<=="; done; ...


11

You are expanding the DESTINATION variable, if you did echo this is what you would get: echo ${DESTINATION} /home/hogar/Ubuntu\ One/folder But mv doesn't understand this: mv ${FILE} ${DESTINATION} mv: cannot move ‘/home/hogar/Documents/files/bdd.encrypted’ to ‘/home/hogar/Ubuntu\\ One/folder’: No such file ...


11

Without quotes the string is subject to word splitting and globbing. See also BashPitfalls #14. Compare $ echo $(printf 'foo\nbar\nquux\n*') foo bar quux ssh-13yzvBMwVYgn ssh-3JIxkphQ07Ei ssh-6YC5dbnk1wOc with $ echo "$(printf 'foo\nbar\nquux\n*')" foo bar quux * When word splitting occurs the first character of IFS acts as a separator (which, per ...



Only top voted, non community-wiki answers of a minimum length are eligible