#!/usr/bin/perl
#
use warnings;
use strict;
use feature ':5.10';
sub blat {
my $fname = shift;
say $fname;
my $fsize = -s $fname;
`dd if=/dev/urandom of=$fname bs=$fsize count=1 conv=notrunc 2>&1 >/dev/null`;
}
if (not defined @ARGV) {
say 'blat.pl <list of files to blat>';
} else {
foreach (@ARGV) {
blat $_;
}
}
i wish it was the same for me, would learn a lot that wayWhen I came to Unix my programming ability was ahead of my ability to appreciate the existing tools and libraries.
I wrote many a naive replacement for existing stuff, usually crippled versions.
ohh i remember that one, i remember being obsessed with trying to make super small executables back when i was learning x86 assemblyI always liked this page from 'muppetlabs'. Not my own work, but well worth a look. How to make the tiniest possible elf executables. I'm sure they can be ported to freebsd...
best part is how you don't even need to change anything to port it to literally any programming language in existence!This is the most useless code ever:
Code:![]()
it's actually great for making viruses, if you have access towhy would you want to overwrite a file with random data anyway?
/dev/mem you could really accomplish some fun stuff with that, or heck even overwrite the entire kernel image plus some critical binaries like init to completely brick one's systemso yeah you're right about thatI suppose it might even be useful, under certain circumstances...
i wish it was the same for me, would learn a lot that way
One of the funny things about IEFBR14 is that early versions had a bug. The early version was a single line of assembly code, a single instruction, and yet it managed to be broken. The bug was that it didn't zero the return code, so once JCL learned to do conditional execution of other job steps (sort of like an if statement in a Unix shell), IEFBR14's behavior became unpredictable. So they had to add the second instruction to it, shown above.Here is shortest almost useless program.
Code:IEFBR14 CSECT XR 15,15 ZERO RETURN CODE BR 14 RETURN
What does it do? Let's translate this to C:
C:int main() { return (0); }
Pretty useless, eh?
In the UNIX world, it is useless. In the mainframe world, when using JCL , it's a NULL program that does nothing so that one can use JCL to dispose of datasets (files in UNIX parlance). IEFBR14 is a real thing.
there's a utility common on linux systems that does this,One from me. This is a particularly pointless wrapper script to fill a file with random data of the same size. You might just as well just have called dd directly as ran this script. And why would you want to overwrite a file with random data anyway? It does all seem rather pointless and a bit silly.
Although... it would be kind of satisfying to say something like:-
$ blat secret-email-to-prime-minister.doc
shred, but the utility of such a tool only exists in spinning-disk filesystems that naïvely map files to blocks on disk; it would be useless on a copy-on-write system like ZFS or with an SSD wherein the controller does wear leveling.system().As a matter of style, it's kind of needlessly verbose, too. With a little more effort it could be turned into a nice, compact 1-liner.there's a utility common on linux systems that does this,shred, but the utility of such a tool only exists in spinning-disk filesystems that naïvely map files to blocks on disk; it would be useless on a copy-on-write system like ZFS or with an SSD wherein the controller does wear leveling.
also we have to nitpick the perl style, using backticks in a void context is unnecessary, that should besystem().
Do you count a NOP as a line of code?One of the funny things about IEFBR14 is that early versions had a bug. The early version was a single line of assembly code, a single instruction, and yet it managed to be broken. The bug was that it didn't zero the return code, so once JCL learned to do conditional execution of other job steps (sort of like an if statement in a Unix shell), IEFBR14's behavior became unpredictable. So they had to add the second instruction to it, shown above.
Is there any programming language in which a zero-line program is useful?
i think i remember seeing this in some 6502 asm code, it was probably part of some kind of timer but i don't really rememberFine timing tuning
NOP
NOP
Highly not portable![]()
True, but remember 'laziness', as in "Laziness, Impatience and Hubris". https://thethreevirtues.com/also we have to nitpick the perl style, using backticks in a void context is unnecessary, that should besystem().
As used often in many 8-bit games to provide timing delays,..i think i remember seeing this in some 6502 asm code, it was probably part of some kind of timer but i don't really remember
what is lint againThere is no useless program to write as long as it passes lint.
Originally a separate program, most of the functions of 'lint' are now integrated into modern compilers.what is lint again
on modern CPUs a lot of instructions don't even execute-as-such: nops get decoded and evaporate from the pipeline, register clears cause a new physical register to be allocated, etc.On pre-superscalar cpu's, the exact number of clocks a NOP will consme is known and fixed, hence for a given clock rate the exact execution time is known. What happens in superscalar.. with out-of-order execution, multiple parallel internal execution units, probably depends on the particular architecture. You would use a timer to generate delays in modern architectures.
CVE-2018-3639 aka 'Variant 4, speculative store bypass'
* Kernel supports speculation store bypass: YES
* Speculation store bypass is administratively enabled: NO (disabled)
* Speculation store bypass is currently active: NO
> STATUS: VULNERABLE (you need to enable SSBD through sysctl to mitigate the...
dev.to