Show sorted list with human readable file/foldersize: du -hs * | sort -h
Tha shows only some files. To list all files, use:
du -hs * .* | sort -h
Linux utils that you might not know
81–90 of 159 posts
Re: Linux utils that you might not know
#82Just look at anything in the "moreutils" package. Just great stuff. Excerpt: - ifdata: do not parse the output of ifconfig/ip anymore. Just use this tool. - sponge: when you need to overwrite an input file at the end of pipe. sponge will wait for the pipe to end before overwriting, preventing any data loss - vidir: edit a given dir with your EDITOR. Awesome for mass renames/deletes. - ts: add timestamps to a command…
Although these tools are great, I'm afraid these are of limited use, as these aren't preinstalled but must be explicitly installed. For personal use these are great. But if you write a shell script to be executed on different machines where you can't install anything, these tools won't be available to you. And if you don't have that requirement, i.e. you can install everything, just install appropriate Perl/Python/Ru…
Is that really a problem anymore? Not being able to install things was common in multi-user thin-client type systems, but these days with containerisation and VMs, if you're allowed to execute a script, you're probably allowed to install new packages
No?
Re: Linux utils that you might not know
#83Earlier quoted context omitted.
Before evaluating the claims myself: The shred manual specifically claims that it is "not guaranteed to be effective" on "log-structured or journaled file systems", and specifically calls out ext3 in data=journal mode. I would assume that the concern with ext3/4 in data=journal mode is that shred does not guarantee that the records of previous writes are evicted from the journal.
In data=journal mode, data to be written is first written into the journal. Only after the journal is flushed it will be written out to the correct location. Therefore, a crash at any time is fixed by replaying the journal forwards. Note that the ext3/4 journal is a redo log, not an undo log. Old file contents are not copied into the journal on a write. Thus, I don't see why shred should be less effective in data=jou…
There is no reason for blocks that have been fully rewritten to be written back to the same location. In fact, it is faster to write them somewhere convenient near the write head and update the indirect block. So even though only the meta data goes through the log, block locations can change.
Re: Linux utils that you might not know
#84Earlier quoted context omitted.
and iirc on SSDs you cant really a file with random bytes. Apple removed the "safe erasure" option from Finder because they couldn't guarantee deletion.
You can, but ssds are internally log structured, you have to overwrite whole free space plus the reserve and then run a TRIM.
You can't overwrite the reserve directly though. You have to write non-zero data to 99% to lock it, then destructively update the last 1% many times to cycle through the reserve.
Many disks have a full erase command, which asks the internal controller to do the erase.
In general though, I use a hammer.
Re: Linux utils that you might not know
#85"cal -3" is quite useful, I use it all the time. To show the week-of-year use "ncal -w". Add "-S" if you want ncal to start weeks on Sunday (crazy!).
Use `cal -m` if you want a week to start on a Monday. AFAIK Sunday is the (US centric) default.
Re: Linux utils that you might not know
#86Earlier quoted context omitted.
Although these tools are great, I'm afraid these are of limited use, as these aren't preinstalled but must be explicitly installed. For personal use these are great. But if you write a shell script to be executed on different machines where you can't install anything, these tools won't be available to you. And if you don't have that requirement, i.e. you can install everything, just install appropriate Perl/Python/Ru…
Is that really a problem anymore? Not being able to install things was common in multi-user thin-client type systems, but these days with containerisation and VMs, if you're allowed to execute a script, you're probably allowed to install new packages No?
Sadly, no.
It is often possible to install things locally, i.e. not using apt. The idea that everyone has sudo privs is unrealistic. A version of apt that added a per user subset would be very useful.
Re: Linux utils that you might not know
#87Earlier quoted context omitted.
Is that really a problem anymore? Not being able to install things was common in multi-user thin-client type systems, but these days with containerisation and VMs, if you're allowed to execute a script, you're probably allowed to install new packages No?
Sadly, no. It is often possible to install things locally, i.e. not using apt. The idea that everyone has sudo privs is unrealistic. A version of apt that added a per user subset would be very useful.
This is actually one of the things that made me work on rootless containers (https://rootlesscontaine.rs). It is a pity that everyone assumes you have sudo access to all of the machines you want to run code on.
Re: Linux utils that you might not know
#88"cal -3" is quite useful, I use it all the time. To show the week-of-year use "ncal -w". Add "-S" if you want ncal to start weeks on Sunday (crazy!).
Why crazy?
A large proportion (if not the majority) of the world starts their calanders on Monday. While the ordering is arbitrary, I always thought of the weekend as a single block of days so it's odd to say that the week ends in the middle of the weekend (rather than at the end of the weekend).
Re: Linux utils that you might not know
#89My favorite: basename Returns just the filename plus extensions e.g. basename a/b/c/d/foo.php returns foo.php Very useful for shell scripting.
With shell one can just use "${path_var##*/}" to get the base name from the string stored in $path_var. This also works if $path_var is just a base name already without any slashes.
EDIT: fixed the substitution.
Re: Linux utils that you might not know
#90Just look at anything in the "moreutils" package. Just great stuff. Excerpt: - ifdata: do not parse the output of ifconfig/ip anymore. Just use this tool. - sponge: when you need to overwrite an input file at the end of pipe. sponge will wait for the pipe to end before overwriting, preventing any data loss - vidir: edit a given dir with your EDITOR. Awesome for mass renames/deletes. - ts: add timestamps to a command…
Although these tools are great, I'm afraid these are of limited use, as these aren't preinstalled but must be explicitly installed. For personal use these are great. But if you write a shell script to be executed on different machines where you can't install anything, these tools won't be available to you. And if you don't have that requirement, i.e. you can install everything, just install appropriate Perl/Python/Ru…
Why assume python? It's huge compared to bash or perl. Lots of minimal configuration operational systems won't have python. More likely than go/ruby/node though.