1. 14
  1.  

  2. 4

    I simultaneously see the appeal of this and find it terrifying.

    This:

    $ cat parallel.pow
    kapow route add '/parallel/{ip1}/{ip2}' - <<-'EOF'
         ping -c 1 -- "$(kapow get /request/matches/ip1)" | kapow set /response/body &
         ping -c 1 -- "$(kapow get /request/matches/ip2)" | kapow set /response/body &
         wait
    EOF
    

    feels like a massive footgun waiting to happen, depending on what command you’re calling and who can make requests to your interface.

    It’s easy to imagine scenarios where this is extremely useful and the footgun isn’t a real threat, though. Nice idea.

    1. 1

      You’re right, it is kind of scary.

      I have worked specifically to make this sort of connection of web server to scripting language optional in my web app.

      1. 1

        another thing I thought is that kapow must be using some ambient environment to work and on cursory glance of the source code, it doesn’t appear very secure, it just throws data at locally listening http inet sockets without authentication..

      2. 3

        this is a great idea.

        i think there may be a typo in your first example? should grep be echo?

        1. 1

          Nope. They’re basically searching for a string in a file. cat file displays a file. That is piped to grep <SOMETHING>. (grep “File not found” or what was it). Grep re filters only those lines containing the search string.

          They could’ve shortened it: grep "File not found" access.log | kapow whatever to be more clear I guess.

        2. 2

          I would usually use a CGI endpoint for something similar, however this looks easier to work with than CGI. interesting idea.

          1. 1

            Did somebody else spot the “Useless Use of Cat” thing there in the first example or is it just me? Kinda not inspiring for a person doing things with shell. This isn’t a complaint, not even a nitpick really, just my age showing and me smiling slightly at irrelevant things I notice.

            1. 1

              Avoiding UUoC is often a premature optimization. I do not know whether this one was intentional or not, but I quite often do UUoC because it is more readable – you can read the pipeline from left to right without skipping back and forth. Data just flows from the left side to the right side.

              1. 2

                you can still use <file command and it will be better compared to cat file | command

                From wikipedia

                Beyond other benefits, the input redirection forms allow command to perform random access on the file, whereas the cat examples do not. This is because the redirection form opens the file as the stdin file descriptor which command can fully access, while the cat form simply provides the data as a stream of bytes.

                1. 2

                  you can still use <file command

                  I know, but I still (it becomes bit nitpicking) miss the „|“ separator of the pipeline stages. However I agree that data flows in the right direction.

                  Beyond other benefits, the input redirection forms allow command to perform random access on the file, whereas the cat examples do not. This is because the redirection form opens the file as the stdin file descriptor which command can fully access, while the cat form simply provides the data as a stream of bytes.

                  This is also another reason to use UUoC. I sometimes do it this way to be sure that the command will not manipulate with the source file. It is not a security measure, but it protects you from shooting yourself in the foot.

                  1. 1

                    I sometimes do it this way to be sure that the command will not manipulate with the source file

                    I haven’t come across such a situation, can you give an example/link?

                    1. 2

                      Probable simplest example is gzip/gunzip vs. sed – if someone knows that these commands compresses/uncompresses data or transforms them (replace strings…), he might use these commands in the pipeline without knowing the -k and -i options.

                      If you do:

                      gzip file.txt
                      

                      the compressed file.txt.gz is created and original file.txt disappears which might confuse someone.

                      If you do:

                      sed 's/aaa/bbb/g' file.txt
                      

                      you get transformed output on STDOUT and the file remains unmodified – i.e. different behavior compared to gzip.

                      Yes, the normal way is to consult the manual and learn about the -k and -i switches.

                      But you can also do:

                      cat file.txt | gzip > file.txt.gz
                      cat file.txt | sed 's/aaa/bbb/g' > modified-file.txt
                      

                      Honestly, it is usually not the preferred way. But beauty of this approach is that it is consistent and based on few simple principles.

                      So I often do gzip -k or sed -i – but sometimes I also do things like described above, because I like the purity and consistency.

                      When doing something more complex (but still staying in the shell), it is good to structure the code and compose the program from smaller reusable pieces with well-defined interface – i.e. create your own shell functions or commands. The function can magically work with many files, read and write environmental variables etc. Or it can be a pure stream function without side effects that just transforms the STDIN to STDOUT. It is not just about the beauty but it also allows designing cleaner and more reliable and readable scripts.

                      1. 1

                        Thanks for explaining your reasoning. I have used both these commands but didn’t think from the perspective you are painting here.

                2. 1

                  Your defense of UUoC is as much of an internet tradition as the UUoC award itself. (And I agree with your justification for it, especially the part about knowing it’s immutable… I simply found it amusing that this kind of justification was foreseen 20+ years ago.)