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.
