1. 4

    I’d like to spend one single day watching @SirCmpwn working. I don’t understand how someone with a regular job can get so much done in their free time.

    Keep up the work the great work! I’ll definitely migrate to sway as soon as the porting to wlroots is finished.

    1. 4

      I don’t understand how someone with a regular job can get so much done in their free time.

      With lots of help!

    1. 6

      One of these days you should write something about productivity. It amazes me how much work you get done in such a methodical way. Congratulation for your work, I can’t wait to try Oil Shell!

      1. 3

        Thanks for the support! I’ll answer briefly here – I have a few “advantages”, and one “meta” tip.

        1. I had 7 years of projects that went almost nowhere, so all those learning experiences allow me to develop Oil faster. Examples: http://andychu.net/projects/
        2. I actually found some references to an “oil shell” I had in mind going back to 2013 or 2012! There was almost no code, but there was some design. So I’ve been thinking about this problem for a long time. (There is a longer story if anyone wants to hear it – I actually suggested to Rob Pike and Russ Cox in 2009, in person, that there be a better shell to complement Go’s “better C”. This might have been before Go’s open source release.)
        3. I took a break from work in early 2016, and unsurprisingly, being full time helps!

        So if you take all that into account, my productivity probably isn’t out of the ordinary (at least for someone with 14 years of professional experience).

        Also, take into the account the fact that I’m writing this in Python, and that is like a “superpower” if you compare doing the same work in C or C++. I started this project with 2000-3000 lines of C++, and I wouldn’t have gotten anywhere close to finished if I had stayed on that course.

        If I have one tip, it would be “don’t get stuck”. My previous projects involved a lot of design, and truly clean slate design without any users makes it more likely that you’ll get stuck on something, or waste effort.

        This one is more constrained because I made the decision to be compatible. I think this has helped in a lot of ways, one being that I don’t really get stuck. I just have to make things work roughly the way bash does, sometimes cursing it, sometimes documenting deviations and planning for better semantics in Oil, but I don’t get stuck.

        If you don’t get stuck for 20 months, work full time, and don’t work on anything that’s not in the finished product, a lot of things will get done!

      1. 4

        First, to call itself a process could [simply] execute /proc/self/exe, which is a in-memory representation of the process.

        There’s no such representation available as a file. /proc/self/exe is just a symlink to the executable that was used to create the process.

        Because of that, it’s OK to overwrite the command’s arguments, including os.Args[0]. No harm will be made, as the executable is not read from the disk.

        You can always call a process with whatever args[0] you like. No harm would be done.

        1. 4

          Although /proc/self/exe looks like a symbolic link, it behaves differently if you open it. It’s actually more like a hard link to the original file. You can rename or delete the original file, and still open it via /proc/self/exe.

          1. -4

            No harm will be made, as the executable is not read from the disk.

            the executable is definitely read from the disk

            Again, this was only possible because we are executing /proc/self/exe instead of loading the executable from disk again.


            The kernel already has open file descriptors for all running processes, so the child process will be based on the in-memory representation of the parent.

            no that’s not how it works, and file descriptors aren’t magic objects that cache all the data in memory

            The executable could even be removed from the disk and the child would still be executed.

            that’s because it won’t actually be removed if it’s still used, not because there’s a copy in memory

            <3 systems engineering blog posts written by people who didn’t take unix101

            1. 12

              Instead of telling people they are idiots, please use this opportunity to correct the mistakes that the others made. It’ll make you feel good, and not make the others feel bad. Let’s prop up everyone, And not just sit there flexing muscles.

              1. 3

                Sorry for disappointing you :)

                I got that (wrongly) from a code comment in Moby (please check my comment above) and didn’t check the facts.

                1. 2

                  I’m not saying that the OP was correct, I’m just saying that:

                  /proc/self/exe is just a symlink to the executable

                  ,,, is also not completely correct.

              2. 3

                Thanks for pointing out my mistakes! I just fixed the text.

                I made some bad assumptions when I read this comment [1] in from from Docker and failed to validate it. Sorry.

                By the way, is it just by bad English or that comment is actually wrong as well?

                [1] https://github.com/moby/moby/blob/48c3df015d3118b92032b7bdbf105b5e7617720d/pkg/reexec/command_linux.go#L18

                1. 1

                  that comment is actually wrong as well?

                  I don’t think it’s strictly correct, but for the purpose of the code in question it is accurate. That is, /proc/self/exe points to the executable file that was used to launch “this” process - even if it has moved or been deleted - and this most likely matches the “in memory” image of the program executable; but I don’t believe that’s guaranteed.

                  If you want to test and make sure, try a program which opens its own executable for writing and trashes the contents, and then execute /proc/self/exe. I’m pretty sure you’ll find it crashes.

                  1. 3

                    but I don’t believe that’s guaranteed.

                    I think it’s guaranteed on local file systems as a consequence of other behavior. I don’t think you can open a file for writing when it’s executing – you should get ETXTBSY when you try to do that. That means that as long as you’re pointing at the original binary, nobody has modified it.

                    I don’t think that holds on NFS, though.

                    1. 1

                      If you want to test and make sure, try a program which opens its own executable for writing and trashes the contents, and then execute /proc/self/exe. I’m pretty sure you’ll find it crashes

                      Actually, scratch that. You won’t be able to write to the executable since you’ll get ETXTBUSY when you try to open it. So, for pretty much all intents and purposes, the comment is correct.

                      1. 1

                        Interesting. Thank you for your insights.

                        In order to satisfy my curiosity, I created this small program [1] that calls /proc/self/exe infinitely and prints the result of readlink.

                        When I run the program and then delete its binary (i.e., the binary that /proc/self/exe points to), the program keeps successfully calling itself. The only difference is that now /proc/self/exe points to /my/path/proc (deleted).

                        [1] https://gist.github.com/bertinatto/5769867b5e838a773b38e57d2fd5ce13

                  1. 1

                    Wow, this was smooth! Congratulations to everyone involved!

                    Just out of my curiosity, the site was running on OpenBSD before?

                    1. 3

                      Thanks for sharing!

                      I’m getting 502’ ed at the moment, but I was able to check a few topics. I’ll make to check it out again on my next endevours.

                      Congratulations for the work!

                      1. 2

                        Sorry about 502. We just pushed a big update since our links were not working on mobile. Should be up now.

                        I hope you like it. Would love to hear your thoughts. :)

                      1. 1

                        The language does have annoyances. The absence of const is a minor one.

                        Was he talking about const here or I’m missing something?

                        1. 4

                          const in method/function arguments. const in Go has limited uses, and is effectively the most basic #define in C, though it does support some compile-time arithmetic.

                          1. 1

                            Cool, thanks!