fix(bash): fix small issues of enter_accept for the plain Bash
#1467
Conversation
With the current implementation, the user command "--" would not be executed even if it were the intended one. This is because it would be confused as an option by the "eval" builtin. We can specify "--" to tell "eval" that the later arguments should be literally treated as the command.
The exit status of preexec_ret_value is used to suppress the execution of the corresponding command in the extdebug mode. The current implementation somehow tries to set $? before the call of stty, which does not have any effect. Instead, we can manually turn off the execution of the user command when the condition matches.
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
Not directly related to the fixes in this PR, but we might separate the related code into a new function |
There was a problem hiding this comment.
Thank you for all the fixes! And I appreciate how nicely broken down the commits here are 🙏
but we might separate the related code into a new function __atuin_accept_line for the refactoring because most lines of __atuin_history are somehow the accept-line emulation despite the function name. What do you think?
I think that would make sense. I don't feel strongly enough that it should block this PR, but it would be nice
Thank you for your reply! Then, should I submit a PR for As I mentioned in the first comment, I'll submit a PR for additional refactoring, but I suggest separating the |
|
Yes please! Sounds good to me 😊 |
|
Thanks! |
|
I created PR #1476 for |
This PR resolves small issues of
enter_acceptfor Bash without ble.sh. There are five different fixes, and again the details are in the commit messages. The original author @arcuru might have comments.I plan to submit another PR for refactoring and a small performance improvement (which contains again 5 commits). If I should separate the PR into smaller chunks, please let me know. In such a case, I can re-submit those commits in separate PRs.