CDSoft / pp

PP - Generic preprocessor (with pandoc in mind) - macros, literate programming, diagrams, scripts...
http://cdelord.fr/pp
GNU General Public License v3.0
253 stars 21 forks source link

Implementing `!exec()` and `!rawexec()` for Windows #7

Closed tajmone closed 7 years ago

tajmone commented 7 years ago

On Windows, trying to use !exec() or !rawexec() raises the following error (and exits PP):

pp: Error while executing `sh C:\Users\PK6A24~1.DIC\AppData\Local\Temp\pp.4118467.sh`: sh: createProcess: does not exist (No such file or directory)
CallStack (from HasCallStack):
  error, called at src\Preprocessor.hs:543:19 in main:Preprocessor

I can't miss noticing that the error reports a filepath using short names (PK6A24~1.DIC is the short name of that folder), and the reference to sh (Linux shell files?)

I didn't understand from PP docs if this command is intended for Linux only or for any shell (including Windows CMD), but it would be nice to see it implement on Windows --- also for scripts portability.

NOTE: I have Win 10 x64, and I'm running PP in a CMD shell with normal priviledges.

CDSoft commented 7 years ago

Well, exec and rawexec have been implemented because I had old documents using such macros and an old preprocessor I have never released. They explicitly use sh to execute a script and should work on Windows with Cygwin or MSYS. Determining dynamically the interpretor (e.g. cmd on Windows, sh on Linux or Cygwin) may not be a good idea because a document would have different behaviours on different OS. Instead of rawexec, you can use bat on Windows. exec has no equivalent.

I think I will add a macro pp to explicitly preprocess the output of a script macro. Then !exec(...) would be equivalent to !pp(!bat(...)) on Windows. Of course the macro pp will be able to preprocess the output of any script, not only bat. Then exec and rawexec may become obsolete.

I also don't really like the name of the macro bat. cmd would be more appropriate and consistent with other language names.

tajmone commented 7 years ago

You'r right: I've tested it inside Git for Windows Bash and it worked with both CMD- and Bash-commands.

My mistake: I though that !exec() was meant to be cross-platform, not Linux/Bash specific.

Yes, probably the best way to go about right now is to just create a custom macro for shell commands that can behave differently accordingly to the OS, so the same file can work across platforms.

Thanks!

CDSoft commented 7 years ago

In fact it was not documented. The doc just said "the current shell", which should be cmd on Windows or sh on Windows+Cygwin or sh on Linux, ... It will be less ambiguous to use:

TODO:

tajmone commented 7 years ago

I also don't really like the name of the macro bat. cmd would be more appropriate and consistent with other language names.

I actually think that bat and cmd should be both aliases of each other, with equal status. This issue triggered me thinking about this distinction, because it often pops up (for example, with syntax highlighters language names, etc.). I've found this interesting posts:

The point is that cmd might refer to both *.cmd files as well as CMD (shell program), so on the one the term indicates the shell environment (ie, like: Bash), but on the other it also indicates a type of script by its extension (ie: like sh).

Basically, although the behaviour of both *.bat and *.cmd scripts is almost identical, the former is meant for older Windows versions and run in compatiblity mode under CMD shell, while the latter gets the "full monty" of the modern CMD (and won't run as a script in ture DOS).

Both files qualify as batch files (and produce almost identical results), and which extension people use just boils down to habits, usually:

CDSoft commented 7 years ago

I have added the cmd macro (identical to bat) as well as a new pp macro that forces the preprocessing of any text (e.g. the output of script macros). So \rawexec(...) is equivalent to \sh and \exec is equivalent to \pp(\sh(...)). Of course, this works for sh, cmd, python...

CDSoft commented 7 years ago

I guess this issue can be closed. New macros are tested and no bugs have been (yet) reported.