to quote or not to quote

[ghost]

A summary of what seems to be the same issue for #413 #462 #621 #1092 #1148 #1388 #1390 #1402 #1084 #1742 and maybe more. (list growing)

EDIT: The answer at this moment is to 'quote', it seems that xonsh is drifting away from implementing a backslash escape mechanism, since quotes do exactly the same thing and its much clearer imo. Also some of these issues can be solved with subprocess macros. The best solution at this moment is to include an entry to the tutorial (or a separate tutorial) that explains how xonsh differs from other shells in that matter.

I think this is a design decision that we will have to make sooner or later.

Bash has the motto 'in doubt use quotes', maybe we want to enforce this on xonsh and talk about it extensively in the tutorial. This will instantly solve almost all of the related issues.

Every other solution that comes in mind involves changes on how each command is being parsed, either at the Execer or at a lower level.

Ideas on this matter are appreciated!

[scopatz]

I think this is a design decision that we will have to make sooner or later.

I think the design decision has essentially been made. If someone magically handed us a backslah implementation, I am sure we would seriously discuss it. But even so, that doesn't prevent the

'in doubt use quotes',

motto at all. So I am all for having more and clear documentation about this. Maybe it deserves its own tutorial page because it is sort of a gotcha compared to other shell languages.

[mitnk]

a bit of OT here, git checkout -b foo-and-bar to me is not an in doubt, but it does require me to use quotes to get what I wanted. Use quotes here is unnatural for me.

[ghost]

I think the design decision has essentially been made.

@scopatz is the parsing implementation at the Execer level subject to changes or is it off limits?

[scopatz]

well, it is on the parser level, not the execer level. it is subject to changes.

[scopatz]

Maybe I should clarify now that I am not on my phone :) It is subject to change because we are pre-v1.0. I think it is unlikely to change given the choices the core devs have made to this point. But if someone has a compelling reason for it, that would be great. And if we had an implementation, that wouldn't hurt.

[ghost]

can we implement something like #378 by changing the implementation of the Execer or would this require changes on the parser level too ?

[scopatz]

that particular example should just use @(f) which is more explicit

[ghost]

hey @scopatz, going around reading the discussions on all of these issues i'm not clear on what we should write on the tutorial/docs. It seems like there is more work that could be done implementation wise.

[scopatz]

There probably is more work to be done, but I think a small document that basically covers the design decisions about not having escape characters in subprocess mode, how quotes work, etc would be good to start with.

[ghost]

hey @xonsh/core-developers do you think we can try and find a solution here? Maybe we wan't to quote some args at some point in the parsing stages? There are many related issue we can close and i believe this will keep coming up.

[scopatz]

Hi @laerus sorry for the delay here. I think we have basically decided to not escape in favor of quotes and subprocess macros. My personal justifications for this are:

1. escape charaters can get overwhemlingly ugly fast.
2. We have escape characters, they are called quotes :)
3. We have literal input in subprocess mode via macros.

If you think we just need docs to this effect, I am happy to write something up.

[ghost]

I went again over all the related issues and tried to come up with something to write in the docs but i'm not sure how to structure it. I really like quotes more than escape characters and never had an issue with this. You said in the previous post that there is more work to be done, did you mean about how the parsing is done, like do we want to autoquote some parts before parsing? My only concern is that is not obvious for someone that's coming from i.e bash on what needs escaping with quotes and what doesn't, and this will keep coming up from new users that fall into this. I'm all for changing the mindset of the users to get used to xonsh quote escaping, then we can close a lot of the related issues with just better docs on the matter!

[scopatz]

Hi @laerus - I think that I meant by "there is more work to be done" with respect to how the tab completer will auto-quote invalid tokens.

As per making thing more clear to the user, if #1759 is merged we can just say that if the token contains any of the forbidden characters/tokens (which are explicitly listed) it will need quotes. I think that is easier to explain than just the ones that are allowed.

[scopatz]

Thanks for pushing this forward.

[ghost]

the tail of the lost quote

#1148 makes no sense to force quoting around
why to treat and and or that are part of a word as separate token even in subproc mode

#621 xonsh wats

$ echo 'test'
test
$ echo 'test1' 'test2'
test1 test2
$ echo 'test'ok
'test'ok
$ echo te'st
te'st
$ echo test"          "
test"          "

more xonsh wats

$ echo xonsh #wats COMMENT IN SUPROC?
xonsh
$ echo hey @('world')
hey world
$ echo hey@('world')
SyntaxError: <xonsh-code>:1:5: ('code: hey',)
echo hey@('world')

IN DOUBT USE QUOTES
parts of this comment should be included in the tutorial in the upcoming Quoting section that gets added in #1856.

decisions decisions

wish i could help with implementation ideas but i
don't really grok xonsh lexing/parsing yet.

[scopatz]

closing based on #2560. Please feel free to continue the discussion.