[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: What should be the expected behavior for $_ ?
From: |
Siteshwar Vashisht |
Subject: |
Re: What should be the expected behavior for $_ ? |
Date: |
Mon, 25 Nov 2019 09:21:04 -0500 (EST) |
----- 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
- Re: What should be the expected behavior for $_ ?,
Siteshwar Vashisht <=