# Tag Info

## New answers tagged quoting

1

You have to use several types of quotes or escape them: sed -i "12iexec('/var/www/scripte/autostandby.sh > /dev/null 2>/dev/null &');" *.php Bonus: sed -i "s|exec('/var/www/streams/taketv.sh');|exec('/var/www/streams/taketv.sh > /dev/null 2>/dev/null \&');|"

0

sed '12i\ exec('\''/var/www/scripte/autostandby.sh > /dev/null 2>/dev/null &'\''); ' file.php You have to quote the whole thing. Your problem is you're trying to insert quotes from within a quoted string. It is doable, but you have to quote the quotes. command 'begin quoted arg'\'' close quotes backslash quote the apostrophe open ...

6

. is a regular expression metacharacter which matches any single character. \ is also a regular expression metacharacter which can be used to escape any metacharacter so that it will be literally matched. and so . matches any character, but \. matches only .. printf %c900983\\n a . | grep -n ".900983" 1:a900983 2:.900983 ...because the . regular ...

0

The accepted answer works for simple (one level) quoting: $echo$'\'single quote phrase\' "double quote phrase"' 'single quote phrase' "double quote phrase" To get the command presented to work, you need to quote twice. This script could do all the work: #!/bin/bash quote () { local quoted=${1//\'/\'\\\'\'}; printf "'%s'" "$quoted" } read -r ...

3

Change the following line: grepFails=$(egrep "\\def$myVar\>" myFile) With: grepFails=$(egrep "\\\\def\\$myVar\>" myFile) The problem was that you were not escaping the \ properly in the subshell. To understand, try running eval echo "\\\\". You will notice that the output is \ because of the double evaluation.

2

Your approach is fundamentally flawed. You grind the meat into hamburger for transportation, and then you want to get the cow back at the end. Nope, that doesn't work. Instead of injecting the string directly into the shell command, pass it as an argument. I'm not familiar with Zabbix, but looking at the documentation, this appears to be how it works (e.g. ...

2

To put single quotes to the command line, use double quotes or backslash: test.sh "'test'" test.sh \'test\' But from your post, it seems your real problem is different: I cant alter what is inside the variable If you already have a string in a variable, just double quote the variable to pass its value unchanged. test.sh "$var" 1 Basically, your problem is Why does my shell script choke on whitespace or other special characters? When you write$curl_command outside quotes, this takes the value of the curl_command variable and splits it into separate words at each whitespace sequence. (And then each word is interpreted as a wildcard pattern and replaced by the list of matching file ...

2

Why not using the right tool for this job, i.e. grep: grep -qxFf- file.txt <<\IN && printf %s\\n "String found. Do remaining steps" #orb_plugins = ["local_log_stream", "iiop_profile", "giop", "iiop"]; IN This stops reading the file as soon as a match is found. It's also (on average) about 100 times faster than your while read loop.

1

Most simple method is to use single quotes on the right hand side: if [ "$line" == '#orb_plugins = ["local_log_stream", "iiop_profile", "giop", "iiop"];' ] This way the string to be matched is interpreted literally. If you prefer using double quotes, you must not escape the brackets ([]), but only the double quotes (""): if [ "$line" == "#orb_plugins = ...

0

Take a look at this script I wrote for updating our service. PROJ=$2 will be passed to remote running env. function update-env () { env=$1 proj=$2 # script for update test env ssh -A root@$2.$1.test.com PROJ=$2 'bash -s' <<'ENDSSH' # commands to run on remote host su gmuser cd /srv/apps/$PROJ ... 2 The question is two-part: how does find manage to call programs using -exec without running into problems with spaces embedded in filenames, and what good is the -print0 option? For the first, find is making a system call, actually one of a group of related calls referred to as "exec". It passes the filename as an argument directly to this call, which ... 2 The find command executes the command directly. The command, including the filename argument, will not be processed by the shell or anything else that might modify the filename. It's very safe. You are correct that there's no need to escape filenames which are represented by {} on the find command line. find passes the raw filename from disk directly ... 3 This is happening because the a* and b* are not quoted and, therefore, are expanded by the shell before being passed to grep. For example, consider this directory:$ ls afile.txt bfile.txt regex.txt If I try to run grep a* regex.txt, the a* will become afile.txt and that is what will be given as a search pattern to grep. We can use bash's debugging ...

1

You do have to do it yourself: this sed command escaped any non-alphanumeric character, which is what quotemeta does (IIRC) str="abc.def.ghi" escaped=$(sed 's/[^[:alnum:]]/\\&/g' <<< "$str") echo "$escaped" # => abc\.def\.ghi we expect this to match because it's using the original string as a regular expression$ echo "foo bar ...

3

Use the -F options to make grep treat pattern as fixed string: grep -F 'abc.def.ghi' <file And also note that you don't need to invoke egrep.

0

The aforementioned printf '%s\n' "$LS" is the only correct solution. Let me demonstrate that the other proposed solutions, both with echo and printf, simply do not work properly:$ mkdir t $cd t$ touch \\n $LS=$(ls -l) $echo "$LS" total 0 -rw-r--r-- 1 domain domain 0 Nov 5 06:12 $printf "$LS\n" total 0 -rw-r--r-- 1 domain domain 0 Nov 5 ...

1

With GNU Make: objects := $(patsubst %.c,%.o,$(wildcard *.c)) all : $(objects) See info make or pinfo make and search for the wildcard and patsubst functions for more details. Depending on your distro, you may need to install the make-doc package (or similar name) first to get the full make documentation. 2 You need to escape the$. In make, you do so by using $$. Your line should be: TARGETS = (shell ls *.c | sed "s/\.c$$//g") Although this one answers the questions directly, @cas's solution appears to be better.

0

You can try double quoting the file name. find . -name "*.txt" -print That works on my system (Debian 8)

2

There are 2 parts here that could try to expand the *: the shell when it's invoking find or find as it's processing/using its arguments. If you do not single quote it, the shell will expand it, so if you have a.txt and b.txt in the current directory your command line would expand from find . -name *.txt -print to find . -name a.txt b.txt -print which ...

Top 50 recent answers are included