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
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.
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.
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
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`.
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.
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.
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?
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.
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)
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.
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.
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.
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.
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?
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
95 comments
[ 1.0 ms ] story [ 1223 ms ] threadActually I do a similar thing by collecting useful commands in a git repository: https://github.com/TimDaub/commands
These should be used instead: https://git-scm.com/downloads/logos
https://www.commandlinefu.com/commands/browse
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
alternative
>_ find . -empty -type d -delete
GNU find says this very specifically: "There are unavoidable security problems surrounding the -exec action..."
Simple xargs builds the longest possible command line with as many find results as can fit.
If the -n option were used with xargs, it might slow down to similar performance as -exec, but it would still be safer.
Multiple processes can also be launched by the xargs, increasing performance by using multiple CPUs.
Here is a script using xargs -0 to launch 6 compression processes at a time on files specified to a shell script:
Only if you end the exec with \;
If you end it with + then the results are built up and appended to the command much like xargs.
For finding a process on a port, use ss
for a listening processFind biggest 10 files in current and subdirectories and sort by file size
>_ find . -type f -print0 | xargs -0 du -h | sort -hr | head -10
alternative,
>find ./ -printf '%s--%p\n'| sort -nr | head
shuf -r -e --random-source=/dev/urandom {a..z} {0..9} {A..Z} | paste -d "" -s | fold -w 25
You and some other commenters have a great knowledge. Can't wait to dig into it and add it to the page! Thanks a lot
-1 for formatting. Can we at least get a monospace font here?
This part will likely confuse people who are not familiar with shell and will create a bunch of thousands "_" files worldwide.
Quick explanation:
or equivalently: 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.
The trivial copyable prompt would be
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 ">_".
I did a quick fix and replaced ">_" with "$". I will dig into CSS :before during the next update. Thanks for the idea.
You are 100% right. That was quite dump. I think I got the idea from the SSH icon I used in the basics page.
Replaced ">_" with "$". Looks much better and I also updated some of the design and content on the site. Update is live.
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.
If so I don't think it is particularly useful, given that using the file anyway already puts it into the cache for later use
And yes, /dev/null is a abyss and everything written in it is discarded
/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:
(if "a.bigish.file" has only just been created, it will likely already be in RAM, run 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?
There are some complications:
* 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.
* http://www.compciv.org/unix-tools/
* https://www.commandlinefu.com/commands/browse/sort-by-votes
* https://linoxide.com/linux-how-to/linux-commands-brief-outli...
* https://github.com/learnbyexample/Command-line-text-processi... --> this is my own repo on text processing commands like grep/sed/awk/sort/pr/paste/etc
Bonus:
* https://github.com/jlevy/the-art-of-command-line
* https://stackoverflow.com/questions/68372/what-is-your-singl...
IMHO, entries like this are misleading for a beginner (a bad apple in the basket)
Instead I recommend something like:
tail -f /some/file | perl -nle 'print scalar(localtime),":",$_'
and it a bit easier to type IMHO.
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?
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.
In fact, I just checked a few commands and descriptions on this site, and they are identical in formulation of both the command and the description.
Also, one of the first commands on this site is:
Why would it even mention this other site's name here unless it was a complete copy/paste of the commands from the other site?Wow it looks like every thread is full of spam comments, really unfortunate.
I'd rather search google.
Yes I used the https://www.commandlinefu.com/site/api to get the data. I should have mentioned it on the site. And I will add in in the next update.
https://linuxcommandlibrary.com/basics.html has also lots of other info/tips to offer not just the one liners so it's not just a rip off of the particular website :)
[1]: https://git.sr.ht/~gpanders/ual
> Remove all spaces from all files in current folder
should really be "from all file names".
https://www.motowilliams.com/conditional-includes-for-git-co...
Thanks! That's how it actually was in the past. Makes a huge difference. Fixed it.