delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2009/07/14/02:31:22

X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
From: Juan Manuel Guerrero <juan DOT guerrero AT gmx DOT de>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: ANNOUNCE: DJGPP port of GNU Sed 4.2 uploaded.
Date: Mon, 13 Jul 2009 23:24:24 -0700 (PDT)
Organization: http://groups.google.com
Lines: 97
Message-ID: <d9d3a6ef-53c2-44ca-b406-16f76e351d2a@p28g2000vbn.googlegroups.com>
References: <200906080112 DOT n581CI65027120 AT delorie DOT com> <2ebe0f9b-17d8-4f6b-af78-d9468d0dab77 AT 26g2000yqk DOT googlegroups DOT com>
<4A58F9BF DOT 70601 AT iki DOT fi> <4a53692e-1d26-4742-bcd9-438819986a50 AT f10g2000vbf DOT googlegroups DOT com>
NNTP-Posting-Host: 88.79.153.12
Mime-Version: 1.0
X-Trace: posting.google.com 1247552665 26132 127.0.0.1 (14 Jul 2009 06:24:25 GMT)
X-Complaints-To: groups-abuse AT google DOT com
NNTP-Posting-Date: Tue, 14 Jul 2009 06:24:25 +0000 (UTC)
Complaints-To: groups-abuse AT google DOT com
Injection-Info: p28g2000vbn.googlegroups.com; posting-host=88.79.153.12;
posting-account=OsAajgoAAADdKJnkJkmhzqP0jo6I_P_0
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; WOW64;
SV1; .NET CLR 2.0.50727; .NET CLR 1.1.4322; .NET CLR 3.0.04506.30; .NET CLR
3.0.04506.648; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729),gzip(gfe),gzip(gfe)
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

On 11 Jul 2009 00:32:04, "Rugxulo" <rugxulo AT gmail DOT com> wrote:

> Hi,
>
> On Jun 7, 5:25=A0pm, "Juan Manuel Guerrero" <juan DOT guerr DOT  DOT  DOT  AT gmx DOT de>
> wrote:
> >
> > This is a port of GNU Sed 4.2 to MSDOS/DJGPP.
> >
> > =A0 Send suggestions and bug reports concerning the DJGPP port
> > =A0 to comp.os.msdos.djgpp or <dj DOT  DOT  DOT  AT delorie DOT com>.
>
> I'm not sure this is technically a bug since it seems to still work as
> expected, but I'm mentioning it anyways just FYI. It doesn't do this
> (complain) on Windows at all.
>
> ------------------------------------------------------------------
>
> [ FreeDOS ] Sat 07/11/2009>cat tony.txt
> hello world
>
> [ FreeDOS ] Sat 07/11/2009>d:\utils\sed -i "s/hello/goodbye/" tony.txt
> d:/utils/sed.exe: preserving permissions for `./seaaaaaa': Function
> not implemented (ENOSYS)
[snip]


It is certainly not a bug.  All 100% MSDOS compatible OS
must produce this error message.
The same happens on Windows if you set LFN=n.

The reason is that the gnulib code defaults to chmod() as
a last resort to change the file permissions.  This is the
case with DJGPP.  DJGPP's implementation of chmod() calls
INT21 func 0x7143 to get/set file attributes if LFN support
is available and func 0x4300/0x4301 if only SFN support is
available.  The -i option works by writing the output into
a temporary file.  IIRC sed tries to rename and change file
permissions while the temporary file is still open.  This
makes func 0x4300/0x4301 fail in this way.  There is
nothing special here.  ENOSYS is what Windows/MSDOS always
returns in this case and this is recorded by DJGPP's errno
and passed to the caller.  Every MSDOS compatible OS must
implement func 0x4300/0x430 in this way.  On a UNIX mashine
the code will never produce error messages because changing
names and permissions is allowed while files are still open.
This issue was already tzreated in thread here.
I was aware about this issue and I tried to suppress this
error message.  Unfortunatly the function that calls chmod()
is called by two different functions and I fixed only one
of them and missed the other one.



On 11 Jul 2009 15:20:35, "Rugxulo" <rugxulo AT gmail DOT com> wrote:

[snip]
> BTW, 4.1.5 didn't complain. I honestly still never
> understood if you thought 4.1.5 was broken (rename) or if that was
> just some change in 4.2 due to Gnulib. 4.1.5, even with "-i", always
> seemed to work for me (plain DOS, SFNs).

4.1.5 is over 3.5 years old.  In those days they do not use
gnulib so that some of the issues did not rise.  The backup
filename generation is certainly broken.  If a backup prefix
und suffix is given and only SFN support is available, then
the filename is generated by prepending the prefix and
adding the suffix to the end of the original filename
without checking if it exceeds the 8+3 filename limit.
This name is passed to the DOS function and truncated by
that function.  This may work or not.  Example: filename is
foobar.txt and -iback_*_up is given as option.  Then the
following backup filename is generated: back_foobar.txt_up.
This will be truncated by DOS to back_foo.txt.  The suffix
is completely descarted because it does not fit into 3
characters long extension.  I have changed this in such a
way that the required amount of characters are removed from
the extension to allow to fit the given suffix.  The idea
is to allow for scripts that may produce backups like this
-i*NNN where NNN stands for a backup number.  In this case
-i*1 will make a backup filename like this foobar.tx1.
The real difficulties ariesed with the use of gnulib to
replace all the old file handling stuff.  The way files
are created, read and written by gnulib and sed is very
UNIX centric without taking into acount that certain
used techniques will only work with POSIX filesystems.
It should be clear that the use of gnulib and the way sed
handles the file operations makes it very difficult to
create a port compiling the sources out-of-the-box.
The reason is quite simple Windows/DOS is not very POSIX
compatible.
May be I will created a new update of the port to suppress
the error message reported.


Regards,
Juan M. Guerrero

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019