CDSoft / pp

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

Add Escape String Macro #38

Closed tajmone closed 6 years ago

tajmone commented 6 years ago

I've encountered an issue when using the !bash macro under Windows (Git Bash):

Git Bash for windows accepts both Windows- and Unix-like paths (ie: dir separators / and \). This allows to invoke Windows commands and console apps from with Bash and Bash scripts.

But in the context of a !bash macro, when I emit a path from an env var (!env(SOME_PATH_VAR)) under Windows' Git Bash, the path needs escaping backslashes!

It would be useful to have a built-in macro that handles escaping path strings — eg:

... ecaping whatever needs to be escaped in a Windows path being passed to !sh or !bash!

and maybe it's counterpart, to unescape strings.

I think this is worth implementing because (as you advised me) using Bash instead of Windows' CMD allows not only creating cross-platform macros, but also finer and better support tools. In many cases, a PP macro will need to access a path already set in an env-var by either the system or some other app.

One can resort to weak quoting, or use some shell command to achieve this, but a built-in macro would be easier, less verbose, and maybe add less overhead. My guess is that there could many contexts in which such a macro comes handy (including Win's CMD context).

What's your view on this?

CDSoft commented 6 years ago

<troll>Well, I also advice using "real OS" ;-)</troll>

The escape macro should be a generic macro. Escaping pathnames for Windows is not the same than HTML text or any other programming language... I don't understand why D:\\some\\path\\ is different than D:\some\path\ (unless you let bash interpret it). Bash can escape what ever you want. If you want to preserve backslashes, just ask bash not to interpret them. I guess that '!env(SOME_PATH_VAR)' (with simple quotes) would work.

Another solution to this very specific problem is to let bash read the environment variable itself: $SOME_PATH_VAR (which is shorter than !esc(!env(SOME_PATH_VAR))).

My view is not to reimplement in pp what bash, python, haskell... can simply do.

tajmone commented 6 years ago

If you want to preserve backslashes, just ask bash not to interpret them. I guess that '!env(SOME_PATH_VAR)' (with simple quotes) would work.

... true, and this is the solution I've been adopting. As I mentioned above, using weak quoting solves it, but the whole issue prompted me the idea that there could be some contexts in which an escape/unescape macro would be convenient (this being something that can't be achived with custom macros). So I thought it might worth proposing it.

Another solution to this very specific problem is to let bash read the environment variable itself: $SOME_PATH_VAR (which is shorter than !esc(!env(SOME_PATH_VAR)))

... ooops! My mistake here — I was still thinking like when building macros that should run both on CMD and Bash! My brains must be wearing out :confused:

The escape macro should be a generic macro. Escaping pathnames for Windows is not the same than HTML text or any other programming language..

... this is a point I wasn't shure about. Since I've started using PP under Git Bash for Windows, I've also encountered some new unexpected situations that derive from the "hybrid" workings of Bash for WIndows (pathnames dual standard being one of them). So I thought worth reporting them here.

Well, I also advice using "real OS" ;-)

... very true, but again: some issues I'm facing relate to the cross-platform CMS I'm working on.

Also, now Win 10 ships with native (but optional) support for Bash via the "Windows Subsystem for Linux":