Equivalent to bash's "&&"

[averageapps]

Great project! It would be very nice to have a keyword in xonsh that is equivalent to && in bash/zsh or ;and in fish, meaning that it would execute if and only if is successful in the following example line:
<A> <keyword> <B>.
For maximum "bashwards compatibility" the keyword should be exactly like in bash (&&) if possible.

For completeness' sake there should also be a keyword equivalent to || (bash/zsh) or ;or (fish) that only executes something if the preceding command fails.

The current xonsh behavior (v0.1.2) for this syntax seems to be 100% cpu usage and doing nothing until I hit Ctrl+C

[adqm]

I agree wholeheartedly. I would be happy to take this one on.

[mbollmann]

I was already thinking whether the standard subprocess mode $[...] shouldn't return the command's exit code by default, however, a naive implementation would cause the exit code to be printed on screen then each time. Also, the "success" code is 0, which means it can't easily be used in standard Python comparisons, which is awkward.

Alternatively, $[...] could return a StatusCode object, which would evaluate to True if the code was 0, False otherwise, and prints as an empty string, though that seems a bit hacky.

However, I also believe that implementing such a behaviour would require quite a few internal changes, because the return code of subprocess commands isn't even currently stored as far as I remember.

Just some food for thought @wrywerytwreywery, because I investigated this for a little while already :)

[scopatz]

Hi All, before anyone gets too far down the road on this, I'd like to make a few points:

1. Right now you can do something that is semantically equivalent to bash && by separating with semicolons ;. No, it doesn't check the return status, but it does fail approriately.
2. I would like to see Python's logical operators used (and, or, not) rather than Bash's and C's logical operators (&&, ||, !). There is no reason to add complexity to the language for this feature.
3. As @mbollmann alluded to, we probably need a rich history class for this to be done well or correctly. There are other issues open right now with respect to that.

I'd also like to note that precedence rules come in to play here. Thus the need for grouping with () arises. On the bright side, the parser side of things is implemented in Python mode. So implementing it in subproc mode would be more about copying than the work.

[averageapps]

@scopatz You are right, using standard python operators for this would be more elegant.
Thanks for the hint that the semicolon behaves this way.