jh7370:
The thread has gone a bit stale. From what I’ve read, everybody agrees that the goal of “switching to internal shell by default everywhere” is a worthwhile one, but there doesn’t seem to be much appetite for adding new functionality, except where it is absolutely essential. I think it would be worthwhile raising each new piece of functionality that you want to implement as a separate RFC, so it can be judged on its individual merits. In each of these RFCs, I’d expect to see a count of the number of tests that need it and what would be involved in porting those tests to use existing lit etc functionality. If the impacted test count is small, it would be best to explicitly list the tests. If you’ve got a PR exhibiting the functionality to back the RFC up, that’s fine, but be prepared to close the PR, if the consensus is that the tests should be modified instead.
rnk:
I advocate that we should keep the lit shell dialect extremely minimal.
The lit shell dialect is shell-like, but we should not add support for subshells (i.e. $() and backticks), or other features, that encourage extensive processing and computation in the shell. We don’t want to encourage test writers to push substantial amounts of data through the test shell as Python strings. We really just want to hook up the pipelines and create a testing environment where C++ processes talk to each other through native OS files and pipes. We also want to say “no” to the never-ending project of reimplementing all of bash in Python, we have to limit scope somewhere, and it should be really close to where we are today, even if we have to make a few more accommodations for the sake of practicality.
My position is that using advanced bash features in most tests is just not good taste.
After evaluating the features we were planning on implementing (brackets, command substitution $(), ulimit, unset, for loops), we agree that the tests that rely on these features can just be rewritten without needing to add new functionality. We will be closing the PRs opened previously to implement these features, and will focus on rewriting the tests instead. Thank you @jh7370 and @rnk for the feedback on this matter.