Re: runit still doesn't work
Reply #15 –
Since my previous brief posts were ignored or dismissed as "arrogance", let's try with the more verbose approach.
Searching the web (or "googling") is one very popular, and mostly effective, way to get information. For example, it yields this answer.
But even without that, in Unix-like systems, manual pages explain most of the details such as this one. However, to use manual pages one needs to have patience and a stable attention span, something that most people seem to lack these days. Knowing key bindings for less(1), pager program used by man(1), also helps. (For example, pressing / and typing a regular expression, followed by Enter, allows one to forward-search for text satisfying that regular expression inside the manpage. Pressing n finds the next occurence, N goes back.) But I digress.
Typing
man 1p exec
gives the manual page for exec(1p), a part of which is:
Redirections are explained in manual pages of most shells and in POSIX standard. For example, typing
man bash
followed by typing /^REDIRECTION and pressing Enter leads to the following section:
REDIRECTION
Before a command is executed, its input and output may be redirected
using a special notation interpreted by the shell. Redirection allows
commands' file handles to be duplicated, opened, closed, made to refer
to different files, and can change the files the command reads from and
writes to. Redirection may also be used to modify file handles in the
current shell execution environment. The following redirection opera‐
tors may precede or appear anywhere within a simple command or may fol‐
low a command. Redirections are processed in the order they appear,
from left to right.
Each redirection that may be preceded by a file descriptor number may
instead be preceded by a word of the form {varname}. In this case, for
each redirection operator except >&- and <&-, the shell will allocate a
file descriptor greater than or equal to 10 and assign it to varname.
If >&- or <&- is preceded by {varname}, the value of varname defines
the file descriptor to close. If {varname} is supplied, the redirect‐
ion persists beyond the scope of the command, allowing the shell pro‐
grammer to manage the file descriptor himself.
In the following descriptions, if the file descriptor number is omit‐
ted, and the first character of the redirection operator is <, the re‐
direction refers to the standard input (file descriptor 0). If the
first character of the redirection operator is >, the redirection
refers to the standard output (file descriptor 1).
The word following the redirection operator in the following descrip‐
tions, unless otherwise noted, is subjected to brace expansion, tilde
expansion, parameter and variable expansion, command substitution,
arithmetic expansion, quote removal, pathname expansion, and word
splitting. If it expands to more than one word, bash reports an error.
Note that the order of redirections is significant. For example, the
command
ls > dirlist 2>&1
directs both standard output and standard error to the file dirlist,
while the command
ls 2>&1 > dirlist
man 3p stdin
for more information.
Now let's try an example:
$ cat redir
#!/bin/sh
exec 2>cat.err
exec 1>cat.out
exec cat foo
$ ls -l redir
-rwxr-xr-x 1 strajder strajder 53 Mar 20 13:58 redir
$ ./redir
$ cat cat.out
$ cat cat.err
cat: foo: No such file or directory
if we change the file to:
$ cat redir
#!/bin/sh
exec 2 >cat.err
# ^--- note the space between file descriptor number and redirection operator
exec 1>cat.out
exec cat foo
$ >cat.out; >cat.err
$ ./redir
./redir: 2: exec: 2: not found
$ cat cat.out
$ cat cat.err
$
When the shell parses a command, it cannot know if you meant to run the command "2" or redirect the file descriptor with that number. It sees a space and parses the parameters to exec as:
- program called "2",
- redirection: ">cat.err" (stdout to cat.err).
Since there is no program called "2", first exec gives an error and further script execution is terminated.
Similar thing happens in your other examples, "2" gets passed as an argument to different commands, instead of redirecting output to a file.
Now you see why there is nothing "elitist" nor arrogant in telling those who want to write services for various init systems that they first need to know the internals of GNU/Linux, shell command language and the specifics of init they are writing the service for, before engaging in such an activity. It is comparable to someone wanting to create a space shuttle without knowing elementary school physics. Writing services is not something an average user should need to do or should know to do. If you still want to do that, that is commendable, but you first need to learn to walk before you can run. Changing the immature attitude displayed in your other posts so far would also help immensely.
As far as ssh-chat goes, its wiki seems to indicate that a user service is desirable if one wants to run it as a service. That's why I linked the page describing how to create user services in runit in the other thread, but you seem to have simply ignored that post, instead concluding that "runit doesn't work".
runit works perfectly if you know how to use it.
Topic: runit still doesn't work (Read 1607 times)
previous topic - next topic