So you've got an opinion. And you are loud.
But noone cares. Anon Loli <anonl...@autistici.org> wrote: > On Fri, Aug 30, 2024 at 06:41:50PM +0200, Omar Polo wrote: > > On 30/08/24 18:09, Anon Loli wrote: > > > On Thu, Aug 29, 2024 at 07:03:11PM -0400, Nick Holland wrote: > > >> On 8/29/24 16:11, Anon Loli wrote: > > >>> Okay, I have an vague idea about what happens, let me 1st add this to > > >>> the bug > > >>> report: > > >>> > > >>> So I launched a half a dozen tmux windows and they had archivemedia > > >>> script > > >>> running and while I started all the windows, I went on to edit the > > >>> script and > > >>> add a few lines, > > >> so...you were editing a running script? I do believe that falls under > > >> the > > >> category, "undefined behavior". Yeah, I kinda expect things to go bad > > >> when you do that. > > >> > > >> You are probably assuming the file is loaded in RAM at start and stays > > >> there > > >> until done. That's not how it works, I am pretty sure I've tried it and > > >> not > > >> got away with it before, too. > > >> > > >> Nick. > > > Of course I assumed that the file would be loaded in RAM lol why wouldn't > > > I? > > > > Because it's a waste of both memory and time to load an entire file in > > memory before executing it, especially since the nature of the shell. > > > > Also, IIRC the Thompson shell relied on this to implement conditionals. > > I am not fully aware of "the nature of the shell", but I believe that the > current implementation is a hazard to reliability, brings confusion and > undefined behavior, and is an inconvenience. > > Waste of memory? Look I don't know how many scripts OpenBSD actually executes > like for root/system and what-not, but for the userland, this would be a > extremely minor problem. > I'm assuming that non-root or non-system shells like user-executed shells will > have a extremely small memory and time-to-load resource requirements. > I might as well say that an old computer could function like this. > > > > > > It's the only thing that makes sense to me, but then again I don't know > > > how > > > executing scripts works exactly *shrug*. > > > > > > I would like to know why that is, perhaps this is already answered in > > > e-mails > > > I'm yet to read, but my OS will not have this unlogical and unreliable and > > > actually I'm assuming that this is also UNDOCUMENTED undefined behavior, > > > and as > > > > > > such, ksh.1 manual page is at fault here, this is a bugs. > > > > unfortunately, this is how unix actually works. Even if ksh used > > memory-mapped I/O, it could still concurred edits to the files. Heck, in > > some cases using memory-mapped I/O could lead to worst issues (imagine a > > concurrent process truncating the file while you're reading it, and say > > hello to SIGBUS.) > > If the issue is as serious as you make it, and if there is no other approach > to > this which can prevent this issue, then: > you could get the file modes of the file, change it to read-only to the > users/groups who already could read it, read it to memory, and then chmod it > to > the original file modes. > > By the way, what is this "\xc2\xa0" twice, some Android version of quotes? > > > > > > Note that this also depends on how the editor you're using writes the files > > back to the disk. Some editors will just rewrite the file in-place, which > > means that other processes can see these concurred edits, while others will > > use a tempfile + rename scheme. No one is strictly better than the other. > > Interesting. > The issue happens when editing with vi(1) as well as neatvi. >
