On 2024/08/30 17:51:55 +0000, 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.
Before complaining about "hazards to reliability" & co, I'd suggest you to step down, study the system, understand the expectations and how the various primitives work, and only then, eventually, come back talking about how to improve. If you do, you would know how we handle these things on UNIX. Because none of this is OpenBSD specific. > 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. I'd be interested in knowing the research you did to come to this conclusion. I'm also sure that you are greatly missing the point by not realizing how nothing of this is really ksh(1) specific. (I'm serious. do you know you can crash patch(1) by concurrently modifying the file it is patching? Oh, the horror!) You can't pick up a tool you don't know how to use, only to then complain how it is a security hazard. Learn first how it is expected to be used. > > > 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. how does "atomicity" fit into this scheme? You're trying to fix a problem by opening another (but way bigger!) can of worms. What we really do on unix is to do what install(1) does. or at least that's a way. so, ksh parsing bugs notwithstanding, I'd file what you saw with concurred edits to script as "working as indended." > By the way, what is this "\xc2\xa0" twice, some Android version of quotes? probably some unicode space. I replied from (gasp!) linux with thunderbird, and I still haven't found a way to fully addomesticate it. Luckily i only have to use it for work :p
