Is there different between single quote and double quote in vim command mode? - vim

In my vim, I can use :%!sed "s/^/ /", got the wrong output when I use :%!sed 's/^/ /' .
sed: -e expression #1, char 0: no previous regular expression
Is there differences between single quote and double quote in vim command mode?
In my sed, single quote is the same as double quote.
$ echo "wha012" | sed 's/w/haha/'
hahaha012
$ echo "wha012" | sed "s/w/haha/"
hahaha012
my system is xp+vim 7.3 for windows.
In my system:
[1] "c://cygwin/bin/ash.exe"
[2] "c://cygwin/bin/bash.exe"
[3] "c://cygwin/bin/dash.exe"
[4] "c://cygwin/bin/sh.exe"
if i set set shell=\"c:\cygwin\bin\sh.exe"\ -f in _vimrc,i get the new wrong messages:
sed command can not found.

Funny, when I try :%!sed "/^/ /" I get the same error message as when I use single quotes:
sed: 1: "/^/ /": invalid command code /
(This line replaces the content of my file.) I expect to get an error message there because, as #Birei pointed out, you left out the sed s command. This works as expected, with either single or double quotes:
:%!sed "s/^/ /"
#Birei is also right that you can use vim to do things like this, but I assume you have simplified the example from what you were really trying to do.
To answer the original question, Vim uses single quotes for literal strings. The only special character in a literal string is ' itself. Strings delimited with double quotes use \ to denote special character, such as `"\<Esc>".
:echo 'a''b' == "a'b"
:help expr-string
:help literal-string

my system is xp+vim 7.3 for windows
By default Vim uses cmd.exe to run :! commands on Windows, which behaves differently with regard to quoting from the POSIX shell that your s/w/haha/ examples suggest you've been testing with. Try something like
:set shell=\"C:\path\to\sh.exe\"\ -f
to tell it to use your POSIX shell instead. Or if you're using cygwin then try the cygwin version of vim instead of the Windows native one.

The difference is in the sed command, that lets interpolate variables when you execute it directly from the shell, like:
sed "s/$pattern/$replacement/"
but your problem is that you have to use a substitution command that begins with letter s, like:
:%!sed "s/^/ /"
Also you can have same behaviour inside vim without an external command, like:
:%s/^/ /

Related

pass string with spaces to gcc [duplicate]

This question already has answers here:
How can I store a command in a variable in a shell script?
(12 answers)
Closed 4 years ago.
These work as advertised:
grep -ir 'hello world' .
grep -ir hello\ world .
These don't:
argumentString1="-ir 'hello world'"
argumentString2="-ir hello\\ world"
grep $argumentString1 .
grep $argumentString2 .
Despite 'hello world' being enclosed by quotes in the second example, grep interprets 'hello (and hello\) as one argument and world' (and world) as another, which means that, in this case, 'hello will be the search pattern and world' will be the search path.
Again, this only happens when the arguments are expanded from the argumentString variables. grep properly interprets 'hello world' (and hello\ world) as a single argument in the first example.
Can anyone explain why this is? Is there a proper way to expand a string variable that will preserve the syntax of each character such that it is correctly interpreted by shell commands?
Why
When the string is expanded, it is split into words, but it is not re-evaluated to find special characters such as quotes or dollar signs or ... This is the way the shell has 'always' behaved, since the Bourne shell back in 1978 or thereabouts.
Fix
In bash, use an array to hold the arguments:
argumentArray=(-ir 'hello world')
grep "${argumentArray[#]}" .
Or, if brave/foolhardy, use eval:
argumentString="-ir 'hello world'"
eval "grep $argumentString ."
On the other hand, discretion is often the better part of valour, and working with eval is a place where discretion is better than bravery. If you are not completely in control of the string that is eval'd (if there's any user input in the command string that has not been rigorously validated), then you are opening yourself to potentially serious problems.
Note that the sequence of expansions for Bash is described in Shell Expansions in the GNU Bash manual. Note in particular sections 3.5.3 Shell Parameter Expansion, 3.5.7 Word Splitting, and 3.5.9 Quote Removal.
When you put quote characters into variables, they just become plain literals (see http://mywiki.wooledge.org/BashFAQ/050; thanks #tripleee for pointing out this link)
Instead, try using an array to pass your arguments:
argumentString=(-ir 'hello world')
grep "${argumentString[#]}" .
In looking at this and related questions, I'm surprised that no one brought up using an explicit subshell. For bash, and other modern shells, you can execute a command line explicitly. In bash, it requires the -c option.
argumentString="-ir 'hello world'"
bash -c "grep $argumentString ."
Works exactly as original questioner desired. There are two restrictions to this technique:
You can only use single quotes within the command or argument strings.
Only exported environment variables will be available to the command
Also, this technique handles redirection and piping, and other shellisms work as well. You also can use bash internal commands as well as any other command that works at the command line, because you are essentially asking a subshell bash to interpret it directly as a command line. Here's a more complex example, a somewhat gratuitously complex ls -l variant.
cmd="prefix=`pwd` && ls | xargs -n 1 echo \'In $prefix:\'"
bash -c "$cmd"
I have built command processors both this way and with parameter arrays. Generally, this way is much easier to write and debug, and it's trivial to echo the command you are executing. OTOH, param arrays work nicely when you really do have abstract arrays of parameters, as opposed to just wanting a simple command variant.

Executing error while executing sed command

Below given sed command is working fine on online BASH & KSH shell, but getting an error "Illegal operation --r" while trying to run it on linux server.
I'm trying to make a regex to parse MFBBMYKLAXXX from first line.
echo "{1:F01MFBBMYKLAXXX2474811384}{2:O3001434181108BKKBTHBKBXXX12203020241811081534N}{3:{108:241C182AFFD4403C}}{4:
:15A:
:20:10168957
:22A:NEWT
:94A:BILA
:22C:BKKBBK8308MFBBKL
:82A:BKKBTHBK
:87A:MFBBMYKL
:15B:
:30T:20181108
:30V:20181109
:36:32,8308
:32B:THB2500000,
:53A:/610165
BKKBTHBK
:57A:BKKBTHBK
:33B:USD76148,01
:53A:CHASUS33
:57A:/04058664
BKTRUS33
:58A:MFBBMYKL
:15C:
:24D:ELEC/REUTERS D-3000
-}{5:{CHK:4117CD0206B7}}{S:{COP:S}}
" | sed -rn 's/.*\{1:F01([A-Z]{12}).*/\1/p'
The use of sed -r (or in some dialects sed -E) is nonstandard and optional.
It selects a regex dialect called extended regular expressions, which allows you to express some things more succinctly.
POSIX basic regular expressions support pretty much the same facilities, but with an oddball syntax where you have to backslash some characters to obtain their special meaning (which in other words does exactly the opposite of what backslash escaping originally did).
So if you have an extended regular expression like a+(b{2})c then if your sed does not support either -r or -E, try a\+\(b\{2\}\}c without any special option, and hope that your sed is at least roughly on par with what POSIX specifies. (If you're serious about retrocomputing, this is unlikely, though.)
The original regular expression implementation by Ken Thompson only supported the regex metacharacters [...] and . and *, and for a long time, that's all sed supported, too.
Of course, you could always install a more modern sed. I know SunOS used to have some goodies in their xpg4 directory but I have no idea if this was is the case in Solaris; if so, maybe you just need to add /usr/xpg4/bin to your PATH. (According to this it was true at one point in time at least.)

Command sed using g

I am new to Linux.
I was debugging some code. I encountered the following command:
PROGRAM_ID=$(echo $PROGRAM_ID|sed 's/-/,/g')
Can anybody explain what the g represents here?
I understand hyphen is being replaced with comma.
The /g flag means, perform the substitution globally on a line. Without that flag, only the first hyphen on every line would get substituted.
A better way with Bash would be
PROGRAM_ID=${PROGRAM_ID//-/,}
but if you have to be portable to Bourne shell in general, this replacement facility is not available.
(In which case you should take care to keep "$PROGRAM_ID" in double quotes in the echo.)
Its easy to see how g (global) works with these two example:
echo "test-one-two-three" | sed 's/-/,/g'
test,one,two,three
echo "test-one-two-three" | sed 's/-/,/'
test,one-two-three
Without the g it only replace the first hit.

Understanding sed

I am trying to understand how
sed 's/\^\[/\o33/g;s/\[1G\[/\[27G\[/' /var/log/boot
worked and what the pieces mean. The man page I read just confused me more and I tried the info sai Id but had no idea how to work it! I'm pretty new to Linux. Debian is my first distro but seemed like a rather logical place to start as it is a root of many others and has been around a while so probably is doing stuff well and fairly standardized. I am running Wheezy 64 bit as fyi if needed.
The sed command is a stream editor, reading its file (or STDIN) for input, applying commands to the input, and presenting the results (if any) to the output (STDOUT).
The general syntax for sed is
sed [OPTIONS] COMMAND FILE
In the shell command you gave:
sed 's/\^\[/\o33/g;s/\[1G\[/\[27G\[/' /var/log/boot
the sed command is s/\^\[/\o33/g;s/\[1G\[/\[27G\[/' and /var/log/boot is the file.
The given sed command is actually two separate commands:
s/\^\[/\o33/g
s/\[1G\[/\[27G\[/
The intent of #1, the s (substitute) command, is to replace all occurrences of '^[' with an octal value of 033 (the ESC character). However, there is a mistake in this sed command. The proper bash syntax for an escaped octal code is \nnn, so the proper way for this sed command to have been written is:
s/\^\[/\033/g
Notice the trailing g after the replacement string? It means to perform a global replacement; without it, only the first occurrence would be changed.
The purpose of #2 is to replace all occurrences of the string \[1G\[ with \[27G\[. However, this command also has a mistake: a trailing g is needed to cause a global replacement. So, this second command needs to be written like this:
s/\[1G\[/\[27G\[/g
Finally, putting all this together, the two sed commands are applied across the contents of the /var/log/boot file, where the output has had all occurrences of ^[ converted into \033, and the strings \[1G\[ have been converted to \[27G\[.

vim :gsearch (greplace plugin) escaping characters

I am using the greplace plugin for vim and am not sure how to escape brackets in a search.
I want to search for cookies[:parent] and have tried:
:Gsearch cookies[:parent] # returns nothing
:Gsearch cookies\[:parent\] # returns nothing
How should I be doing this?
Thanks
Try
Gsearch cookies\\\[:parent\\\]
or
Gsearch 'cookies\[:parent\]'
. If I understood correctly, shell invoked by :grep! invoked by :Gsearch gets string grep -n cookies\[:parent\] /dev/null (assuming grepprg option has default value) and thus your escapes are interpreted by shell that thinks they are for escaping [ in order to prevent glob expansion. But after globbing done by shell grep takes argument as a pattern, so you need to escape it for grep also and it is why I have three backslashes here: two are to make grep get a backslash and third to prevent glob expansion.
:Gsearch cookies\\\[:parent] works for me.
Remember that :Gsearch requires a file mask in addition to the pattern, so in reality, you'd want to type something like :Gsearch \\\[:parent] *.php or whatever, to specify which files you want to have searched.
:Gsearch cookies\[:parent]
[ is the start of a character class, so needs to be escaped. The ] isn't particularly special so doesn't need to be escaped.

Resources