Differences between ; and &&, $() and $(())

[jun0]

I was basically trying to do the same as lieryan here but with different constructs, and ran across some counter-intuitive behavior. I'm hoping someone here could clarify what's going on...

# $PROMPT is set to '{cwd} @ '.  .xonshrc is otherwise empty.
/tmp/test @ tree
.
└── subdir
    ├── file-a
    └── file-b

2 directories, 2 files

### First, a few things work as I expect.  ###

/tmp/test @ (cd subdir; ls) # Restores cwd after cd'ing and ls'ing.
file-a file-b
/tmp/test @ cd subdir; ls # Doesn't restore cwd.
file-a file-b
/tmp/test/subdir @ cd - # Restoring cwd manually.
/tmp/test @ cd subdir && ls # Doesn't restore cwd; so far, so good.
file-a file-b
/tmp/test/subdir @ cd - # Restoring cwd manually.

### Here's where the weirdness starts. ###

/tmp/test @ (cd subdir && ls) # cd complains and fails (inhibiting ls) but changes cwd anyway?
cd: no such file or directory: subdir
/tmp/test/subdir @ x=$(cd subdir; ls) # ; is taken as a literal string?
cd takes 0 or 1 arguments, not 2. An additional `-P` flag can be passed in first position to follow symlinks.
/tmp/test/subdir @ cd - # Restoring cwd manually.
/tmp/test @ $((cd subdir; ls)) # Extra parens makes ; interpreted.
'file-a file-b\n'
/tmp/test @

• Why does cd subdir && complain inside parens when cd subdir; doesn't? What's different between the handling of ; and &&? I expected both to commence the ls inside subdir and then restore cwd.
• What is cd subdir && complaining about, when in fact it's successfully changing the cwd?
• Why does $() not interpret ; as command-separators? Is the inside of $() not "full-fledged" subprocess mode somehow? What exactly is the difference, and why is there such a difference? Is it useful for something? I expected $(cd subdir; ls) to simply behave as if cd subdir; ls were typed at the top level (i.e. runs cd subdir then ls), except that it returns the output as a string.
• Why does adding extra parens turn on ;-interpretation? I expected the only difference between $(()) and $() to be whether a subshell is started.

[anki-code]

hi! I'm going to answer generally because I feel the pressure of posix shells users expectations. The xonsh shell is young and developed by the volunteers without strong release cycles. Current behavior of parser, threading and the logic of how it's working together were constructed for cover pretty minimal needs. So we can't say that the logic is weird we can say that the logic is on the beginner level.

To push the improvement forward:

• create the issue with the clear description of cases, examples, how it works now, how it should work
• become the core developer of xonsh by understanding how it works and do this changes

(I see that my messages has "Maintainer" label but the "maintainer" is the team during a couple of years. Don't treat my comment as a comment from owner.)

[jun0]

Hi there! Well, OK; since a more seasoned member of the community seems to think these behaviors are bugs (or at least something to be sorted out), can certainly repost them as issues instead.

I understand everyone here works on xonsh in their spare time, and I really appreciate their effort. I wouldn't be here if I didn't think it was cool! But as someone just starting to explore xonsh, I was wary of judging these as problems with xonsh, when it could very well be me misunderstanding the constructs.

[anki-code]

Don't worry and don't be shy just create clean proposal how it should work e.g. well structured issue or XEP