3

Refering to this question:

Why is an extra \needed in cmd.exe to work with sed (MinGW msys-1.0) when \ is not a special character according to cmd /? (see last paragraph or here)?

The following special characters require quotation marks: & < > [ ] { } ^ = ; ! ' + , ` ~ [white space]

First backslash escapes the second, robbing him his special meaning. Two remaining backslashes are given to sed which escapes the third by using the second, so one verbatim single backslash is left in the end, which is matched by my search and replace. But still I'm unsatisfied with this explanation, because:

cmd does not perform tokenizing so the first step of escaping doesn't make sense ... from here, \ has only some special meaning when preceding "...so what is the real explanation?

on bash in linux:

echo 'sample\input' | sed 's/\\/----/'
sample----input

on cmd.exe in windows xp sp3 (no ' needed):

echo sample\input | sed "s/\\/----/"
sed: -e expression #1, char 9: unterminated 's' command 
// for some reason sed received only one backslash which causes him trouble ?

echo sample\input | sed "s/\\\/----/"
sample----input
Community
  • 1
panny
  • 675

1 Answers1

3

Sed is doing it, it uses a regex in the "find" section. it uses BRE or ERE or PCRE depending on the switch. Backslash is special within a regex.

Added

I haven't used your version of using single quotes 'cos that makes no sense to me in cmd.exe!! cmd.exe uses double quotes if at all.

And it works fine.

tested with gnuwin32's sed run from cmd.exe as it is meant to be.

C:\>echo sample\input | sed "s/\\/----/"
sample----input

C:\>sed --v
GNU sed version 4.2.1
Copyright (C) 2009 Free Software Foundation, Inc.

If I was testing cygwin's sed i'd run it from the cygwin window as that's where cygwin programs are meant to be run. And then i'd use single quotes. msys seems similar to cygwin in that sense.

UPDATE

You can run cygwin's sed from cmd, or from cygwin. They behave different because they are different GNU versions, but I don't see any shell related issue running from cmd vs running from cygwin (other than the simple point about single quotes for cygwin 'cos eg bash, and double quotes for cmd).

And cygwin's is a much later version of sed. Gnuwin32's sed, like many gnuwin32 things including gnuwin32 grep, is years out of date. and e.g. later greps can fix bugs in earlier greps. The 2009 sed that gnuwin32 uses, or less up to date version that gnuwin32 uses, may be ok but may be better to use a recent version that cygwin would use.

Interestingly, the seds behave differently regarding backslash.. I can see how to get it working in the later sed, the sed that cygwin uses.

C:\blah>echo a\bc | c:\cygwin\bin\sed "s/\\/_/"
/usr/bin/sed: -e expression #1, char 6: unterminated `s' command

C:\blah>echo a\bc | c:\cygwin\bin\sed "s/\\\/_/"
a_bc

C:\blah>echo a\bc | "c:\Program Files (x86)\GnuWin32\bin\sed" "s/\\/_/"
a_bc

The earlier sed (gnuwin32's sed), allows "s/\/_/" It's not escaping the forward slash. So the backslash is escaping the backslash to make a literal backslash. And the forward slash after the two backslashes, remains fine. And it works in that.

note- running cygwin's sed in cmd is fine. And since it's a later version it's preferable to gnuwin32's sed.

The later sed (cygwin's sed), does not allow "s/\/_/" because the / is escaping the forward slash. Instinct(and correct instinct) would be try adding another backslash and see what happens. And it works. Not sure the mechanics but I guess a single backslash in the later sed is \\\.

C:\blah>echo \ | c:\cygwin\bin\sed "s/\\\/d/"
d
barlop
  • 25,198