Comment by oguz-ismail
5 months ago
>oils
Nah. Bash is well-maintained, you can have a bug fixed quickly. It's been months since I reported this <https://github.com/oils-for-unix/oils/issues/2068> and still nothing.
5 months ago
>oils
Nah. Bash is well-maintained, you can have a bug fixed quickly. It's been months since I reported this <https://github.com/oils-for-unix/oils/issues/2068> and still nothing.
Not a oils maintainer, but: I took a look at your report, and it seems like it could use a bit more detail. Things like clearer steps to reproduce, expected vs. actual behavior, and a more descriptive title might help get it addressed faster. Open-source projects often have limited resources, so anything that makes it easier for maintainers to pinpoint the issue can speed things up. Maybe updating the report with more context could help move it along?
Looking at the original posting, the maintainer knows what the bug is. The stopper is more along the lines of "This looks synthetic, so it's not high priority. If it's a priority for you, then you should fix it yourself or make an argument for its priority." followed by oguz saying "It's not actually my problem either, I'm not invested in osh.". (not actual quotes: https://github.com/oils-for-unix/oils/issues/1881#issuecomme...)
The bug is that osh leaves the script fd open for the child process when executing a command, allowing the child command to mess with the parent script. I don't see this as a huge issue for everyday interactive use, but I'd prefer my shell to not do that. If I were executing programs with limited capabilities, I'd consider this a possible vector for security bugs. That is to say, I wouldn't use osh scrpts if I cared about security.