What’s the terminal prompt shown the graphics?
An Illustrated Guide to Useful Command Line Tools
91–100 of 108 posts
Re: An Illustrated Guide to Useful Command Line Tools
#92Earlier quoted context omitted.
find has awful ergonomics that are completely unlike any other common unix tool. I can never remember the syntax, how the flags work, or what order things need to be in. Let's use an example I just dug up of using find: To list and remove all regular files named core starting in the directory /prog that are larger than 500KB, enter: find /prog -type f -size +1000 -print -name core -exec rm {} \; OK first, how in the…
Your fd command: Why type=file and a size? What else has size in 500k range on a filesystem, except files? =+500 isn’t how math works, that’s implying it could be -500 or using equals for an inequality because the commonly used greater than symbol is off limits, it’s a learned bodge. 500kwhats? Bits? Bytes? Base2? Base10? Can I put a suffix on, is it kB and kb case sensitive? Why is your filename on the left of the f…
[deleted]
Re: An Illustrated Guide to Useful Command Line Tools
#93Earlier quoted context omitted.
find has awful ergonomics that are completely unlike any other common unix tool. I can never remember the syntax, how the flags work, or what order things need to be in. Let's use an example I just dug up of using find: To list and remove all regular files named core starting in the directory /prog that are larger than 500KB, enter: find /prog -type f -size +1000 -print -name core -exec rm {} \; OK first, how in the…
Your fd command: Why type=file and a size? What else has size in 500k range on a filesystem, except files? =+500 isn’t how math works, that’s implying it could be -500 or using equals for an inequality because the commonly used greater than symbol is off limits, it’s a learned bodge. 500kwhats? Bits? Bytes? Base2? Base10? Can I put a suffix on, is it kB and kb case sensitive? Why is your filename on the left of the f…
>Why type=file and a size? What else has size in 500k range on a filesystem, except files?
Directories. They have a size depending on the metadata list of included files they contain. And can retain their size even if their inner files are deleted (until some cleanup style process is run).
>It’s no more immediately sensible than find
Oh yes, it is.
The same nitpicking for find would take 10 days, and wont be as contrived...
Re: An Illustrated Guide to Useful Command Line Tools
#94Lots of cool stuff in here. I’m going to have a long look at Restic and Syncthing. I’d like to know why Skim instead of FZF. They are pretty similar but I’ve been using the latter for years and would like to know of any possible advantages to it.
There's a lot of these pickers and they are indeed similar. I've been using https://github.com/jhawthorn/fzy since it's not fullscreen and has a really good matching algorithm.
fzy is cool and probably underrated. It's the preferred fuzzy utility for file manager nnn too.
Re: An Illustrated Guide to Useful Command Line Tools
#95I’m gonna sound like an old person here. As much as these tools are gorgeous and ergonomic, remember that the others are standard, which means they’re available (almost) everywhere. Still though, these alternatives seem great for productivity locally, even if they’re not usable in a script.
> I’m gonna sound like an old person here. As much as these tools are gorgeous and ergonomic, remember that the others are standard, which means they’re available (almost) everywhere. Well, I, for one, don't work "almost anywhere", I work with specific servers. I ain't gonna get a new server out of the blue. And if some teams works with the same N servers, they can mandate that the tools are present on all of them. P…
> Plus even on some unknown system, one can quickly copy or download a set of static binaries as our toolset.
Aha, even on a machine with networking problems running a non-glibc set of libraries? (muslc has some problems running glibc (even static,) binaries OOTB, and most docker systems use alpine as a base which means... dealing with musl).
> So unless someone is a sysadmin for heterogenous networks, or is called to go to random clients and fix unseen before systems, or some corporate mandate prevents them from having their tools installed, there's no reason not to expand beyond standard POSIX userland.
I don't believe that the person in question was arguing against expanding beyond the POSIX userland -- rather that they were arguing for maintaining familiarity with POSIX tools in case you need to use them.
Re: An Illustrated Guide to Useful Command Line Tools
#96I quite like this list, there are a number of utilities here that I already use on a daily basis. There are also a few utilities that I like that weren't on this list, or some alternatives to what was shown. Some off the top of my head: - nnn[0] (C) - A terminal file manager, similar to ranger. It allows you to navigate directories, manipulate files, analyze disk usage, and fuzzy open files. - ncdu[1] (C) - ncurses d…
+1 for nnn!
Re: An Illustrated Guide to Useful Command Line Tools
#97I’m gonna sound like an old person here. As much as these tools are gorgeous and ergonomic, remember that the others are standard, which means they’re available (almost) everywhere. Still though, these alternatives seem great for productivity locally, even if they’re not usable in a script.
> I’m gonna sound like an old person here. As much as these tools are gorgeous and ergonomic, remember that the others are standard, which means they’re available (almost) everywhere. Well, I, for one, don't work "almost anywhere", I work with specific servers. I ain't gonna get a new server out of the blue. And if some teams works with the same N servers, they can mandate that the tools are present on all of them. P…
Well, it's not always so simple.
If you are in a small team of 5 or 6 people, with less than 100 servers to manage, sure, it's doable.
But if you are part of a very large team of 50 or more sysadmins, with a large infra in the thousands of nodes with various OSes and vintage of OSes (even if Unix only), things can get tricky quite quickly.
First a lot of people will want their favorite tools to be installed which can result in a huge mess of special toolboxes not being consistently installed (different path location, tool set varying from server to server).
Second, these tools, specially the shiny newer ones, need to be built, packaged and maintained properly which represent a significant load, specially across several OSes/Vintage of OSes.
Third, as a general rule, having an install base with as few packages as possible is generally a good thing, on one hand it reduces the surface of exposition of a server, on a second hand, it helps auditing for security vulnerabilities as "dead weight" dependencies (ex: libX11 for an editor which is both terminal based and graphical based, but only used in its terminal form on a server) will not trigger false positives in term of CVEs.
Re: An Illustrated Guide to Useful Command Line Tools
#98Earlier quoted context omitted.
Neither one interprets the sequence, but cat will print the file unfiltered to stdout, and stdout is processed by your terminal, and then the terminal will interpret it. less filters before printing to the terminal.
I meant that "echo -e" transforms the four characters "\033" into a single byte, for example. Thus, the sequence is "interpreted" by echo. Then, the cat program just copies the bytes without looking at them. If you want "cat" to escape these bytes so that they are not seen by the terminal you can use the "-v" option.
The sequence that translates to an escape code is interpreted by echo. The escape code is passed unfiltered by cat for the terminal to interpret.
Re: An Illustrated Guide to Useful Command Line Tools
#99I quite like this list, there are a number of utilities here that I already use on a daily basis. There are also a few utilities that I like that weren't on this list, or some alternatives to what was shown. Some off the top of my head: - nnn[0] (C) - A terminal file manager, similar to ranger. It allows you to navigate directories, manipulate files, analyze disk usage, and fuzzy open files. - ncdu[1] (C) - ncurses d…
I'd like to further expand on the topic of ncdu.
rclone is a great utility for syncing data between local and remote (including remote to remote) locations and supports a ton of online services.
Well, rclone also supports an ncdu command modeled after the ncdu utility. It lets you quickly calculate directory sizes on remotes that don't show dir sizes, like Google Drive, for example.
Re: An Illustrated Guide to Useful Command Line Tools
#100No mention of things that have gained a lot of traction, like `ag` and `fzf` ag: - silver searcher, fast parallelized recursive grep that can abide by things like `.gitignore` fzf: - fuzzy finder powerline-shell - $PS1 on steroids
It does mention rg which is in the same category as ag and, maybe this is my own bias, seems to have more mindshare now.
Agreed - I used to use Ag but switched to Ripgrep. Better in every single way, in my opinion. It's obscenely fast and has good defaults