From: Achim Gratz <Stromeko@nexgo.de>
To: emacs-orgmode@gnu.org
Subject: Re: We're doing it wrong. [WAS]: Zip utility on Windows for ODT exporter
Date: Sun, 07 Apr 2013 09:50:29 +0200 [thread overview]
Message-ID: <87r4im3hkq.fsf@Rainer.invalid> (raw)
In-Reply-To: FCEE4469EE8B234199968ECA9B0661E208CD671A@STNEEX10MB02.stone.ne.gov
Loyall, David writes:
> And that's why civilized programs don't depend on external executables
> from $PATH.
Then practically all programs are uncivilized, especially when
considering that dynamic libraries are just another form of external
executables.
> Now, I'd imagine that some people have argued in the past that org
> shouldn't depend on external executables. Clearly those arguments
> have failed.
I'm sure that if you could point to an Emacs package that allows to work
with archives without depending on external executables it would be used
instead, but I'm not aware of any such package: ox-odt uses arc-mode for
unzipping (which in turn uses call-proc for actually doing it) and then
call-proc itself to do the zipping.
> But, let's take a fresh look. How about this rule of thumb: don't
> depend on external executables **from $PATH**.
>
> Can we agree on that?
No, because I can't really see the point, especially since Emacs doesn't
use just $PATH for call-proc, but a user option exec-path (whose default
value is a copy of $PATH, but even a cursory look on $PATH on a Windows
system should convince you that you really should change this).
> How about: don't depend on external executables from $PATH, but allow
> the user to override via config.
How about: if you want that level of control, customize exec-path (and
perhaps exec-suffixes)?
> This is important on the 'reproducible research' front.
Are we still talking about Windows? You'd need an audited system if you
want to take it that far, I'm not sure anybody has tried to do this on
Windows and is still outside the asylum. The only practical way seems
to deliver the reproducible research as a VM (yes, that has other
problems).
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
next prev parent reply other threads:[~2013-04-07 7:50 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-27 14:06 We're doing it wrong. [WAS]: Zip utility on Windows for ODT exporter Loyall, David
2013-03-27 22:04 ` John Hendy
2013-04-06 0:10 ` Bastien
2013-04-06 17:56 ` John Hendy
2013-04-06 18:09 ` Bastien
2013-04-06 18:15 ` John Hendy
2013-04-06 18:19 ` Bastien
2013-04-06 20:54 ` Achim Gratz
2013-04-07 7:50 ` Achim Gratz [this message]
-- strict thread matches above, loose matches on Subject: below --
2013-04-11 14:58 Loyall, David
2013-04-11 15:11 ` Bastien
2013-04-11 18:13 ` Achim Gratz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r4im3hkq.fsf@Rainer.invalid \
--to=stromeko@nexgo.de \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).