1. 4

    There is one aspect where Ed maybe has an actual advantage: It keeps you in write mode and discourages editing. I will consider using Ed for journalling where I currently use vim.

    1. 3

      There is one aspect where Ed maybe has an actual advantage: It keeps you in write mode and discourages editing.

      cat > $filename will do that, too, but with ed I can switch back to command mode, save what I’ve done so far, and then continue by returning to append mode.

      Though I could probably do the same with cat >> $filename, but I’m afraid I’d forget that I need to type > twice to append and end up overwriting the file. :)

      1. 2

        This is why I prefer writing drafts in a chat with myself. Also because of the enforced pacing: the rhythm of hitting Enter when a line is done, and the leaving it as it is.

        1. 1

          or use ex, similar enough to ed, has the vi : commands, and vi is one command away

        1. 9

          Have you heard of vi? It’s a “visual” mode for ed. A truly amazing innovation. It lets you see the file while entering ed commands, and changes get reflected immediately.

          1. 2

            ex is not ed. i have often wished for ve instead of vi though

            1. 2

              Isn’t that, mostly, sam?

            2. 1

              vi, vi, vi - the editor of the beast

              vi, vi, vi - the one for you and me

            1. 2

              Should have an option to emit TAP

              1. 1

                +1

                I’ll definitely look into that, thanks

              1. 1

                i was able to build the gcp cups connector with a few changes on openbsd

                1. 2

                  My vim annoyance is that it’s not emacs. (Trollface)

                  1. 6

                    my vim annoyance is that its non nvi

                  1. 7

                    I frown at putting all of Perl into a chroot, but there isn’t really a good alternative. You could use FastCGI, run the Perl process outside of the chroot and leave its socket in /var/www, so that httpd/nginx only has access to the socket and there are no Perl guts inside the chroot to use, but the Perl script should really then be chrooted separately.

                    This gets much uglier with big things like Ruby on Rails.

                    1. 3

                      The purpose of the perl-in-chroot portion of the article was more like ‘hey, this is how you would do it if you wanted to’. As I mentioned in the article itself, I only host static content.

                      1. 1

                        Hopefully it'l eventually support something like proxying to a second http daemon, so for Perl you could chroot perl + Starman, and have httpd proxy to it

                      1. 7

                        cron is one of those necessary tools that could really use an evolutionary functionality step to clear cruft like this out of the way. Another example is error/output handling, an issue that makes a tool like cronic necessary: http://habilis.net/cronic/

                        1. 8

                          https://wiki.archlinux.org/index.php/Systemd/Timers#As_a_cron_replacement if you’re ok with the creeping horror that is systemd

                          1. 0

                            Upvoted as informative and that’s all. ;)