Re: We're doing it wrong. [WAS]: Zip utility on Windows for ODT exporter

Re: We're doing it wrong. [WAS]: Zip utility on Windows for ODT exporter

[Loyall, David]

> From: emacs-orgmode@gnu.org On Behalf Of Achim Gratz
> 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.

Yes.  But would you grant me that this is done in a more orderly fashion?

> > 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.

I realized shortly after my post that calling external executables is the norm, not the exception.

Also, I must apologize, my general tone in that message was terrible.  I'm experimenting with quitting smoking.  Suggestion: never start.
 
> > 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?

No.  Well, kinda.

> 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).

Yeah, I've thought about that a little bit.

I heard somebody say the other day that according to some survey, x percent of people don't know the difference between a search engine and a browser.  Would they know the difference between an application and a VM that auto-starts an application?  ...If you just change the title bar of Virtualbox to say "Emacs" instead...

I wrote ~2200 characters on this subject, just now, but then I stashed it away rather than present it here before asking: has this been proposed before? What was the outcome?

> Regards,
> Achim.
 
Cheers,
--Dave

Re: We're doing it wrong. [WAS]: Zip utility on Windows for ODT exporter

[Bastien]

"Loyall, David" <david.loyall@nebraska.gov> writes:

> I'm experimenting with quitting smoking.  Suggestion: never start.

(Been there...)  Trying to capture this:

* Stop smoking
  :PROPERTIES:
  :ORDERED: t
  :END:
** TODO Don't stop smoking
** TODO Don't start smoking
   SCHEDULED: <2013-04-11 jeu. +1d>

:)

-- 
 Bastien

Re: We're doing it wrong. [WAS]: Zip utility on Windows for ODT exporter

[Achim Gratz]

Loyall, David writes:
>> Then practically all programs are uncivilized, especially when
>> considering that dynamic libraries are just another form of external
>> executables.
>
> Yes.  But would you grant me that this is done in a more orderly
> fashion?

It may appear that way, but the closer you get to the details the
fuzzier it looks.

>> 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).
>
> Yeah, I've thought about that a little bit.
>
> I heard somebody say the other day that according to some survey, x
> percent of people don't know the difference between a search engine
> and a browser.  Would they know the difference between an application
> and a VM that auto-starts an application?  ...If you just change the
> title bar of Virtualbox to say "Emacs" instead...

Would anyone with an Android phone know that they actually run multiple
instances of some sort of VM?  Do they need to?  Emacs also is a VM when
looked at in the right perspective.  I'd think that people are getting
used to such layers of abstraction by now and shrug it off as long as it
does what they want.

> I wrote ~2200 characters on this subject, just now, but then I stashed
> it away rather than present it here before asking: has this been
> proposed before? What was the outcome?

Not sure what exactly you mean, but if you want to help out CERN with
doing some analysis on their data, they'll have you download a VM and
run their code from inside that without touching the rest of your
system.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

DIY Stuff:
http://Synth.Stromeko.net/DIY.html

We're doing it wrong. [WAS]: Zip utility on Windows for ODT exporter

[Loyall, David]

> Just tried [...X] and don't have the [... utility] that Org is looking for.

And that's why civilized programs don't depend on external executables from $PATH.

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.

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?

How about: don't depend on external executables from $PATH, but allow the user to override via config.

This is important on the 'reproducible research' front.

Cheers,
--Dave

Re: We're doing it wrong. [WAS]: Zip utility on Windows for ODT exporter

[John Hendy]

On Wed, Mar 27, 2013 at 9:06 AM, Loyall, David
<david.loyall@nebraska.gov> wrote:
>> Just tried [...X] and don't have the [... utility] that Org is looking for.
>
> And that's why civilized programs don't depend on external executables from $PATH.
>
> 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.
>
> But, let's take a fresh look.  How about this rule of thumb: don't depend on external executables **from $PATH**.

That, and I'm not sure that "zip" was working on Windows anyway. I had
to edit ox-taskjuggler and change it to "zip.exe." Could be wrong, as
I ran into an issue where Wiz.exe from Info-zip gave an error when I
renamed it zip.exe and said it "couldn't find itself." Thus, I named
it back to Wiz.exe and created a hardlink to it called zip.exe. I
tried renaming to just 'zip' to satisfy Org, but then Windows doesn't
recognize it as an executable...

Thus, I resorted to editing ox-taskjuggler on Windows to do it's path
check on "zip.exe."

>
> Can we agree on that?
>
> How about: don't depend on external executables from $PATH, but allow the user to override via config.
>
> This is important on the 'reproducible research' front.
>

Agree -- let the user specify the path to the thing to use. Kind of like this:

#+begin_doc

org-ditaa-jar-path is a variable defined in `org-exp-blocks.el'.
Its value is
"~/.elisp/org.git/contrib/scripts/ditaa.jar"

Documentation:
Path to the ditaa jar executable.

#+end_doc

> Cheers,
> --Dave

Thanks for chiming in.


John

Re: We're doing it wrong. [WAS]: Zip utility on Windows for ODT exporter

[Bastien]

Hi John and David,

If one of you can provide a patch for this, that'd be great.

Thanks,

-- 
 Bastien

Re: We're doing it wrong. [WAS]: Zip utility on Windows for ODT exporter

[John Hendy]

On Fri, Apr 5, 2013 at 7:10 PM, Bastien <bzg@altern.org> wrote:
> Hi John and David,
>
> If one of you can provide a patch for this, that'd be great.
>

I guess there's no time like the present for learning some lisp.

*If* I can figure out how to do this, it would be a simple variable to
set the name of the zip utility. I'd add documentation specific to
Windows linking to INFO-zip or some other utility, instructions, and
then to set the variable to "C:/path/to/zip.exe" instead of just
"zip."

*nix users could simply leave the default variable, "zip", or change
to a direct path as well if they wanted.


John

> Thanks,
>
> --
>  Bastien

Re: We're doing it wrong. [WAS]: Zip utility on Windows for ODT exporter

[Bastien]

Hi John,

John Hendy <jw.hendy@gmail.com> writes:

> I guess there's no time like the present for learning some lisp.

:)

> *If* I can figure out how to do this, it would be a simple variable to
> set the name of the zip utility. I'd add documentation specific to
> Windows linking to INFO-zip or some other utility, instructions, and
> then to set the variable to "C:/path/to/zip.exe" instead of just
> "zip."

There are three occurrences of "zip" in ox-odt.el.

But two of them come with switches (see lines 4101):

	  (cmds `(("zip" "-mX0" ,target-name "mimetype")
		  ("zip" "-rmTq" ,target-name "."))))

Two problems: (1) I don't know what these switches do, and
(2) I infer there are specific to zip.

So you would need to find out if there are necessary and what
equivalent switches are needed for other zip utilities.  If they
are not necessary, let's remove them.  If these switches are the
same for all zip utilities (we can dream, right?), let's only 
have an option `org-odt-zip-executable'.

If they are pecualiar to zip, then maybe the option should be an
alist of executables to search for, along with formatting strings
for those two occurrences -- something like:

(setq org-odt-zip-executable
      '(("zip" "zip -mX0 %s mimetype" "zip -rmTq %s .")))

> *nix users could simply leave the default variable, "zip", or change
> to a direct path as well if they wanted.

Yes.  The problem is with the switches.  That would be too simple
otherwise :)  Let us know if you can come up with something that
is good enough for you!

-- 
 Bastien

Re: We're doing it wrong. [WAS]: Zip utility on Windows for ODT exporter

[John Hendy]

On Sat, Apr 6, 2013 at 1:09 PM, Bastien <bzg@altern.org> wrote:
> Hi John,
>
> John Hendy <jw.hendy@gmail.com> writes:
>
>> I guess there's no time like the present for learning some lisp.
>
> :)
>
>> *If* I can figure out how to do this, it would be a simple variable to
>> set the name of the zip utility. I'd add documentation specific to
>> Windows linking to INFO-zip or some other utility, instructions, and
>> then to set the variable to "C:/path/to/zip.exe" instead of just
>> "zip."
>
> There are three occurrences of "zip" in ox-odt.el.
>
> But two of them come with switches (see lines 4101):
>
>           (cmds `(("zip" "-mX0" ,target-name "mimetype")
>                   ("zip" "-rmTq" ,target-name "."))))
>
> Two problems: (1) I don't know what these switches do, and
> (2) I infer there are specific to zip.
>
> So you would need to find out if there are necessary and what
> equivalent switches are needed for other zip utilities.  If they
> are not necessary, let's remove them.  If these switches are the
> same for all zip utilities (we can dream, right?), let's only
> have an option `org-odt-zip-executable'.

That's what I want, but it has to allow for a specific path to get
around having to specifically add the zip utility on Windows to the
actual $PATH environment. I'd rather leave the switches along, as then
one doesn't have to figure out a bunch of other zip utility stuff.

The current documentation requires that one have a *nix-equivalent
(wrt syntax) zip utility, hence other mailing list suggestions to use
INFO-zip.

If we want to go another route, say allowing for 7zip, it would
require more more cases to check for the actual zip utility being
used. INFO-zip was simple enough, so I think it would be fair to have
the user download it, move zip.exe somewhere, and then point to it
with the variable.

>
> If they are pecualiar to zip, then maybe the option should be an
> alist of executables to search for, along with formatting strings
> for those two occurrences -- something like:
>
> (setq org-odt-zip-executable
>       '(("zip" "zip -mX0 %s mimetype" "zip -rmTq %s .")))
>
>> *nix users could simply leave the default variable, "zip", or change
>> to a direct path as well if they wanted.
>
> Yes.  The problem is with the switches.  That would be too simple
> otherwise :)  Let us know if you can come up with something that
> is good enough for you!
>

I'll keep thinking through it. For now, I got Windows working by
simply editing ox-odt directly and replacing zip with zip.exe :)


John

> --
>  Bastien

Re: We're doing it wrong. [WAS]: Zip utility on Windows for ODT exporter

[Bastien]

John Hendy <jw.hendy@gmail.com> writes:

> I'll keep thinking through it. For now, I got Windows working by
> simply editing ox-odt directly and replacing zip with zip.exe :)

Is this that easy?  And is it needed for all Windows users who 
do not install Cygwin?  If so, the simple variable could do.

-- 
 Bastien

Re: We're doing it wrong. [WAS]: Zip utility on Windows for ODT exporter

[Achim Gratz]

John Hendy writes:
> I'll keep thinking through it. For now, I got Windows working by
> simply editing ox-odt directly and replacing zip with zip.exe :)

The only reason I can think of why this should help is that you
somewhere have a file named "zip" (without any extension) in your path
and before it gets to the directory where zip.exe resides.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: We're doing it wrong. [WAS]: Zip utility on Windows for ODT exporter

[Achim Gratz]

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