issue with sed.exe on Windows 10

I believe it's your use of $ to designate an end of line. There is no end of line character in your test string. This works for me: echo testme| sed "s/me//g" Also, in your example you left off the trailing quote. MIKE http://www.skeptic.com/ message edited by mmcconaghy

> I believe it's your use of $ to designate an end of line. > There is no end of line character in your test string. There is: on Windows, the ECHO command always end with an end of line If I omit the $ all is OK because the issue is with the $ sign For example: This one works on both Windows 7 and 10 (for me): echo testme| sed "s/me//g" This one only works correct on Windows 7 (for me): echo testme| sed "s/me$//g" For example, on my Windows 7 machine: C:\> echo testme| sed "s/me$//g" test C:\> message edited by Looge

> Also, in your example you left off the trailing quote. Yes I did, there should be a double quote on the end, I tested it with that, but in the thread here is was removed somehow

> This works for me: > > echo testme| sed "s/me//g" Yes, it does for me, the issue is with the command using the $ sign

It would appear that the issue is with MS This one works on both Windows 7 and 10: echo testme| sed "s/me//g" This one only works correct on Windows 7: echo testme| sed "s/me$//g So what did MS do to change the function? Because: echo testme| sed "s/me//g" works on Windows XP, but echo testme| sed "s/me$//g" does not. Perhaps, as we used to say, it's an undocumented feature?? Might also be how they implemented SED between 32 & 64 bit versions. MIKE http://www.skeptic.com/ message edited by mmcconaghy

It'll not be an undocumented feature (by GNU) since the $ sign is an important regular expression - But I need to have a check on something you mentioned ..

I checked using the 32 and 64-bit GNU toolset, but they have the same issue, on Windows 10. If I run an older version of the same GNU set, it works correctly, but each call gets this warning message. It's a quite technical one, and I can't recall it, but Google says this is because there is some issue when Windows works with old versions of GNU.

Windows 10 comes with ability to run Linux. What happens if you run Linux on Windows and try it? Not sure which distro they use or how they have implemented it. Do not think it's a dual boot situation. I'm on Win 7 so can't give it a try. MIKE http://www.skeptic.com/

I can try to run the Linux thing on Windows 10 - I'm sure that will work just fine.

The Bash on Windows asks me to install the Distribution by visting the Microsoft Store But, my Bash from Cygwin has an interesting behaviour; - the ^ character in SED works just fine - the $ works .. if I use it with PRINTF instead of ECHO So, that explains a bit more where the issue is C:\cygwin32\bin>printf "testabc"| sed "s/abc$//g" test C:\cygwin32\bin>echo testabc| sed "s/abc$//g" testabc C:\cygwin32\bin>echo testabc| sed "s/^test//g" abc C:\cygwin32\bin>

Got it - it turns out the ECHO command, the one that is the internal command from the CMD interpreter, some way or another does not respect the end-of-line character. I don't understand why, but this is the only failure I found in the system. The CygWin module also brings its own echo command, but as a file : echo.exe That one works better, in this context So I'm guessing that I'll be using this one insetad. But then I needed to find out how to get the system's ECHO command not being used. I found that on StackOverflow - not sure if I can share such an URL here - but it works just great. You know, you think you know all ... and then you find another great thing, which is around from at least Windows 7. Anyway, here it is: He's using the internal Windows ECHO command C:\cygwin64\bin>echo testabc| sed "s/abc$//g" testabc C:\cygwin64\bin> But if you use the echo.exe from inside the same directory, it works: C:\cygwin64\bin>dir echo.exe /b echo.exe C:\cygwin64\bin>echo.exe testabc| sed "s/abc$//g" test C:\cygwin64\bin> So, I found this interesting command on StackOverflow, that explains how to override internal commands from the CMD This is how: C:\cygwin64\bin>@doskey echo=c:\cygwin64\bin\echo.exe $* and if you then run the ECHO command: C:\cygwin64\bin>echo testabc| sed "s/abc$//g" test C:\cygwin64\bin>

Although the above works, it's just fixing the exact usage as shown there. The real issue is that the $ no longer accepts DOS style EOL's (end of line, line feed, carriage return, or however it is named). Apparently, Cygwin has changed the behaviour a couple of years ago, so that now you have what is considered the correct behaviour. Note that that behaviour is in the context of files : text files with DOS type EOLs versus Linux/Unix style EOLs. I'm just using the EOL in context of a one line command, where the EOL is just the end of the line, or the end of the command (which is the same in this kind of usage). And since ECHO, the command on Windows that is, uses a Windows EOL ... the subsequent SED command doesn't understand it, and doesn't work on it. The same issue can be see with GREP, or whatever other command allows usage of $ signs. It also is NOT a Windows 10 issue, the reason is just that since Cygwin changed the behaviour, Windows 7 is already around, and Cygwin is already installed on most Windows 7 machines, unlike new installs on Windows 10. When I run the old Cygwin on Windows 10, I get errors left and right, it just doesn't work. 64 or 32 bit has nothing to do with it message edited by Looge

Conclusion (I cannot put my own answer as Best Answer): Cygwin has changed the way in which the EOF characters are handled. It states that NOW it works correctly, and it didn't use to. The result is that it would break your code, and by means of this, they have caused a backwards incompatibility. The issue is not related to Windows 7 or Windows 10, but the change in the Cygwin behaviour did occur somewhere in the life of Windows 10. So, if you have Windows 10, and you download Cygwin: no issue. If you take old Cygwin - which you used on Windows 7 for example - you may be hitting this issue. I think this is a correct reference to the issue: https://ptolemy.berkeley.edu/projec... message edited by Looge