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

Groups > gnu.bash.bug > #15633 > unrolled thread

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

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

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

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

----- 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

[toc] | [standalone]

Back to top | Article view | gnu.bash.bug

csiph-web