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.
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.
#!/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
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.
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.
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.
from here
What’s the purpose of double forking?
https://stackoverflow.com/questions/10932592/why-fork-twice double forking is a common way to spawn daemons on POSIX systems
I guess I rather should have linked this page, it’s a bit more descriptive: https://skarnet.org/software/execline/grammar.html
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 usesforxorforstdinto loop through all the ‘.wav’ files in that directory and convert them to MP3 withffmpeg. 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.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 {}andbackground {}system was great though.I more often use if { … } instead of foreground. That replaces the use of sh’s
set -eflag and takes up less space. I also set symlinks offoregroundtofgandbackgroundtobg.