Nice list, here are suggestions for improving a few of the commands:
Generate Random Passwords
>_ < /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c6
This produces a 6-character password which only has 35 bits of entropy. It also doesn't print a newline, causing the password to be on the same line as the next prompt. Better to use something like:
Find the process that is using a certain port e.g. port 3000
>_ lsof -P | grep ':30000'
This command will be extremely slow on large systems with a lot of open files. It is essentially listing every open file (the -P flag just inhibits port mappings from e.g. "port 22" to "SSH") and then grepping the output. Much better to run:
>_ lsof -i :30000
Which is not only shorter, but much faster as it directly gets info about that port.
Add your public SSH key to a server in one command
>_ cat .ssh/id_rsa.pub | ssh hostname 'cat >> .ssh/authorized_keys'
This is what the "ssh-copy-id" utility, which is part of the openssh-client package, does already.
Please don't use -exec. Use -print0 and xargs -0 instead, as it's much safer, and correctly passes newlines and other problem characters. Even BSD adopted this idiom.
GNU find says this very specifically: "There are unavoidable security problems surrounding the -exec action..."
This part will likely confuse people who are not familiar with shell and will create a bunch of thousands "_" files worldwide.
Quick explanation:
>_ echo hello
or equivalently:
echo hello >_
when executed in a shell creates a file named "_" with contents of "hello". Author seems to use ">_" as a terminal icon, but many will copy it as part of a command.
That is, if I'm not missing anything clever here.
Upd: copy button doesn't copy the >_ part, so the "icon" theory seems to be correct.
A ‘trick’ for fancy prompts containing information is to give them the form,
: all the stuff;
As long as ‘all the stuff’ is parseable as shell words (which you can ensure by quoting with printf '%q' if there's doubt), then you can copy and paste entire lines.
Note that this isn't guaranteed to be a no-op for arbitrary "all the stuff". Specifically it won't work for commands involving pipes, or commands involving command substitution / process substitution. That is:
: bar "$(foo)"
: bar <(foo)
: < <(foo) bar
: bar | foo
I read about this long ago, possibly in the Blit era, possibly in ;login: (other order, other reasons). It's old lore, but not widely known, so I try to mention in when the subject of prompts comes up.
Agreed, including the ">_" prompt in the command line isn't really helpful. The copy icon works, it's extra unnecessary cognitive overhead. Also, ">_" is an unusual prompt, I don't know what distro ships with that by default.
">" is the prompt on MS-DOS, and "_" is the cursor.
Somehow this has resulted in ">" or ">_" being the terminal "icon" even in unixy parts of the world; looking at the generic "utilities-terminal" icon: the default theme for Gnome 3 ("Adwaita") uses ">_" in the icon, the default theme for KDE ("Breeze") uses ">", and the runner-up ("Oxygen", which also comes bundled with KDE), also uses ">_".
Yes, I wonder what benefit there is to include `>_` as the prompt. The obvious drawback is confusing some poor souls. Also it's ugly, who would want to use `>_` as their prompt?
It could have at least a less prominent color. And it could be added with a `::before` pseudo-element so you can't select it (just for decoration). Might be also annoying for screen readers without `aria-hidden`.
Yeah, I hate being that kind of guy but seriously... oneliners displayed over 5 lines because the columns are very small, commands in dark red on black...
Reasonable feedback. The design isn't great and can only get better from here one. I pushed some quick design updates with a new standard font, decreased the font size for the headline, slightly bigger columns and some other fixes and improvements
I wrote a shell script [1] that allows me to write my own mini-man pages to capture things exactly like this. Whenever I have to do something non-trivial on the command line that I will 1) likely need to do again at some point and 2) don’t do often enough to commit it to memory, I simply create a new little note. They are viewable in the terminal just like normal man pages so the notes are trivial to read once written. It’s worked extremely well for me!
Nice, this is exactly what I needed. I had my one liners in Notable to look them up but this is way more seamless AND it integrates great with Notable at the same time with the UAL folder in the Notable notes directory and a slightly more complex UAL "edit" to add the Notable metadata.
I think we should change the link to sort by votes all-time [1]. It's just fun to go through and see some of this stuff. The longer I use the terminal, the more of its power I come to respect. There's so many tools, so many parameters for each tool. It takes a really long time to build up muscle memory of what things you can do and remembering how to do them in that perfect situation.
Recently I've been trying to take at least 20 minutes a day to try and do things the tricky way by stringing these commands together. It's fun and the productivity wins of being able to string together several of these things in a pinch is fantastic.
Although it's definitely more fun than useful at this point~
Using conditional includes in your global gitconfig based on the path is a much less error prone way of having different identities for different projects.
1. Pointing your webserver to your current directory. Simplifies copying files to your local box.
The simple python 3.x way...
python -m http.server 8001
And the original way I used to do it...
function sfiles() { x=`ipconfig getifaddr en0`;echo $x:8001;ruby -run -ehttpd . -p8001; }
And please use this with *extreme* caution because any files you've got access to on your remote box will have no authentication when they're exposed via HTTP.
My most frequently used one liner...
2. Regex searching files in directories.
grep -inR <keyword> *
The Silver Searcher, aka ag, is better but not natively installed so...
I'm unsure what the "sort dotted quads" one-liner is really supposed to buy you. Yes, you can define multiple keys and all that. But an IPv4 address in dotted notation is literally indistinguishable from a multi-part semantic version number.
I fully agree: each time a command in awk or sed or bash becomes complex, it is the right time to switch to perl. Perl does not have all the limitations of (awk, sed, bash) while having concise syntax.
Does anyone have the original link this was submitted as? I looked at it earlier today and thought I should look at it again later but now it points to much less interesting commands.
I love the site, I was looking for something similar a while ago and I guess I found it today. As I spend most of my time in command line this website can really teach me new ways
I still primarily rely on StackOverflow for most of my shell one-liner needs, but I've found it extremely helpful to make a list/spreadsheet of the commands I repeatedly find myself having to google: https://github.com/dannguyen/bashfoo#toc
I save all my history and have a little script to grep it for commands I've used.
There was a thread on here about a shell add-on that would recommend one-liners, but I can't recall it ... anyone have any ideas?
Also I'd like a more robust version of my saved commands history (after 10 years or so it's getting to be like I want to make it a bit slicker), maybe backed by sqlite or something. Any suggestions?
Do you know about ctrl-R? At the prompt in bash, it lets you search your previous commands and edit and run them right there. Combined with a large HISTSIZE it's really useful.
Also starting to type a command and using up-arrow to scroll through (I assume) endings of that command line that are in history. That's great too. But I often don't do, say,a do-release-upgrade (I use Kubuntu but prefer command line upgrade) within the time the command stays in history.
It mentions that this command loads the file to RAM for faster usage. I do not understand how this works. How do you access the "RAM version" of the file.
Also, I thought that /dev/null was just an "abyss" you would send unwanted outputs.
You can't specifically access the cached version, but the OS will (assuming the file isn't too large) remember the blocks read from disk in the cache for a while (until the memory is needed by something else) so that next time the file is ready those blocks do not need to be read from disk. This can make a huge difference on traditional drives.
/dev/null is the abyss, but the cat command will read all the blocks comprising the file from the filesystem before sending them to that abyss.
You can see the effect like so:
dspillett@swann2:/tmp$ time cat a.bigish.file > /dev/null
real 0m3.830s
user 0m0.000s
sys 0m0.468s
dspillett@swann2:/tmp$ time cat a.bigish.file > /dev/null
real 0m0.165s
user 0m0.004s
sys 0m0.164s
dspillett@swann2:/tmp$ time cat a.bigish.file > /dev/null
real 0m0.148s
user 0m0.000s
sys 0m0.144s
(if "a.bigish.file" has only just been created, it will likely already be in RAM, run
sync; echo 3 > /proc/sys/vm/drop_caches
as root or other privileged user to clear the not-currently-active cache & buffers, or chose an older file) (note though that this clears all cache machine-wide, not just cached information from your current session)
So any interaction with the file would put it in memory will do. Of course assuming that you interact with the whole file.
So if you have a big file and use "head", I guess it will not be enough. But you use "less" and scroll the whole thing you achieve the same result as in the command above right?
* If the file is large then blocks at the start will be dropped from cache as you move further in, or will quickly be pushed out by IO activity elsewhere on your system.
* Some commands open files with options that inhibit caching, so not everything will have this effect.
> Of course assuming that you interact with the whole file.
Reading some of the file will have the effect for that portion of the file, so if subsequent commands only touch the same parts then the effect is the same.
These are neat, but is there an explanation for how/why these actually work? (Joke alert!) What sort of n00b just copies and runs random shell commands from the internet without understanding them? (End 'joke)
These are great but, ideally one shouldn't have to leave the command line to get a cheatsheet, it would be great to get a TUI and scroll through bash snippets right from the command line. Is there such tool?
Why misleading? I use `curl icanhazip.com` pretty regularly. Are you considering security issues of echoing the content to the console, or is something else the matter?
SEO playing dirty. They have injected random content and a link. Most probably, they are profiting the reputation of commandlinefu.com, trying increase the google score of their sites.
