compilers using pipes.quote() == not Windows compatible. breaks LESSc #444
Comments
|
I am getting this same issue and was just about to try and figure out a resolution myself. If you have one I recommend setting a pull request and I can help test as well. Otherwise, I can assist in resolving this issue if needed. My biggest worry, I'm not sure the best way to keep this backwards compatible. |
Convert command to use a list of arguments and sending outfile to stdout for compilers using it.
Convert command to use a list of arguments and sending outfile to stdout for compilers using it.
|
Yeah, I played around with solutions a while back. Wound up rewriting Backing that change out, I still did have a solution that removed the On Wed, Apr 15, 2015 at 12:53 AM, dwatkinsweb [email protected]
|
Names on disk and config files should not have to be safe for shells to interpret. As close to possible, we should take literals and give literals to the OS kernel to operate on directly. For filename globs, it is our responsiblility to expand them, and if we had no problem with backwards compatibility, we would insist config files' SCRIPT_ARGUMENTS parameters are tuples of discrete values. Delegating those to a shell breaks clear boundaries of interpreetation and will always be prone to errors, oversight, and incompatibility. So, now, we never take names that are unsafe and try to make then safe for a shell, because we don't need a shell. This fixes #444, which had problems with Windows paths being insensible to the crazy quoting we hoped would make a filename safe for a shell. This fixes #494, which had a compiler-attempt stdout captured as part of a string interpreted by a shell. When the compiler didn't exist, that shell expression STILL created empty files, and the pipeline thenafter served an empty file as if it were real compiler output.
Names on disk and config files should not have to be safe for shells to interpret. As close to possible, we should take literals and give literals to the OS kernel to operate on directly. For filename globs, it is our responsiblility to expand them, and if we had no problem with backwards compatibility, we would insist config files' SCRIPT_ARGUMENTS parameters are tuples of discrete values. Delegating those to a shell breaks clear boundaries of interpreetation and will always be prone to errors, oversight, and incompatibility. So, now, we never take names that are unsafe and try to make then safe for a shell, because we don't need a shell. This fixes #444, which had problems with Windows paths being insensible to the crazy quoting we hoped would make a filename safe for a shell. This fixes #494, which had a compiler-attempt stdout captured as part of a string interpreted by a shell. When the compiler didn't exist, that shell expression STILL created empty files, and the pipeline thenafter served an empty file as if it were real compiler output.
In bug #335, a call to quote() was added to better handle variety of filenames. It turns out that quote() is not windows compatible and is not intended to be (neither the shlex version nor the pipes version).
quote() adds single quote characters, windows requires double quotes as single quotes have no special meaning (to windows it's just an apostrophe, and apostrophes are ok in windows filenames).
For me, pipeline is adding single quotes everywhere it calls lessc. This is breaking lessc, which does not handle the single quotes properly. It tries to add the current working directory to the quoted filename and comes up with a brand new filename that is not valid.
To me, things would be much simpler if you called lessc using Popen in 'not shell' mode. Pass in the name of the executable, pass in the arguments as an array. Dont try to quote anything. dont turn the whole thing into one long command string. Is there a reason it was not implemented this way?
I have already been working with lessc. They merged a patch for me which "fixes" the single quote issue. But now we are removing it because it breaks to deviate from the windows specs in this way.
I can submit a PR, just wanted to get feedback first if possible.
wonder if this is related to issue #368 ...
The text was updated successfully, but these errors were encountered: