TIL: Use $_ to reuse the last argument in Bash/linux terminal commands!

[-]

Ultimate_Mugwump@reddit

I did not know this, but afaict !$ does the same thing, and it’s a little easier to type imo

[-]

elrata_@reddit

It's not the same. That will use the previous command you executed, this is with an &&, the last command has not been executed

[-]

Megame50@reddit

Sure, but it still works for the purpose stated by OP, right? In practice mkdir dir followed by cd ESC+. is definitely how I'd input this as two commands, rather than one.

[-]

elrata_@reddit

No, it doesn't work for the first command in an && from the second. Does it?

[-]

What I mean is you don't need to type the above as one command if it doesn't save you time. It's quicker to type it as two commands in an interactive shell with the keyboard shortcut to insert the last argument, so in practice that's usually what I'll do.

In fact I'd say there's a minor advantage to using two commands, in that if mkdir fails you 'll get the error immediately and wont have wasted 100ms typing cd $_.

[-]

kjensenxz@reddit

So, not only are you wrong, you also don't mind ignoring what && does...

[-]

Megame50@reddit

If mkdir fails you'll know before you hit another key. Just don't type cd at that point. <RETURN>cd ESC+. is six keystrokes keystrokes, while && cd $_ is eight.

[-]

whosdr@reddit

In fish however it seems to rerence the command part instead. That doesn't seem so useful..

e.g. echo hi then echo $_ yields echo

[-]

degrix@reddit

In fish, the equivalent is Alt-Up. This cycles backwards through your history of command parameters. Alt-Down does the reverse.

[-]

whosdr@reddit

That is nice, but is useless for quick scripting. I can't put alt-up in a loop.

[-]

degrix@reddit

You would need to write a simple helper function for the same behavior if you were wanting to script with it. Alt-Up/Alt-. is only for interactive usage.

[-]

gloriousPurpose33@reddit

Surely they made this featuring knowing how existing shells already implement it... it feels silly to have their shell do it exactly backwards

[-]

wpm@reddit

ZShell decided that starting arrays at index 1 was a good idea too, all the shells are full of dumb choices.

[-]

gloriousPurpose33@reddit

Oh dear...

[-]

Daholli@reddit

Fish is not POSIX compliant, so I assume stuff like that is deliberately done

[-]

gloriousPurpose33@reddit

If that was done deliberately it comes off to me as very stupid. To intentionally observe and make something commonly known across multiple shells behave oppositely.

[-]

cpt-derp@reddit

Yeah I wonder if fish's user friendliness even precludes POSIX compatibility. That just feels like a low bar. You can have all nice things and still be a drop-in for sh

[-]

zinozAreNazis@reddit

I stopped using fish for small but very frustrating things like this. Once configured zsh is still the best shell on any Unix system.

[-]

CardOk755@reddit

Once configured zsh is still the best shell on any Unix system.

Oh god, now they want to make me waste my life configuring the shell.

[-]

fearless-fossa@reddit

A basic configuration that is equal or better than standard bash is quickly done, and afterwards you just dump your .zshrc on every device you want zsh on.

[-]

Wemorg@reddit

I have over 100 linux machines at work and about 10 private machines. I don't want to sychronize changes across all devices in my dot files. I'll just stick with the default config in most cases.

[-]

Megame50@reddit

Are you saying you just use bash with an empty bashrc? Fish might be usable with little or no configuration, but both bash and zsh are very bare bones without any config. Even if you use fish surely there's some effort to install it everywhere, right?

I log in to plenty of remote machines and plenty of ephemeral VMs. It's not that difficult to share your configs imo. Personally I have dotfiles tracked in git and a subset of portable dotfiles marked for export (using git attributes) to any machine even if I don't want to clone all of my dotfiles. I typically export them with just git archive piped directly to ssh host tar -xzf -, no git remotes involved, so in practice its just one extra command before I log in the first time. It's not like I change my zshrc all the time.

[-]

CardOk755@reddit

Then why is that not the default.

[-]

fearless-fossa@reddit

Because people complain when things change?

[-]

syklemil@reddit

they want to make me

"you can" ≠ "they want to make you"

E.g. you can bling out your prompt with starship and have all sorts of neat stuff in $XDG_CONFIG_HOME/fish/conf.d, but it's entirely voluntary and opt-in.

In the same vein, you don't have to use $_ in bash either, you're free to use a rather minimal feature set (or even stick to posix-isms if you have to support /bin/sh rather than /bin/bash).

Also personally I started with desktop Linux following Windows ME, and while I've had a stint with server Linux, where I'm working that seems to be going away in favor of distroless containers running in Kubernetes (where the nodes are also GNU-less), so falling back to default bash is fine in the rare cases where I find myself logging in to some legacy VM.

[-]

RndPotato@reddit

I think it was hyperbole ;)

[-]

RndPotato@reddit

I remember back in the day when I used csh and then thought ksh was the bees knees and then bash came out. shells today are so nice.

[-]

whosdr@reddit

Having to convert all my existing configurations from Fish to ZSH seems like it might be a pain.

Any resources you might recommend?

[-]

whosdr@reddit

The single reason I use it seems to be for the string manipulation functions. I've not got around to learning some of the other methods.

Well, that and the fact that even on a basic install with no configuration it has colours. I sometimes find myself switching to another user for admin tasks and immediately invoking fish just to be able to read things better. These are user accounts without any configurations or real home directories.

I haven't looked at what zsh has admittedly.

[-]

dexter_brz@reddit

$_ and !! I use them very often

But $ is very powerful in scripts I recommend you to learn about it.

[-]

ilikejamtoo@reddit

Esc-. too, if you're using bash interactively.

[-]

turtlecattacos@reddit

you can also use meta - . Most places you use esc as a modifier key, you can use meta as a replacement

[-]

siodhe@reddit

That's handy. Normally I use history substitution with

mkdir dir1
cd !$

But that doesn't have the test. Still, check out history substitution sometime, it's one of the reasons Csh users were able to switch to Bash way back in the long long ago :-)

That weird $_ is mentioned in https://stackoverflow.com/questions/5163144/what-are-the-special-dollar-sign-shell-variables which gives this list:

$1, $2, $3, ... are the positional parameters.
"$@" is an array-like construct of all positional parameters, {$1, $2, $3 ...}.
"$*" is the IFS expansion of all positional parameters, $1 $2 $3 ....
$# is the number of positional parameters.
$- current options set for the shell.
$$ pid of the current shell (not subshell).
$_ most recent parameter (or the abs path of the command to start the current shell immediately after startup).
$IFS is the (input) field separator.
$? is the most recent foreground pipeline exit status.
$! is the PID of the most recent background command.
$0 is the name of the shell or shell script.

However, although my bash supports the $_ in this context, the man page doesn't document it (yet?).

I'm a bit baffled that $_ is overloaded this way.

[-]

syklemil@reddit

Given all the posts about SO dying on reddit recently, I find that this a case of what I talk about when I say that part of their decline is that for newer languages we seem more likely to go to the primary documentation.

In this case, the GNU Bash reference manual says the following about $_ (from section 5.2 Bash variables):

_

($_, an underscore.) At shell startup, set to the pathname used to invoke the shell or shell script being executed as passed in the environment or argument list. Subsequently, expands to the last argument to the previous simple command executed in the foreground, after expansion. Also set to the full pathname used to invoke each command executed and placed in the environment exported to that command. When checking mail, this parameter holds the name of the mail file.

Some of the others there are listed under 3.4.2 special parameters. There's also a lot of detail to be aware of in 3.5.3 Shell parameter expansion, that I think most of us hope we'll never actually encounter.

[-]

siodhe@reddit

"SO"?

I know most of those anyway, except for the ${var@...operator...} transformations, those seem new.

Manual pages are typically authoritative for *nix commands, with everything else being both secondary and probably not synched to the version you personally have installed locally.

Sort of the same idea as to always, for git repos, put the documentations in the repo, rather than use some weird adjunct doc repo like Gitlab provides (or provided, at least, I'm out of date about Gitlab) - which won't stay synched to the branch you have checked out.

[-]

syklemil@reddit

SO as in "StackOverflow". They've had a huge loss of activity since 2017, and are now nearly dead in the water. People have a variety of reasons for that; LLMs and the culture being perceived as very hostile are the main things people mention. I like to bring up that there's also a discrepancy between current tools and languages and SO activity, as in, people seem to be better able to rely on primary sources for newer technologies, while SO covers for older technologies that either have bad primary documentation, or primary documentation that doesn't come up well in searches.

[-]

siodhe@reddit

Yeah, signal to noise on Stack Overflow did go way down, but between the compsci-related stuff and all the other forums, I'll admit being surprised at a downturn in a system that overall I still like.

GNU really should have generated linear manages from the same info source and just made both available. Granted, I virtually always just read "info" in Emacs itself, hardly ever using the command.

[-]

syklemil@reddit

I'll admit being surprised at a downturn in a system that overall I still like.

Yeah, I hope they at the very least stay up as an archive. I don't swing by them for newer stuff, but I've been trying to configure a "mature" Java system which seems to think that throwing stack traces at me is an acceptable way of telling me I've misconfigured something, and at some point I just need someone who says "yeah, that stack trace means that you can't write to specific file that was never mentioned".

These days I expect stack traces for bugs in the application, and clear error messages, preferably even with something actionable, for my user errors. So for the apps and programming languages that do that, and that have good documentation systems, I find I don't need SO.

And I'm not alone in that: Looking at some language stats it's clear that newer languages like Typescript, Rust and Go feature much, much less on StackOverflow than their github activity would indicate, compared to languages like Java, Python and Javascript.

GNU really should have generated linear manages from the same info source and just made both available.

Eh, manpages are venerable and all, but I can also understand that GNU found that system too incapable to hold all the relevant information. The info docs are the same as on the website I linked earlier (modulo installed version), and they'd likely have to split that up in a bunch of manpages the way zsh does—and navigating the zsh collection of manpages never felt great either.

I virtually always just read "info" in Emacs itself, hardly ever using the command.

Ironically I think a lot of us bounced off info because we interpreted it as too emacs-y.

[-]

siodhe@reddit

I hate the stack-trace-is-enough attitude too, since it doesn't include any of the local var values that probably caused the problem. Super annoying.

Granted, there was an era where debugging was amazing and software was reportedly fun - on LMI LISP machines and similar. Too bad LISP is essentially too powerful, cutting some of the incentive out of writing good sharable libraries.

Hah, info is essentially a light web page style doc system with a text interface, and it's not like everyone bounced off of web pages. There are web-based front ends to the unix man pages that even link them all together through the See Also section (hell, I think I wrote on once).

My biggest pet peeve currently is how developers have essentially given up checking malloc call returns, because the cancer of overcommit has infected so many linux dists. Firefox routinely likes to grab all the rest of vram (libxul.so, I think) for no reason, and since my hosts disable overcommit (using swap instead, same size as ram), I have to run this garbage in a ulimit-constrained shell to keep its memory grabby nature under control. They have rather a lot of excuses for being bad at software development - but the one the holds water is when the bloody library writers do the same condemnable thing.

[-]

syklemil@reddit

I hate the stack-trace-is-enough attitude too, since it doesn't include any of the local var values that probably caused the problem. Super annoying.

And it's very … programmer-oriented. In my case I know how to read them, but I think being able to work with the programming language in question (or additional tooling like debuggers) shouldn't be necessary for plain end users who had a typo in a config file, or did some other ordinary misconfiguration.

Java seems to have a specific culture around it: They made checked exceptions a bit too annoying to work with, and grew a culture of "just don't handle the exceptions lol". Other programming languages make the same information available in T foo() throws E as union types (e.g. Rust with Result<T, E>) or tuples (e.g. Go with the (T, E) pattern), so they essentially only have the checked exceptions but not the unchecked, and it turns out the way Java ended up wasn't the way it had to be. Alas.

Hah, info is essentially a light web page style doc system with a text interface, and it's not like everyone bounced off of web pages.

No, but terminal browsers remain very niche, and even among them, lynx/links/elinks and the like remain more common I think than whatever the GNU terminal browser is called (w3?) is. If it'd just worked with $BROWSER it might've been more popular?

[-]

siodhe@reddit

Exceptions generally seem to complicate error handling rather than help unless they're done really well. "Complicate" meaning that the program just emits some error message that might contain a useful local and then crashes, because by the time you've left the local context - due to iffy design - it's too late to handle the error.

Tty browsers are very niche. My mention of a web wrapper around man was an actual HTML version, intended for web viewing. There ought to be such a wrapper for info too - some option that just tosses the URL to your local info stash at the web browser or tells you the URL to use.

Wikipedia has had suboptimal moments too. Jerks who decide arbitrarily that a wiki page is "too long", and just cut random stuff out. Or they describe some concept like RAII (Resource Acquisition Is Initialization, but generally reduced the examples to languages that do it implicitly, hiding how RAII is done (there used to be a C example that showed how), and worst of all, the current version of the page only has a single example in C++, probably one of the worst languages to use due to its marginal readability and reliance on on users somehow having understood a large chunk to do even the simplest things, and somehow even with a mutex, the presence of which the example doesn't even bother to justify.

Ack.

[-]

syklemil@reddit

Exceptions generally seem to complicate error handling rather than help unless they're done really well. "Complicate" meaning that the program just emits some error message that might contain a useful local and then crashes, because by the time you've left the local context - due to iffy design - it's too late to handle the error.

I mean, getting a stack trace generally means it wasn't handled at all. At some point getting a stack trace without crashing the service feels kinda insulting, as someone figured they should catch the exception at some point to prevent the entire service going down, but instead of doing anything useful with it, they just printed it to stdout or the loghandler. Thanks.

It's more work for the programmer, but I'd like it if they could at least take the time to relay what assumption of theirs broke, or even just tell me "failed writing /path/to/crap" so I can at least try to reason about why it'd want to write that file, and whether it should be permitted to.

The "should" error message style Rust encourages is good IMO; even better if I get something like miette output. It seems to be spreading into more tools, so I'm kinda hopeful the "just spew stack trace" style of error messages will go away over time. Writing good, actionable error messages is work, but work worth doing.

[-]

siodhe@reddit

> Writing good, actionable error messages is work, but work worth doing.

Exactly :-)

[-]

sza_rak@reddit

In bash try alt+tab in this case.

If the argument was simple (no slashes - if anyone know how to make bash treat long paths as single argument let me know) then it will flip the two words.

So:

command arg

Alt+t

Ctrl+w

arg2

Alt+t

Somehow it feel easier for my hands than reaching for $_

[-]

UntestedMethod@reddit

no slashes - if anyone know how to make bash treat long paths as single argument let me know

Do you mean wrapping it in quotes?

[-]

sza_rak@reddit

No, I mean change default way bash detects words. And I already mentioned answer in edit.

[-]

KishCom@reddit

Similarly, I use !! all the time, repeats the entire last command.

$ pacman -Syu

error: you cannot perform this operation unless you are root.

$ sudo !!

:: Synchronizing package databases...

[-]

HandwashHumiliate666@reddit

In fish, after accidentally running pacman -Syu just press

[-]

lego_not_legos@reddit

Don't do this if you use tab-completion. Who doesn't?

Pressing tab during a subsequent command to complete it or its arguments will run further commands to perform that completion. Those will overwrite the $_ from the previous command that you can see. So you can only use this into never press Tab. Also, not escaping your shell variables (here it should be "$_") is a noob mistake.

[-]

syklemil@reddit

At the point where you're going "$_" I'm guessing you might in some cases actually want "${_[@]}", at which point I'd use an actual name. "${foo[@]}" is line noisy enough as it is without replacing foo with _.

Even without the tab special surprise, I'd rate bash as wibbly-wobbly enough to always be specific with variable names rather than rely on and assume the reader can keep track of what $_ holds.

There are some other languages with _ variables; IME perl works pretty similarly with magic $_ and @_ variables, but they're best used when omitted for pointfree programming, not as actual placeholders over time. Other languages use the _ name to essentially mean "I have to assign to this variable for some reason, but please just throw it away asap, I will never read from it"; it's essentially the name variant of /dev/null.

[-]

animeinabox@reddit

I was told it's not safe. True?

[-]

lego_not_legos@reddit

It's not.

[-]

AlveolarThrill@reddit

What I'm about to describe is an old and well-known trick, I didn't come up with this, but I use this inside an alias in my .bashrc along with Bash string manipulation to be able to quickly go to the directory in which the last accessed file is located.

alias cdir="cd ${_%/*}"

The relevant bit is the mess of characters at the end:

${} is used for manipulating Bash variables.

Inside it, you write the variable names directly, so just _ is used to denote the $_ variable, the final argument of the last command.

The % is a string operation that, from the end of a string, removes the shortest possible match for a pattern specified after it, in this case /*, which is just a forward slash and a wildcard. So, everything after the last forward slash, and the slash itself, will be removed from the string.

It's meant to be used when you do something like vim /etc/foo/bar.cfg, exit, and want to go to the directory immediately. Instead of typing out the path all over again, which can be annoying even with tab completion, you just type cdir. The pattern will take the last argument (the file path), remove the last slash and everything after it, and then use it as an argument for cd, so in this case the alias will evaluate to cd /etc/foo and execute.

In the command line, I navigate mainly with just tab completion, often directly with vim or what have you, and sometimes the file paths get quite long, so this little alias has come in quite handy on many occasions. Highly recommend.

[-]

Ezmiller_2@reddit

Or just hit the up arrow?

[-]

dosangst@reddit

right?

[-]

dosangst@reddit

or just hit the up arrow

[-]

Former_Substance1@reddit

wait till you discover ALT + .

[-]

ang-p@reddit

TIRTFM?

[-]

GarThor_TMK@reddit

This is also a feature of powershell... though it doesn't work quite the same way as bash...

You see this a lot with piping...

`ls | foreach { write-host $_ }`

for example...

[-]

mina86ng@reddit

For mkdir + cd I have a function:

md () {
    if [ $# -eq 0 ]; then
        echo usage: 'md dir [ dir ... ]' >&2
        return 1
    fi;
    mkdir -p -- "$@" && \cd "$1"
}

For any other situation I find !$ more convenient. It’s easier to type, doesn’t need to be quoted and with `bind '" ": magic-space' I can easily edit the expansion.

[-]

cpt-derp@reddit

I'd make it "mcd", make and change directory. If you have mdadm and autocomplete, it'll resolve definitively (add the extra space automatically) rather than wait for you to tap tab again and show md or mdadm.

[-]

mina86ng@reddit

Why would I use autocomplete rather than pressing space?

[-]

cpt-derp@reddit

I mean if I'm using mdadm and want to tab autocomplete at "md" but then I realized md5sum exists, among other commands.

[-]

Meowthful127@reddit

Also there's !:[n], which takes the nth argument from the command you previously ran. I find it useful for something like this:

$ ls /path/to/some/dir/
[output of ls] ...
$ nvim !:1/file
# expands to nvim /path/to/some/dir/file

[-]

0b0101011001001011@reddit

You can alias that to something shorter as well.

[-]

NikuKuda@reddit (OP)

Are talking about the whole command mkdir dir1 && cd $_ or just $_ for aliasing??

[-]

0b0101011001001011@reddit

Well in fact not exactly alias, but just make a function in your .bashrc file.

mcd() { mkdir -p "$1" && cd "$1" }

Now when you type

mcd dir1

It creates that directory (unless it exists) and then changes to it.

[-]

CrankBot@reddit

That's alright for automating specific pairs of commands. But having a general macro for the last arg is still essential bc there are tons of scenarios where you are reusing the same "subject" which you can't predict them all or need variations.

[-]

CrankBot@reddit

m-. to insert the last arg at the cursor. This is a readline feature and usually enabled but t default. You can customize it with .inputrc.

Readline also controls hotkeys like Ctrl-A and Ctrl-S to move to the beginning and end of the line and there are a bunch of other handy macros you can do like "delete the word under the cursor" and "delete from the cursor to the beginning/end of the line."

There's a great article that's probably 15-20 years old on customizing inputrc and existing readline macros. I'll see if I can find it.

[-]

arglarg@reddit

Another one: you can do sudo !! If you forgot it, ant that's oddly satisfying

[-]

zinozAreNazis@reddit

I am using the double Esc shortcut to append sudo to either current or last command. It’s one of my most used and loved modification I made in zsh.

https://github.com/anatolykopyl/doas-zsh-plugin

I have a chrome version of it but this works the same

[-]

ReallyEvilRob@reddit

Meta-period will do the same thing.

[-]

likeavirgil@reddit

Another useful one is ‘!!’. Run ‘do_something’, no permissions, run ‘sudo !!’ to run the previous command again but with sudo this time

[-]

michaelpaoli@reddit

Shell Variables
    The following variables are set by the shell:
    _      At  shell  startup, set to the pathname used to invoke the shell
           or shell script being executed as passed in the  environment  or
           argument  list.   Subsequently,  expands to the last argument to
           the previous simple command executed in  the  foreground,  after
           expansion.   Also  set  to the full pathname used to invoke each
           command executed and placed in the environment exported to  that
           command.   When  checking mail, this parameter holds the name of
           the mail file currently being checked.

bash(1) - Read The Fine Manual (RTFM).

Also, not POSIX, so may not be present in other shells (though dash(1) seems to have some use of $_, though it doesn't appear to be documented on dash(1)). $_ looks to have first appeared in Korn shell(?) (which bash is heavily based upon).