The editing is perfectlty safe.
It is the reading of a file that is being changed that is unsafe.
Of course there's Microsoft Windows.
>- --- Original Message --- -
>From: [EMAIL PROTECTED]
>To: misc@openbsd.org
>Sent: Fri, 7 Oct 2005 09:39:47
>
>OM> I know this behaviour form eve
OM> I know this behaviour form every Unix system I've worked on. Besides,
OM> the nice thing about the current way of doing things is that you can
OM> read a script form a pipe and have the desired behaviour without any
OM> special case code.
This behavior has any advantages for regular files ? Co
Otto Moerbeek wrote:
> On Thu, 6 Oct 2005, Han Boetes wrote:
> > In the meanwhile this behaviour has been changed in CVS.
> > Perhaps this will get backported as well. And if not it's
> > pretty easy to backport I'd guess.
>
> What commit are you referring to? You can say that I'm closely
> involve
On Thu, 6 Oct 2005, Han Boetes wrote:
> Andreas Kahari wrote:
> > Yes, sh(1) will probably keep a descriptor to the old file and
> > keep using it until done.
> >
> > However, does this have any kind of other implications? The
> > behaviour that Ilya pointed out would not occur to me to be
> > exp
Andreas Kahari wrote:
> Yes, sh(1) will probably keep a descriptor to the old file and
> keep using it until done.
>
> However, does this have any kind of other implications? The
> behaviour that Ilya pointed out would not occur to me to be
> expected...
In the meanwhile this behaviour has been ch
On Thu, 6 Oct 2005, Andreas Kahari wrote:
> On 06/10/05, Ilya A. Kovalenko <[EMAIL PROTECTED]> wrote:
> > TK> just edit a copy, chmod +x and mv(1) it into place.
> >
> > Slightly complicated, but works, because mv(1) removes
> > old file, so sh(1) working either old version or new one
> > (no "h
On 06/10/05, Ilya A. Kovalenko <[EMAIL PROTECTED]> wrote:
> TK> just edit a copy, chmod +x and mv(1) it into place.
>
> Slightly complicated, but works, because mv(1) removes
> old file, so sh(1) working either old version or new one
> (no "hybrids").
Yes, sh(1) will probably keep a descriptor t
TK> just edit a copy, chmod +x and mv(1) it into place.
Slightly complicated, but works, because mv(1) removes
old file, so sh(1) working either old version or new one
(no "hybrids").
On Wed, Sep 28, 2005 at 11:53:08AM +0800, Ilya A. Kovalenko wrote:
Hello,
> Greetings,
>
> I found out that sh(1) reads file in process of execution (instead of
> read whole file and execute it from memory image), which makes
> editing such scripts unreliable and/or dangerous. Is there an
correction, for logs:
My first conclusion that "sh(1) reads file in process
of execution" was wrong.
Looks like when file size is increasing during script
execution, sh(1) additionally executes file "tail" (starting
at old EOF seek position).
I guess, this behavior is useless (and dangerous)
Greetings,
I found out that sh(1) reads file in process of execution (instead of
read whole file and execute it from memory image), which makes
editing such scripts unreliable and/or dangerous. Is there any
existing ways to solve this problem ?
Is there sense to make sh(1) to read whole
11 matches
Mail list logo
