Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
quote removal in subprocess mode does not behave as expected #621
Please have a look at the following two examples::
In the first case quotes are stripped from the second argument; in the
This is not consistent with what other shells do, and makes it quite
Hi @riccardomurri, you are correct that we are not consistent with how other shells treat string. Xonsh makes a willful departure from what other shells do, in part because what other shells do is not self-consistent. Rather, xonsh's literal string syntax sticks as close as possible to Python string behaviour, which we believe to be cleaner and more consistent.
The only departure from Python strings in subproc mode is that literal strings are globbed and have their environment variables expanded, as one would expect from other shells.
The examples that you give of echo and svn are not entirely consistent themselves. It is generally the responsibility of each program to parse its own arguments. So if svn is including quotes this is svn fault. As an demonstration, consider the following Bash script which simply prints its arguments:
#!/bin/bash echo $*
Now let's run this with multiple arguments.
scopatz@localhost ~ $ chmod 755 temp.sh # see bash keeps the quotes scopatz@localhost ~ $ ./temp.sh --message='hello mom' --message='hello mom' # bash keeps the quotes even when running though bash directly scopatz@localhost ~ $ bash temp.sh --message='hello mom' --message='hello mom' # same thing with double quotes scopatz@localhost ~ $ bash temp.sh --message="hello mom" --message="hello mom" # Let's add a 'foo'bar argument, and see that the quotes remain. scopatz@localhost ~ $ bash temp.sh 'foo'bar --message="hello mom" 'foo'bar --message="hello mom"
So bash is doing something strange here with echo and a literal string + characters that I don't think is worth replicating.
As per getting the SVN example to work in a natural way, recall that arguments are whitespace separated. Thus, I would leave off the
$ svn commit --message 'A short description here.'
Alternatively, if you truly must have the equals sign and want xonsh to group the internal whitespace, I believe that you can put the whole token in quotes.
$ svn commit '--message=A short description here.'
This is probably less satisfying, but works because your original command is actually equivalent to:
$ svn commit "--message='A short description here.'"
In general for xonsh, if a subprocess argument does not start and end with quote characters or other known syntax like
I hope this helps clear things up.
Hello @scopatz, thank for looking into this!
Actually, I cannot replicate the "temp.sh" example you showed. (Did
I understand Xonsh does not need to retain compatibility; actually, I
Instead sh/bash needs quote removal to control whether variables are
Still, if you keep quote removal, I think it should behave like
I stand corrected: of course we need quote removal in order to have
So, to sum up, there are two styles of quote removal:
Being used to UNIX shells, I would like to see the latter style
Hi @riccardomurri, I think I got the bash behaviour wrong myself. temp.sh does act as you describe if I am in a Bash interactive instance.
On the subject of what to do about it, I would really call the first one "Python-style." My personal opinion is that the way the sh-lang spec is written is rather arcane and not up to modern notions of how strings should work. (Though I am not saying that what we have now is perfect.)
Now, I may be wrong about this, but I believe that adding in optional Unix-sh-style strings would touch the parser. I am a little wary of having option-dependent syntax. This means that xonsh code could not be universally parsed.
On the flipside, adding in the behvaiour for strings you are suggesting would have overlapping syntax some Python literals, namely
Now, that said, I am open to suggestions - though for something like this I would also like for it to be vetted by @adqm, @gforsyth, and the mailing list. A suggestion backed by a PR would be even more compelling. Here are a couple of thoughts that I had that might be more or less compelling:
In any event, I guess I'd like folks to weigh in with their thoughts.
I agree that Python doesn't use double-up quotes -- are you envisioning something along the lines of
That doesn't seem too terribly hard, but I'm also at a loss for an actual use-case. @riccardomurri -- did you have a specific idea in mind that led you to this example? If it's the
Hi @gforsyth, sorry to be clear, I am envisioning double quotes as the following:
$ echo foo""bar"" foobar
Which would mirror Bash's quoting behaviour. However, I don't think that this makes anyone happy because it isn't as concise as the sh-lang syntax for the people that want it and it makes something possible that should not be possible for the people who don't want it (and are generally anti-arcana).