Re: 'emacs -batch -eval ... -f ...' outputs everyday crunching to stderr?

[Emanuel Berg <embe8573@student.uu.se>]

Emanuel Berg <embe8573@student.uu.se> writes:

> The strange thing is that the 2>&1 is required. It
> seems, 'emacs -batch -eval ... -f ...' outputs the
> "Loading..." and "Wrote..." stuff to stderr - any
> ideas why?

In the Emacs man page, emacs(1), it says:

    --batch ...  The editor will send messages to
      stderr. ...

It doesn't say why, but I just had another problem that
made me think about this.

There is a shell tool called 'par'. You can use it to
justify a file (at the 54th char) like this:

par 54j < input.txt > output.txt

However, fed with the language of honor and heroes
(Swedish), par doesn't work (probably because of out
three special chars). (I wrote the Debian maintainer
about this, but he didn't replied. In the par manpage,
par(1), they provide another email that doesn't work.
Anyway the Debian guy didn't reply.)

So I thought I'd do it in Emacs instead. In zsh:

justify () {
    file=\"$1\"
    emacs --batch --eval "
      (progn
        (find-file $file)
        (setq fill-column 54)
        (fill-region (point-min) (point-max) 'full)
        (princ (buffer-string))
        (kill-buffer) )" 2> /dev/null \
    | pr -o 4 -t
}

(The last line - pr - is to get a left margin of 4
whitespaces.)

When I wrote it, I noticed it was practical for batch
Emacs to output to stderr - that way, I could redirect
it to /dev/null and have Emacs print exactly what I
wanted (the `princ' part).

So I suppose this is the reason - or one of the reasons
- for batch Emacs to behave like this. I don't know if
it makes sense, but it is very manageable, which is what
matters the most. If it were to make sense, perhaps
batch Emacs would just shut up - unless there is a real
error - which then, naturally, would go to stderr?

-- 
underground experts united