Have you even bothered to check any of the man pages or existing documentation? Perhaps the reason some of these examples seem a bit sparse is that they are filled with filler/example/boilerplate text use to illustrate the usage, not to serve as a definitive guide for all users.
In the examples above, the
tv.xml
was implied to mean the name of the XMLTV-formatted guide infomration residing on disk. Likewise, the
/path/to/xmltv.sock
is used to show where one would input the full and absolute path to where Tvheadend creates the the socket it listens for XMLTV data on. If you bothered to check your installation of Tvheadend, you will see that under "Configuration > Channel / EPG > EPG Grabber Modules" there is an "External: XMLTV" item in the "EPG Grabber Name" list. Then, under that item's "Parameters" pane, under the heading "Settings", you'll find an item labeled "Path:". On my machine, this is
/home/hts/.hts/tvheadend/epggrab/xmltv.sock@; where that socket may exist on your machine is unknown to me. Hence, when using sample filenames and paths, it is fairly common in examples to see something like: @/this/is/the/full/and/absolute/path/to/this/file.ext@. (Likewise for the @tv.xml
file: I have no idea if you store your XMLTV data in a file called
tv.xml@, but it ought to be obvious that that file represents the XMLTV data file.)
The @socat
command looks pretty self-explanatory: Use
cat
to pipe the data from
tv.xml
to the
standard input
of
socat@, which in turn will take the data it receives on the @standard input
(the
-
file input option) and outputs it to a Unix Domain Socket that exists at
/path/to/xmltv.sock@).
Similarly, the @netcat
command is pretty simple: Use
cat
to pipe the data from
tv.xml
to the
standard input
of
netcat
(invoked by the command
nc@), which in turn will take the data it receives on the @standard input
(the
-
file input option) and outputs it to a Unix Domain Socket that exists at
/path/to/xmltv.sock@, waiting up to 5 seconds for data to be received before it times out (the @-w 5
option).
I can understand how the
curl
command might need a bit more explanation, but it's really rather convoluted and re-appropriating the command to do something it wasn't ever really supposed to do. Both
socat
and
netcat
embody the idea of applications on *nix systems: Do one thing and do it well.
The answers to what all of the command line options mean could easily have been found by browsing the man pages of the commands in question. When encountering any new command, browsing its man page should be the first thing you do so you understand what the command is doing. Blindly following directions and cut-and-pasting from the internet is a surefire way to invite disaster.
I don't know if the options I provided for the examples commands would need to be changed, or if other options would be necessary. However, if you browsed the man page, you could easily find the answer.
Also, if you are building an image for use on an embedded device, I (rather foolishly, in hindsight) assumed that you had some knowledge and familiarity with the command line, man, and command options. I'll take the blame on that account for assuming more than I should have.
However, the examples were meant to merely be skeleton examples, not a full and complete step-by-step howto tailored to your needs.
