Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #15633

Re: What should be the expected behavior for $_ ?

Path csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail
From Siteshwar Vashisht <svashisht@redhat.com>
Newsgroups gnu.bash.bug
Subject Re: What should be the expected behavior for $_ ?
Date Mon, 25 Nov 2019 09:21:04 -0500 (EST)
Lines 80
Approved bug-bash@gnu.org
Message-ID <mailman.2574.1574691746.13325.bug-bash@gnu.org> (permalink)
References <880841828.14107306.1522764210557.JavaMail.zimbra@redhat.com> <2fbd26f8-811a-579b-7799-e2e8c6532840@case.edu> <5AC41639.6010006@tlinx.org> <621305317.18102863.1574691664255.JavaMail.zimbra@redhat.com>
NNTP-Posting-Host lists.gnu.org
Mime-Version 1.0
Content-Type text/plain; charset=utf-8
Content-Transfer-Encoding 7bit
X-Trace usenet.stanford.edu 1574691747 3533 209.51.188.17 (25 Nov 2019 14:22:27 GMT)
X-Complaints-To action@cs.stanford.edu
Cc bug-bash@gnu.org
To chet ramey <chet.ramey@case.edu>
Envelope-to bug-bash@gnu.org
DKIM-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1574691739; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5ithIMG3g4oXjaJC7YnuHnesO+/2SonHAeW74lShIFE=; b=C3gSSdIzteupA/QTXvTqHeC7ppNo3SZUCi2AtIbZdty/sR/ZAUI7ICfimUYyzs9G5VI9RP TX60T7F4AINQPwYGmNUsYYqCn2k8x7sB7h/JdP3rkwCc8qrWhnlwHRcReq9bwTGqwFAUy9 UUWYCgVs1EA6VJmMG8gkXq5j1DtgJts=
In-Reply-To <5AC41639.6010006@tlinx.org>
X-Originating-IP [10.43.2.182, 10.4.195.18]
Thread-Topic What should be the expected behavior for $_ ?
Thread-Index rfztiGon+onaXeOX5Ss6ihBn2pKkyA==
X-Scanned-By MIMEDefang 2.84 on 10.5.11.22
X-MC-Unique tYj_ro4AMCGGH7vMA2PAkQ-1
X-Mimecast-Spam-Score 0
X-detected-operating-system by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy]
X-Received-From 207.211.31.81
X-BeenThere bug-bash@gnu.org
X-Mailman-Version 2.1.23
Precedence list
List-Id Bug reports for the GNU Bourne Again SHell <bug-bash.gnu.org>
List-Unsubscribe <https://lists.gnu.org/mailman/options/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=unsubscribe>
List-Archive <https://lists.gnu.org/archive/html/bug-bash>
List-Post <mailto:bug-bash@gnu.org>
List-Help <mailto:bug-bash-request@gnu.org?subject=help>
List-Subscribe <https://lists.gnu.org/mailman/listinfo/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=subscribe>
X-Mailman-Original-Message-ID <621305317.18102863.1574691664255.JavaMail.zimbra@redhat.com>
X-Mailman-Original-References <880841828.14107306.1522764210557.JavaMail.zimbra@redhat.com> <2fbd26f8-811a-579b-7799-e2e8c6532840@case.edu> <5AC41639.6010006@tlinx.org>
Xref csiph.com gnu.bash.bug:15633

Show key headers only | View raw



----- Original Message -----
> From: "L A Walsh" <bash@tlinx.org>
> To: "chet ramey" <chet.ramey@case.edu>
> Cc: bug-bash@gnu.org, "Siteshwar Vashisht" <svashisht@redhat.com>
> Sent: Wednesday, April 4, 2018 2:03:05 AM
> Subject: Re: What should be the expected behavior for $_ ?
> 
> 
> 
> Chet Ramey wrote:
> > On 4/3/18 10:03 AM, Siteshwar Vashisht wrote:
> >   
> >> $ mkdir testdir
> >> $ cp rpmall.txt rpmshort.txt $_ # Use tab completion to complete filenames
> >> cp: target '_filedir' is not a directory
> >>
> >> Last command fails because tab completing 'cp' command modifies value of
> >> '$_'. Shall value of '$_' be modified if a command gets executed in
> >> background ?
> >>     
> Well -- two things -- 1, "use tab completion to complete filenames" --
> WHAT filenames?  Did you really mean to look for other files?  Usually
> '$_' is rather ephemeral -- doing anything between the last command
> and the use of '$_', would seem to be perilous if you want to to make
> use of '$_'.  And 2nd -- it's not really the case that command completion
> is done in background (exactly), but more "behind the scenes".
> 
> Seems more like you are making an argument for not relying on the value
> of '$_' in interactive use.  Maybe in a script -- where interactive
> things might not be happening but....as more automations get added
> to your shell (whether from bash or some addon package), using $_
> could possibly lose its value in other ways.
> 
> 
> * Maybe yet-another-option -- to have '$_' be equal to the last arg
> of the last command executed in the same "context" -- i.e. if
> interactive, then from the last interactive command, or if in a script,
> from last arg of previously executed line...
> 
> I'd prefer to see that^^, than to change the current behavior, as I'd
> be too concerned about unforeseen consequences, though I'm not sure
> how common the problem is vs. work involved in changing it.
> 
> >
> > It's an interesting question. You want $_ to expand to the last argument
> > (or last word) of the previous history entry when the shell is interactive,
> > which is available as !$, instead of the last command executed by the
> > current shell instance.
> >
> > Should the command line know about shell functions and commands executed in
> > the foreground on its behalf? What should the behavior be in a
> > non-interactive shell? What do folks think?

Can we at least document this behavior in man page if we can't change it ?

> >   
> ----
>     Suppose some shell func/cmd executed deliberately changes the value of
> $_ for some reason?  I can't think of a good reason why, off hand, but
> others might have a better imagination.... ;-)  Is there a common
> entry point for something like bash_completion to save such a var if
> it wants to (I don't know).
> 
>     Besides, even relying on '$_' being the last word of '!$'
> wouldn't work when histexpand is off or disabled -- I have too many
> surprises with '!' expansion.
> 
> 
> 
> 
> 
> 

-- 
--
Siteshwar Vashisht

Back to gnu.bash.bug | Previous | Next | Find similar | Unroll thread


Thread

Re: What should be the expected behavior for $_ ? Siteshwar Vashisht <svashisht@redhat.com> - 2019-11-25 09:21 -0500

csiph-web