bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: When using -i, consistently creates a sed file at current working di


From: Bob Proulx
Subject: Re: When using -i, consistently creates a sed file at current working directory on Windows10
Date: Sat, 13 Feb 2021 18:32:30 -0700

Minh-Tâm TRAN wrote:
> Hello,

Hello!  You have mailed bug-gnu-utils which is a low use catch-all
mailing list for projects which do not have their own mailing list.
But you are talking about sed and sed does have its own mailing lists.

> In a company working with Windows OS, I am trying to get used to tools from
> the unix world.

Very good!  Welcome to the world of Unix! :-)

> I think I found a bug using sed on version 4.2.1 on Windows 10 that I got
> from http://gnuwin32.sourceforge.net/packages/sed.htm

GnuWin from http://gnuwin32.sourceforge.net/ is a "port" of GNU sed
over to windows.  And as I look at it right now it was last updated 27
December 2010.  Wow!  That was 10 years ago.  I don't know but I think
that port might be dead.

I think that a newer port of sed to Windows might be the best thing.
I do not run MS-Windows myself and do not know where to suggest to get
a newer port to Microsoft for sed.  That would be a good thing to ask
on the sed discussion list < sed-devel AT gnu.org > .  

    sed-devel@gnu.org

> Given a file named "foo", containing the string "bar",
> The following command:
> 
> sed -i "s/bar/baz" foo
> 
> correctly transforms "bar" to "baz" in the file "foo".

Good.

> However, I always have a sed[something] file that is created in the
> directory from which I run the scrip.
> For example: sedObrnzt
> 
> I have tried the following commands, which give the same outcome:
> sed -i"" "s/bar/baz" foo
> sed --in-place "s/bar/baz" foo
> sed --in-place= "s/bar/baz" foo
> sed --in-place="" "s/bar/baz" foo
> 
> Is it reasonable to ask for a fix ?

This sounds like a bug in the GnuWin port from December 2010.  It does
not exist in the native sed program.

> I observed that sed version 4.0.7 does not have this issue, but it would
> still be nice to fix it in version 4.2.1 I think.

The current version is sed 4.8 but I think you simply need a fixed
"port" of any version of sed.

Good luck! :-)
Bob



reply via email to

[Prev in Thread] Current Thread [Next in Thread]