From owner-svn-src-head@freebsd.org Tue Oct 31 14:49:30 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 9657FE5BCAC; Tue, 31 Oct 2017 14:49:30 +0000 (UTC) (envelope-from mack@macktronics.com) Received: from borg.macktronics.com (gw.macktronics.com [209.181.253.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6E7397C829; Tue, 31 Oct 2017 14:49:29 +0000 (UTC) (envelope-from mack@macktronics.com) Received: from pandora.local (olive.macktronics.com [209.181.253.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by borg.macktronics.com (Postfix) with ESMTPS id 5A7DF529; Tue, 31 Oct 2017 09:49:22 -0500 (CDT) From: Dan Mack To: Devin Teske 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 Subject: Re: svn commit: r325092 - head/usr.bin/fortune/datfiles In-Reply-To: <9CD7866D-BF74-4618-8FFE-E9C47D4DA328@shxd.cx> (Devin Teske's message of "Mon, 30 Oct 2017 21:33:35 -0700") References: <201710291851.v9TIpM0I073542@slippy.cwsent.com> <20171030151627.GA74374@FreeBSD.org> <3CB26689-0D12-4E69-9BBA-58CCC3B71F3F@shxd.cx> <9CD7866D-BF74-4618-8FFE-E9C47D4DA328@shxd.cx> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (darwin) Date: Tue, 31 Oct 2017 09:49:21 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain 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 14:49:30 -0000 Devin Teske writes: >> On Oct 30, 2017, at 2:35 PM, Dan Mack wrote: >> >> Devin Teske writes: >> >>> Better in bash which allows you to filter not only on "begins with" >>> but also "contains" (which is arguably more valuable than "begins >>> with"). >> >> Definately different. Better? > > Typical session of editing exim acls on the mail server: > > 1. Log in via ssh to bash > 2. Esc-P vi ENTER > (pulls up "sudo vi /usr/local/etc/exim/acls/relay_domains") > 3. ENTER > 4. Make changes in vi, save, exit > 5. Esc-P restart ENTER > (pulls up "sudo service exim restart") > 6. ENTER > > Ok, so if I was using tcsh, I cannot call this "better": > > 1. Log in via ssh to tcsh > 2. sudo vi Esc-P > (pulls up "sudo vi /usr/local/etc/exim/acls/relay_domains") > 3. ENTER > 4. Make changes in vi, save, exit > 5. sudo service exim r Esc-P > (pulls up "sudo service exim restart") > 6. ENTER > > As you can see, being able to match on contents rather than begins-with saves me valuable keystrokes and allows me to find history elements faster with less effort. > > Take the example of using "service". Imagine: > > 1. Esc-P restart > 2. Esc-P stop > 3. Esc-P reloas > > Etc. > > Using the tcsh implementation you simply cannot navigate the history sequentially like that. > > However... there is the fallback of history substitution to pluck elements in tcsh which also works in bash: > > !?text?:p > > This will copy the most recent history element containing "text" onto the top of the history. > > In bash you can turn on histverify (using shopt) which will allow you > to use simply "!?text" (without quotes) to pull up the previous > command containing "text". In tcsh and zsh -- which lack the > histverify shell option -- the syntax "!?text" will still work but > without the "?:p" modifier will execute the match right away. > > However, this cross-shell history substitution feature does not allow matching on "begins-with", only "contains," and as-such is not as flexible as bash's Esc-[PN] feature. > > Though, I admittedly use history expansion a lot too. ^^ i use '!$' constantly to pull up the last argument to the previous command Definately appreciate your perspective. My lack of doing this the bash way is really just a side effect of being an early tcsh user, bash not being everywhere I needed it, habbit, and prefix thinking with respect to searching command history. Dan