Allow easy installation #10
Comments
|
An Arch package would be great, but it's a little early for that. As mentioned in issue #7 , cd isn't even working yet! Right now OSH is passing on 248 tests and failing on 166: http://www.oilshell.org/git-branch/master/11eaa05c/andy-home/spec/RESULTS.html Once we get that closer to 95% or so, I think it will make sense to release an Oil 0.1, and then an Arch package will make sense. I hope that will be in a couple months. I will ping this bug then :) Thanks for trying this. |
|
It's now packaged as a C program rather than a Python program: http://www.oilshell.org/blog/2017/07/23.html Please try it and let me know what goes wrong! :) |
andychu
pushed a commit
that referenced
this issue
Sep 4, 2018
Now we check file descriptors (even those above #10) before using them. This is a recurrence of the bug described here: http://www.oilshell.org/blog/2017/07/02.html If you do 'import random' in Python, it results in /dev/urandom being permanently open (which can be seen in the blog post!) At the time, I incorrectly fixed the bug by just opening our own descriptors above #10. But it's possible that CPython will subsequently open something above #10 (/dev/urandom appeared as #12), so we have to additionally check descriptors before we use them. NOTE: 'import cgi' eventually causes 'import random'. We're only using it for cgi.escape(), but cgi.FieldStorage() uses tempfile, which uses a random number generator. Also: minimize the test case as gold/configure-bug.sh. 'test/gold.sh configure' was the case that caught this bug. The spec tests didn't find it! Because it appears to take about 4 redirects for this to happen!
andychu
pushed a commit
that referenced
this issue
Jan 26, 2019
The symtom was that running 'test/unit.sh all' under OSH failed. In core/completion_test.py, we run the line: echo "$@" >&2 under test_lib.EvalCode(), and the two OSH interpreters conflicted somehow, resulting in stdout being permanently closed. Then any remaining print() calls failed with EBADF. I got rid of the self.next_fd counter since it's not correct. Instead we do a linear search from fd #10. Now the tests pass. However now I realize I should be using fnctl(..., F_DUPFD, ...) and looking at the return value. It does the linear search for you in the kernel! Looking at dash source code clued me into this. Addresses issue #202.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I attempted to try and create an Arch Linux PKGBUILD for this project and realized that setup.py install only installs python libc, and not oil. Could this be fixed?
The text was updated successfully, but these errors were encountered: