https://www.nrl.navy.mil/itd/ncs/products/mgen
ps. ...I know, I know, but sadly no way to make them change the protocol used.
91–100 of 159 posts
https://www.nrl.navy.mil/itd/ncs/products/mgen
ps. ...I know, I know, but sadly no way to make them change the protocol used.
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
$ find . -mindepth 1 -maxdepth 2 -print0 | xargs -0 -- du -hs
Not that I would write it in a shell. ;)
factor is buggy : factor 100000000000000000000000000000000000000 100000000000000000000000000000000000000: 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 http://www.wolframalpha.com/input/?i=factor+1000000000000000... also numfmt bug: $ numfmt --to=iec 999999999999999999939999999 828Y $ numfmt --to=iec 999999999999…
hrrm but bc -l shows : 999999999999999999939999999 / 1024^8 827.18061255302767482177
Earlier quoted context omitted.
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.
Earlier 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…
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.
And having a system using Python on startup is a pretty good indicator that Python will be preinstalled.
However, I see that the situation may be different in specialized distros.
It always pains me when I see people use "cat" left and right, even when they don't need it. This makes for good reading: http://porkmail.org/era/unix/award.html
It shouldn't. It's 2017 now, and the speed difference between a "misplaced" cat command is normally negligible. The speed of the terminal user is more important.
Just 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…
combine file1 not file2
1. http://manpages.ubuntu.com/manpages/zesty/en/man1/combine.1....Anyone here will probably enjoy checking out commandlinefu: http://commandlinefu.com Especially looking down the list of all time greats: http://www.commandlinefu.com/commands/browse/sort-by-votes
...In hindsight, of course...
The gem I just plucked out is something I've been curious about for a while but never looked up:
CTRL-X e
The shell will take what you've written on the command
line thus far and paste it into the editor specified by
$EDITOR [then run it when saved]
Similar to `fc` except you don't need to run the command before invoking the editor