> 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
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
Hi John and David, If one of you can provide a patch for this, that'd be great. Thanks, -- Bastien
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
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
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
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
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
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
> 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
"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
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