• naught101@lemmy.world
    1·
    17 minutes ago

    Damn, I really could have made a lot of use of this over the last 20+ years… Thanks for sharing!

  • provectus@lemmy.mlEnglish
    4·
    1 hour ago

    Did you know openBSD does not have this folder? I think the BSD’s do not use /proc. I do not know why though.

  • otacon239@lemmy.world
    29·
    3 hours ago

    Okay, this is legitimately cool as heck. This finally helps me wrap my head around the “everything is a file” concept in Linux. Of course it can just copy the executable to memory for later reference. That’s how the system would not completely have a meltdown when you do live updates.

    Excellent share!

    • atzanteol@sh.itjust.worksEnglish
      14·
      2 hours ago

      It’s a bit more interesting than that…

      Linux, unlike Windows, will let you delete a file that is actively in use. It removes the reference on the file system but the contents of the file won’t be deleted until all file pointers to it close. In fact it will still be seen as taking up disk space until it’s garbage collected (deleting a large file that’s in use can be frustrating).

      So the file is actually still available to that running process. If you replace it with a new executable and run that then you get the new version.

  • twkm@programming.dev
    1·
    2 hours ago

    It’s wonderful but can be less complete or even missing typically due to settings (e.g., security), the environment (e.g., a container), or both.

  • lyralycan@sh.itjust.works
    13·
    4 hours ago

    Great tips! Although if i may 🤓 just a little for the top right, it works because what you deleted isn’t the binary, it’s the pointer that points to the binary’s location. The data is still exactly as it was before “deletion”; the symlink is simply a copy of the original pointer’s info; and I’m speculating that the existence of any pointer prevents the system from recycling those addressed bits.

    • bruh@nord.pubEnglish
      3·
      3 hours ago

      it merely deletes the inode from the directory instead of overwriting the actual data on the disk

  • pelya@lemmy.world
    6·
    4 hours ago

    Do you know how to build portable executables?

    configure --prefix=/proc/self/pwd

    It even works in .so files and libtool.

      • pelya@lemmy.world
        3·
        2 hours ago

        The executable will search for .so files not inside predefined paths like /usr/lib but inside it’s current directory. You may theoretically put . as an argument to configure, but it converts that into an absolute path, snd libtool and linker fail when encountering relative paths inside shared library dependencies.

      • pelya@lemmy.world
        2·
        2 hours ago

        --prefix=$(pwd) is resolved at compile time. If you move your compiled .so files to a different directory, they stop working.

        • eleijeep@piefed.socialEnglish
          2·
          2 hours ago

          I see what you mean, very clever solution if a program is using the configure prefix by compiling it into the binary.

          That can’t be very common though is it? Usually the configure prefix is just used by make install to install the binaries into the prefix. If the compiled program needs to know where it is installed it can read argv[0].

          Have you seen this used somewhere?

          • pelya@lemmy.world
            2·
            2 hours ago

            I am using this myself in Android app, where you can write files only inside /data/data/your.app.id/

            So naturally, if you want to publish a different app, your.app.id will be different, so you need to recompile all your Linux tools that you bundle inside your app.

            If you are not running your Linux tools on Android, you’d probably be better off using Docker or a chroot.