1. 29
    1. 5

      I have two use-cases for execline: a) daemon init scripts and b) as a stub loader for Python scripts.

      As a stub loader, I use execline to specify things like the Python interpreter (virtualenv), default input and output files, and if necessary modifications to PYTHONPATH. I also use it to set resource limits, run helper programs, or change behavior if I’m running a program from a tty–typically piping the output through a pager. This lets me separate environment configuration and affordances from the work of the script itself–particularly helpful when the environment changes between machines I run a Python script on.

      The author is tremendously responsive on IRC. I run a nightly execline build against master and it happened once that we got to chat about a build failure. You should use a release version of the software, but I enjoyed the excuse to talk to the author about their project.

    2. 2

      -d : doublefork. If the -d option is set, prog1… will run as a grandchild of background.

      from here

      What’s the purpose of double forking?

      1. 5

        https://stackoverflow.com/questions/10932592/why-fork-twice double forking is a common way to spawn daemons on POSIX systems

    3. 2

      I guess I rather should have linked this page, it’s a bit more descriptive: https://skarnet.org/software/execline/grammar.html

      1. 4

        Neither link was very clear to me without close reading and hard thought. I think you could make both pages clearer by displaying some example execline scripts. For example, show a script that cds into a directory and then uses forx or forstdin to loop through all the ‘.wav’ files in that directory and convert them to MP3 with ffmpeg. I have written a similar script before for my preferred shell (Fish), so the differences would be instructive. An example would also make it easier to visualize execline‘s compilation process.

        1. 3
          #!/usr/bin/env execlineb
          # Some commands look like their shell equivalent, but "cd" is its own binary and
          # not a built-in. Note that the whole script could have been written in a single
          # line without any ';'.
          cd directory
          # '*' has no special meaning in execline. The elglob program shipped with
          # execline provides file name globbing. It immediately subtitute the pattern.
          elglob g *.wav
          # "$g" is now expanded to a list of file names. "forx" loops over the list
          # filling "x" environment variable successively with each entry.
          forx x { $g }
          # The words starting with '$' are not automatically expanded into the content of
          # the matching environment variable. This is the job of importas, which has
          # some of the ${special:?features} of ${shell:-expansion}
          importas wav x
          # "backtick" has the role of x=$(sub shell expansion)
          backtick x {
                  # heredoc replaces the bash-specific "sed 's///' <<<string" or the
                  # POSIX sh's "echo string | sed 's///'"
                  heredoc 0 $wav sed "s/.wav/.opus/"
          importas opus x
          # note that there is no problem with spaces in the name of the files: they are
          # not split automatically (this requires a flag of importas, where you can also
          # specify the IFS).
          ffmpeg -i $wav $opus
    4. 2

      Back when I made my (now long abandoned) Linux From Scratch installation, I used s6 and execline for my init system. Overall it was a very pleasant experience; Skarnet’s software is good at what it does.

      That said, the execline syntax is rather verbose, especially for loops, variable substitution and if-statements. The foreground {} and background {} system was great though.

      1. 1

        I more often use if { … } instead of foreground. That replaces the use of sh’s set -e flag and takes up less space. I also set symlinks of foreground to fg and background to bg.