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

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

[Emanuel Berg]

I have a Makefile [1] to manage all my Elisp.

Today I set out to make it not echo all the
"Loading..." and "Wrote..." stuff, and the command
itself (lots of noise, as repeated for each source
file), so that, when compiling, I would be able to
detect warnings and errors and not just drown in all
the other output.

'make -s' was the way to not echo the command, for the
other stuff I used sed:

# only errors and warnings should be outputed
sed-filter=2>&1 | sed '/^\(Loading\|Wrote\)/d'

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?

Other comments also welcome.

I include several comments to make the Makefile
manageable.

[1] http://user.it.uu.se/~embe8573/conf/emacs-init/Makefile

-- 
underground experts united

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

[Emanuel Berg]

Aurélien Aptel <aurelien.aptel@gmail.com> writes:

> You can use `append' instead of `cl-concatenate'.
> It's a builtin.

You mean like this?

(setq l1 '(1 2 3))
(setq l2 '(four five six))

(setq l1 (append l1 l2))

Yeah, that's better. Then I don't need to bring in CL
for the Makefile so when I compile individual files
those will complain if they use CL and I don't bring it
in for that particular file. Thank you!

And idea as to the output to stderr?

-- 
underground experts united

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

[Emanuel Berg]

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