New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

to quote or not to quote #1432

Closed
laerus opened this Issue Jul 15, 2016 · 16 comments

Comments

Projects
None yet
3 participants
@laerus
Copy link
Member

laerus commented Jul 15, 2016

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!

@laerus laerus added this to the v0.5 milestone Jul 15, 2016

@scopatz

This comment has been minimized.

Copy link
Member

scopatz commented Jul 15, 2016

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.

@scopatz scopatz added the docs label Jul 15, 2016

@mitnk

This comment has been minimized.

Copy link
Member

mitnk commented Jul 16, 2016

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.

@laerus

This comment has been minimized.

Copy link
Member

laerus commented Jul 16, 2016

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

This comment has been minimized.

Copy link
Member

scopatz commented Jul 16, 2016

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

@scopatz

This comment has been minimized.

Copy link
Member

scopatz commented Jul 17, 2016

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.

@laerus

This comment has been minimized.

Copy link
Member

laerus commented Jul 17, 2016

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

@scopatz

This comment has been minimized.

Copy link
Member

scopatz commented Jul 17, 2016

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

@laerus

This comment has been minimized.

Copy link
Member

laerus commented Aug 21, 2016

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

This comment has been minimized.

Copy link
Member

scopatz commented Aug 21, 2016

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.

@laerus

This comment has been minimized.

Copy link
Member

laerus commented Sep 14, 2016

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

This comment has been minimized.

Copy link
Member

scopatz commented Sep 24, 2016

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.

@laerus

This comment has been minimized.

Copy link
Member

laerus commented Sep 24, 2016

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

This comment has been minimized.

Copy link
Member

scopatz commented Sep 24, 2016

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

This comment has been minimized.

Copy link
Member

scopatz commented Sep 24, 2016

Thanks for pushing this forward.

@laerus

This comment has been minimized.

Copy link
Member

laerus commented Oct 15, 2016

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.

quote-all-the-args

@scopatz

This comment has been minimized.

Copy link
Member

scopatz commented Dec 9, 2017

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

@scopatz scopatz closed this Dec 9, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment