# php interactive shell: save history on SIGINT exit - Thread: https://externals.io/message/75747 - Original archive: https://news-web.php.net/php.internals/75747 - Started by Dmitry Saprykin on 2014-07-21T09:12:26+00:00 - Messages: 13 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #75747 — Dmitry Saprykin — 2014-07-21T09:12:26+00:00 URL: https://externals.io/message/75747#75747 Php interactive shell saves commands history when you exit it using 'quit'. But it throws all you history away when you exit using Ctrl+C. It is common practice to save history on `SIGINT` exit (mysql, mongo, etc.) I would like to implement `SIGINT` handler for interactive shell to save history on Ctrl+C exit. Threre is request on bugs.php.net for this feature https://bugs.php.net/bug.php?id=67496. I have created pull request https://github.com/php/php-src/pull/727 but was advised to create RFC to discuss this change. So could you provide some feedback. Kind regards, Dmitry Saprykin --- ## #75752 — Yasuo Ohgaki — 2014-07-21T09:23:58+00:00 URL: https://externals.io/message/75747#75752 · In reply to: #75747 Hi all, On Mon, Jul 21, 2014 at 6:12 PM, Dmitry Saprykin wrote: > Php interactive shell saves commands history when you exit it using 'quit'. > But it throws all you history away when you exit using Ctrl+C. It is common > practice to save history on `SIGINT` exit (mysql, mongo, etc.) > > I would like to implement `SIGINT` handler for interactive shell to save > history on Ctrl+C exit. > > Threre is request on bugs.php.net for this feature > https://bugs.php.net/bug.php?id=67496. > I have created pull request https://github.com/php/php-src/pull/727 but > was advised to create RFC to discuss this change. > > So could you provide some feedback. > Isn't it nicer to treat this kind of change as simple bug fix/feature implementation? It's common behavior and there is no compatibility issue at all. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #75757 — Michael Wallner — 2014-07-21T09:46:04+00:00 URL: https://externals.io/message/75747#75757 · In reply to: #75752 > > Hi all, > > On Mon, Jul 21, 2014 at 6:12 PM, Dmitry Saprykin < saprykin.dmitry@gmail.com> > wrote: > > > […] 'quit'. > > […] common > > […] > > Isn't it nicer to treat this kind of change as simple bug fix/feature > implementation? > It's common behavior and there is no compatibility issue at all. > Yes, please do NOT create a RFC for each and every tiny feature. Just find someone to review and eventually merge your patch! --- ## #75758 — Dmitry Saprykin — 2014-07-21T09:50:10+00:00 URL: https://externals.io/message/75747#75758 · In reply to: #75757 Ok, I will NOT )) God saves us from bureaucracy > > > > […] > saprykin.dmitry@gmail.com> > > […] > 'quit'. > > […] > common > > […] > but > > […] > > Yes, please do NOT create a RFC for each and every tiny feature. Just find > someone to review and eventually merge your patch! --- ## #75778 — Pierre Joye — 2014-07-21T10:52:19+00:00 URL: https://externals.io/message/75747#75778 · In reply to: #75758 On Mon, Jul 21, 2014 at 11:50 AM, Dmitry Saprykin wrote: > Ok, I will NOT )) > God saves us from bureaucracy Well, Michael's view is known. However let me explain what RFCs bring, besides bureaucracy. - clear identification of use cases, incl. edge cases - better design and design reviews - documentation, ready to be used by the doc team I do not know how big such changes will be but I can already see a couple of things that may require more than "works for me on my fav linux distros" edge cases. :) > > […] -- Pierre @pierrejoye | http://www.libgd.org --- ## #75787 — Bob Weinand — 2014-07-21T12:34:29+00:00 URL: https://externals.io/message/75747#75787 · In reply to: #75778 Am 21.7.2014 um 12:52 schrieb Pierre Joye : > On Mon, Jul 21, 2014 at 11:50 AM, Dmitry Saprykin > wrote: > > […] > > Well, Michael's view is known. > > However let me explain what RFCs bring, besides bureaucracy. > > - clear identification of use cases, incl. edge cases > - better design and design reviews > - documentation, ready to be used by the doc team > > I do not know how big such changes will be but I can already see a > couple of things that may require more than "works for me on my fav > linux distros" edge cases. :) > > > […] > > -- > Pierre > > @pierrejoye | http://www.libgd.org - Here the use case is very obvious, I don't see what a RFC would make clearer here. - That it was posted to the mailing list should usually attract enough attention to quickly review such a small patch. - Here nothing needs to be documented. People just should feel free to post it on the mailing list; if it gets controversial, then, why not, create a RFC. Bob --- ## #75790 — Dmitry Saprykin — 2014-07-21T13:08:20+00:00 URL: https://externals.io/message/75747#75790 · In reply to: #75778 Thank you for clarification. I'm agree with all points. But I think in this particular case (1 file, <20 lines of code) simple review could be enough. I'm new in php development and may be I am missing some workflow steps. If RFC is absolutely necessary I will be happy to create it but I have no enough wiki karma. > On Mon, Jul 21, 2014 at 11:50 AM, Dmitry Saprykin > wrote: > > […] > > Well, Michael's view is known. > > However let me explain what RFCs bring, besides bureaucracy. > > - clear identification of use cases, incl. edge cases > - better design and design reviews > - documentation, ready to be used by the doc team > > I do not know how big such changes will be but I can already see a > couple of things that may require more than "works for me on my fav > linux distros" edge cases. :) > > > […] > find > > […] > > > > -- > Pierre > > @pierrejoye | http://www.libgd.org --- ## #75795 — johannes@schlueters.de — 2014-07-21T14:00:55+00:00 URL: https://externals.io/message/75747#75795 · In reply to: #75747 > Php interactive shell saves commands history when you exit it using 'quit'. > But it throws all you history away when you exit using Ctrl+C. It is common > practice to save history on `SIGINT` exit (mysql, mongo, etc.) > > I would like to implement `SIGINT` handler for interactive shell to save > history on Ctrl+C exit. > > Threre is request on bugs.php.net for this feature > https://bugs.php.net/bug.php?id=67496. > I have created pull request https://github.com/php/php-src/pull/727 but > was advised to create RFC to discuss this change. > > So could you provide some feedback. I think messing with signals is not good - a script might try to catch them, too. What we can do is to save the file each time we execute something. (between the is valid code chack and zend_eval) johannes --- ## #75799 — Dmitry Saprykin — 2014-07-21T14:17:18+00:00 URL: https://externals.io/message/75747#75799 · In reply to: #75795 changed "write_history" at the end to "append_history" after each cli_is_valid_code. Now it is -1 line, +1 line commit and completely looks like bug fix. ) > > > […] > 'quit'. > > […] > common > > […] > > I think messing with signals is not good - a script might try to catch > them, too. What we can do is to save the file each time we execute > something. (between the is valid code chack and zend_eval) > > johannes --- ## #75954 — johannes@schlueters.de — 2014-07-23T12:38:24+00:00 URL: https://externals.io/message/75747#75954 · In reply to: #75799 > changed "write_history" at the end to "append_history" after > each cli_is_valid_code. > Now it is -1 line, +1 line commit and completely looks like bug fix. ) Have you tested with libedit? - A quick grep on my system shows no append_history() call, haven't checked further, though. johannes --- ## #75955 — Tjerk Meesters — 2014-07-23T12:54:38+00:00 URL: https://externals.io/message/75747#75955 · In reply to: #75954 > > > […] > > Have you tested with libedit? - A quick grep on my system shows no > append_history() call, haven't checked further, though. Yes, compilation fails with libedit (mac): Undefined symbols for architecture x86_64: "_append_history", referenced from: _readline_shell_run in readline_cli.o > > johannes --- ## #75957 — Dmitry Saprykin — 2014-07-23T13:08:42+00:00 URL: https://externals.io/message/75747#75957 · In reply to: #75954 Yes, you are right. append_history is not suitable for libedit. I left write_history call for libedit. > > > […] > > Have you tested with libedit? - A quick grep on my system shows no > append_history() call, haven't checked further, though. > > johannes --- ## #76021 — johannes@schlueters.de — 2014-07-24T16:13:19+00:00 URL: https://externals.io/message/75747#76021 · In reply to: #75957 > Yes, you are right. append_history is not suitable for libedit. I left > write_history call for libedit. Committed and pushed in a slightly modified form (variable declarations should be on top of a block) http://git.php.net/?p=php-src.git;a=commitdiff;h=d491b2f916d061666d9ff1cb5bdc484961b82db0 johannes