From owner-svn-src-head@freebsd.org Tue Oct 31 03:59:37 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3D09CE4C9A4; Tue, 31 Oct 2017 03:59:37 +0000 (UTC) (envelope-from devin@shxd.cx) Received: from shxd.cx (mail.shxd.cx [64.201.244.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 283201F22; Tue, 31 Oct 2017 03:59:37 +0000 (UTC) (envelope-from devin@shxd.cx) Received: from [64.201.244.132] (port=50453 helo=[10.0.0.105]) by shxd.cx with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1e9LpW-000Mdb-9F; Tue, 31 Oct 2017 01:59:02 +0000 Mime-Version: 1.0 (1.0) Subject: Re: svn commit: r325092 - head/usr.bin/fortune/datfiles From: Devin Teske X-Mailer: iPhone Mail (13G36) In-Reply-To: Date: Mon, 30 Oct 2017 20:59:33 -0700 Cc: Alexey Dokuchaev , "src-committers@freebsd.org" , Eitan Adler , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" , Cy Schubert , Ed Maste , Warner Losh Message-Id: <2D640E63-6C20-4904-ADF6-DAF422797604@shxd.cx> References: <201710291851.v9TIpM0I073542@slippy.cwsent.com> <20171030151627.GA74374@FreeBSD.org> <3CB26689-0D12-4E69-9BBA-58CCC3B71F3F@shxd.cx> To: Dan Mack Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 03:59:37 -0000 > On Oct 30, 2017, at 2:35 PM, Dan Mack wrote: >=20 > Devin Teske writes: >=20 >> Better in bash which allows you to filter not only on "begins with" >> but also "contains" (which is arguably more valuable than "begins >> with"). >=20 > Definately different. Better? Maybe for some. I most always search > command history by prefix and then just using multiple ESC-p invocations > to find the one command to edit/re-execute. Less frequently I want to > search the whole text of history for the whole command line sequence > like bash Ctrl-R accomplishes. >=20 >>>> To emulate this behaviour in bash, I simply create a .inputrc file in m= y >>>> $HOME with the following contents: >>>>=20 >>>> # .inputrc file >>>> "\ep": history-search-backward >>>> "\en": history-search-forward >=20 >> Interesting that you mapped these to cursor-up/cursor-down. >>=20 >> That may cause unexpected results. >=20 >> For example, typing something and then pressing up-arrow will cause >> the shell to give you the previous command that started with that >> rather than the previous command in-general. >=20 > It's ESC-p/ESC-n, not just plain up-arrow/down-arrow. =20 You cut too important context from your reply. Before I said "Interesting th= at you mapped ...", ... > On Oct 30, 2017, at 8:16 AM, Alexey Dokuchaev wrote: >=20 > On GNU/Linux boxes mine has: >=20 > "\e[A": history-search-backward > "\e[B": history-search-forward And according to wikipedia: https://en.m.wikipedia.org/wiki/ANSI_escape_code Under "CSI Sequences" ... \e[A is really "cursor up" (CUU; with syntax of CSI [n] A) \e[B is really "cursor down" (CUD; with syntax of CSI [n] B) NB: CSI is \e[ > Up arrow still > does up without any search. Not if you do what danfe did above, in the restored context. > At least with my config using \ep as shown. > My up arrows work for me as expected - they just iterate forward and > backward through shell history. >=20 That is expected behavior. --=20 Devin