Closed tajmone closed 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.
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!
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:
bat
(maybe renamed as cmd
) on Windows or Linux+Wine to execute .bat
scriptssh
or bash
to execute shell/bash scripts on Windows+Cygwin (or similar) or LinuxTODO:
bat
and rename it as cmd
(I'll keep bat
so as no to break existing documents)pp
to explicitly preprocess the output of any other macro (e.g. cmd
, sh
, ...) to mimic the behaviour of exec
)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:
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
...
I guess this issue can be closed. New macros are tested and no bugs have been (yet) reported.
On Windows, trying to use
!exec()
or!rawexec()
raises the following error (and exits PP):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 tosh
(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.